В этой статье описывается, как создать кластер с тремя узлами в Linux с помощью Pacemaker и добавить ранее созданную группу доступности в качестве ресурса в кластере. Для обеспечения высокого уровня доступности группе доступности в Linux требуется три узла — см. статью Высокий уровень доступности и защита данных для конфигураций групп доступности.
SQL Server не так тесно интегрирован с Pacemaker в Linux, как и с отказоустойчивой кластеризации Windows Server (WSFC). Экземпляр SQL Server не знает о кластере, и все оркестрации находятся вне. Pacemaker обеспечивает оркестрацию ресурсов кластера. Кроме того, имя виртуальной сети относится к отказоустойчивой кластеризации Windows Server; В Pacemaker нет эквивалента. Динамические административные представления группы доступности, запрашивающие сведения о кластере, возвращают пустые строки для кластеров Pacemaker. Чтобы создать прослушиватель для прозрачного переподключения после отработки отказа, вручную зарегистрируйте имя прослушивателя в DNS с IP, использованным для создания ресурса виртуального IP-адреса.
В следующих разделах описаны действия по настройке кластера Pacemaker и добавлению группы доступности в качестве ресурса в кластере для обеспечения высокой доступности для каждого поддерживаемого дистрибутива Linux.
Уровень кластеризации основан на надстройке высокого уровня доступности Red Hat Enterprise Linux (RHEL), созданной на базе Pacemaker.
Примечание.
Для доступа к полной документации по Red Hat требуется действительная подписка.
Дополнительные сведения о конфигурации кластера, параметрах агентов ресурсов и управлении см. в справочной документации по RHEL.
Дорожная карта
Действия по созданию группы доступности на серверах Linux для обеспечения высокой доступности отличаются от действий, выполняемых в отказоустойчивом кластере Windows Server. Ниже описывается общий порядок действий.
Настройте SQL Server в узлах кластера.
Создайте группу доступности.
Настройте диспетчер ресурсов кластера, например Pacemaker. Эти инструкции приведены в этой статье.
Способ настройки диспетчера ресурсов кластера зависит от конкретного дистрибутива Linux.
Внимание
В рабочих средах требуется агент ограждения для обеспечения высокой доступности. В примерах в этой документации агенты ограждения не используются. Примеры приводятся только для тестирования и проверки.
Кластер Linux использует ограждение для возврата кластера в известное состояние. Способ настройки ограждения зависит от дистрибутива и среды. В настоящее время ограждение недоступно в некоторых облачных средах. Дополнительные сведения см. в статье о политиках поддержки для кластеров RHEL с высоким уровнем доступности на платформах виртуализации.
Добавьте группу доступности в виде ресурса в кластере.
Чтобы настроить высокую доступность для RHEL, включите подписку высокой доступности, а затем настройте Pacemaker.
Включение подписки высокой доступности для RHEL
Каждый узел в кластере должен иметь соответствующую подписку для RHEL и надстройку высокой доступности. Ознакомьтесь с требованиями в статье Установка пакетов кластера высокой доступности в Red Hat Enterprise Linux. Выполните следующие действия, чтобы настроить подписку и репозитории.
Зарегистрируйте систему.
sudo subscription-manager register
Укажите имя пользователя и пароль.
Перечислите доступные пулы для регистрации.
sudo subscription-manager list --available
В списке доступных пулов запишите идентификатор пула для подписки высокой доступности.
Измените приведенный ниже скрипт. Замените <pool id>
идентификатором пула для высокой доступности из предыдущего шага. Запустите скрипт, чтобы подключить подписку.
sudo subscription-manager attach --pool=<pool id>
Включите репозиторий.
RHEL 7
sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms
RHEL 8
sudo subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms
Дополнительные сведения см. в статье Pacemaker — кластер с открытым исходным кодом и высокой доступностью.
После настройки подписки выполните следующие действия, чтобы настроить Pacemaker.
После регистрации подписки выполните следующие действия, чтобы настроить Pacemaker.
В брандмауэрах на всех узлах кластера откройте порты для Pacemaker. Чтобы открыть эти порты с помощью firewalld
, выполните следующую команду:
sudo firewall-cmd --permanent --add-service=high-availability
sudo firewall-cmd --reload
Если в брандмауэре нет встроенной конфигурации с высоким уровнем доступности, откройте для Pacemaker следующие порты.
- Порты TCP: 2224, 3121, 21064.
- Порт UDP: 5405.
Установите пакеты Pacemaker на всех узлах.
sudo yum install pacemaker pcs fence-agents-all resource-agents
Задайте пароль для пользователя по умолчанию, который создается при установке пакетов Pacemaker и Corosync. Используйте на всех узлах один и тот же пароль.
sudo passwd hacluster
Чтобы разрешить узлам повторно присоединиться к кластеру после перезапуска, включите и запустите pcsd
службу и Pacemaker. Выполните на всех узлах следующую команду.
sudo systemctl enable pcsd
sudo systemctl start pcsd
sudo systemctl enable pacemaker
Создайте кластер. Чтобы создать кластер, выполните следующую команду:
RHEL 7
sudo pcs cluster auth <node1> <node2> <node3> -u hacluster -p <password for hacluster>
sudo pcs cluster setup --name <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
RHEL 8
Для RHEL 8 необходимо выполнить проверку подлинности узлов отдельно. При появлении запроса введите имя пользователя и пароль для hacluster вручную.
sudo pcs host auth <node1> <node2> <node3>
sudo pcs cluster setup <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
Примечание.
Если кластер был ранее настроен ранее на тех же узлах, при выполнении команды pcs cluster setup
используйте параметр --force
. Этот параметр эквивалентен запуску pcs cluster destroy
. Чтобы повторно включить Pacemaker, выполните команду sudo systemctl enable pacemaker
.
Установите агент ресурсов SQL Server для SQL Server. Выполните следующие команды на всех узлах.
sudo yum install mssql-server-ha
После настройки Pacemaker используйте pcs
для взаимодействия с кластером. Выполните все команды на одном узле из кластера.
Рекомендации по нескольким сетевым интерфейсам (сетевым адаптерам)
При настройке высокого уровня доступности с серверами с несколькими сетевыми адаптерами следуйте приведенным ниже рекомендациям.
Убедитесь hosts
, что файл настроен таким образом, чтобы IP-адреса сервера для нескольких сетевых адаптеров разрешались на имя узла сервера Linux на каждом узле.
При настройке кластера с помощью Pacemaker, используя имя узла серверов, следует настроить Corosync, чтобы настроить конфигурацию для всех сетевых адаптеров. Мы хотим только обмена данными Pacemaker/Corosync по одной сетевой адаптеру. После настройки кластера Pacemaker измените конфигурацию в corosync.conf
файле и обновите IP-адрес выделенной сетевой карты, которую вы хотите использовать для связи Pacemaker/Corosync.
Заданный <hostname>
в corosync.conf
файле должен совпадать с выходными данными, заданными при выполнении обратного поиска (ping -a <ip_address>
), и должно быть коротким именем, настроенным на узле. Убедитесь, hosts
что файл также представляет правильный IP-адрес для разрешения имен.
Ниже выделены изменения в corosync.conf
примере файла:
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
Поставщики кластеров Pacemaker требуют ограждения неудающегося узла с помощью устройства ограждения, настроенного для поддерживаемой настройки кластера. Если диспетчер ресурсов кластера не может определить состояние узла или ресурса на узле, ограждение снова приводит кластер к известному состоянию.
Устройство ограждения предоставляет агент ограждения. Настройка Pacemaker в Red Hat Enterprise Linux в Azure содержит пример создания устройства ограждения для этого кластера в Azure . Измените инструкции для своей среды.
Ограждение на уровне ресурсов гарантирует отсутствие повреждения данных при сбое путем настройки ресурса. Например, вы можете использовать ограждение на уровне ресурсов, чтобы пометить диск на узле как устаревший при отключении канала связи.
Ограждение на уровне узлов гарантирует, что в узле не выполняются никакие ресурсы. Это осуществляется путем сброса узла. Pacemaker поддерживает множество разных устройств ограждения, например источник бесперебойного питания или карты интерфейса управления для серверов.
Сведения о ограждении узла сбоем см. в следующих статьях:
Примечание.
Так как конфигурация ограждения на уровне узлов сильно зависит от вашей среды, отключите ее для этого руководства (ее можно настроить позже). Следующий скрипт отключает ограждение на уровне узла.
sudo pcs property set stonith-enabled=false
Отключение ограждения предназначено только для тестирования. Если вы планируете использовать Pacemaker в рабочей среде, следует запланировать реализацию ограждения в зависимости от среды и сохранить ее включено.
Задание свойства кластера cluster-recheck-interval
cluster-recheck-interval
указывает интервал опроса, с помощью которого кластер проверяет изменения параметров ресурса, ограничений или других параметров кластера. Если реплика выходит из строя, кластер пытается перезапустить ее с интервалом, который связан со значениями failure-timeout
и cluster-recheck-interval
. Например, если для failure-timeout
установлено значение 60 с, а для cluster-recheck-interval
— 120 с, то повторная попытка перезапуска предпринимается с интервалом, который больше 60 с, но меньше 120 с. Рекомендуется задать время ожидания сбоя 60 секунд и cluster-recheck-interval
значение, превышающее 60 секунд. Не рекомендуется задать cluster-recheck-interval
небольшое значение.
Чтобы изменить значение свойства на 2 minutes
, выполните следующую команду:
sudo pcs property set cluster-recheck-interval=2min
Если у вас уже есть ресурс группы доступности, управляемый кластером Pacemaker, пакет Pacemaker 1.1.18-11.el7 представил изменение поведения для start-failure-is-fatal
параметра кластера при его значении false
. Это изменение влияет на рабочий процесс отработки отказа. В случае сбоя первичной реплики ожидается, что будет выполнена отработка отказа кластера на одну из доступных вторичных реплик. Вместо этого пользователи замечают, что кластер продолжает пытаться запустить сбой первичной реплики. Если первичная реплика не включается (из-за постоянного сбоя), кластер не выполняет отработку отказа на другую доступную вторичную реплику. Из-за этого изменения ранее рекомендуемая конфигурация start-failure-is-fatal
больше не является допустимой, а параметр должен быть возвращен обратно в значение true
по умолчанию.
Кроме того, нужно обновить ресурс группы доступности для включения свойства failure-timeout
.
Чтобы изменить значение свойства на true
, выполните следующую команду:
sudo pcs property set start-failure-is-fatal=true
Чтобы обновить свойство failure-timeout
60s
ресурса, выполните следующую ag_cluster
команду:
pcs resource update ag_cluster meta failure-timeout=60s
Сведения о свойствах кластера Pacemaker см. в статье Свойства кластеров Pacemaker.
Создание учетных данных SQL Server для Pacemaker
Во всех экземплярах SQL Server создайте имя входа сервера для Pacemaker.
Следующий запрос Transact-SQL создает имя для входа:
USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
Во время создания группы доступности пользователю Pacemaker требуются ALTER
CONTROL
разрешения на группу доступности, VIEW DEFINITION
но до добавления в нее всех узлов.
Во всех экземплярах SQL Server сохраните учетные данные для имени входа SQL Server.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
Создание ресурса группы доступности
Чтобы создать ресурс группы доступности, используйте команду pcs resource create
и задайте свойства ресурса. Приведенная ниже команда ocf:mssql:ag
создает ресурс типа «основной/подчиненный» для группы доступности ag1
.
RHEL 7
sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s master notify=true
RHEL 8
С выходом RHEL 8 был изменен синтаксис Create. Если вы используете RHEL 8, терминология master
изменилась promotable
на . Используйте следующую команду Create вместо приведенной выше команды:
sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s promotable notify=true
Примечание.
При создании ресурса и периодически после этого агент ресурсов Pacemaker автоматически задает в группе доступности значение REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
на основе ее конфигурации. Например, если группа доступности содержит три синхронные реплики, агент задаст для REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
значение 1
. Дополнительную информацию и параметры конфигурации см. в разделе High Availability and Data Protection for Availability Group Configurations (Высокий уровень доступности и защита данных для конфигураций групп доступности).
Создание ресурса виртуального IP-адреса
Чтобы создать ресурс виртуального IP-адреса, выполните указанную ниже команду на одном узле. Используйте доступный статический IP-адрес из сети. Замените IP-адрес между <10.128.16.240>
на допустимый IP-адрес.
sudo pcs resource create virtualip ocf:heartbeat:IPaddr2 ip=<10.128.16.240>
В Pacemaker эквивалент имени виртуального сервера отсутствует. Чтобы использовать строку подключения, указывающую на строковое имя сервера, вместо IP-адреса, зарегистрируйте виртуальный IP-адрес ресурса и требуемое имя виртуального сервера в DNS. Для конфигураций аварийного восстановления зарегистрируйте имя и IP-адрес нужного виртуального сервера на DNS-серверах на основном сайте и сайте аварийного восстановления.
Добавление ограничения совместного размещения
Почти каждое решение в кластере Pacemaker, например выбор места запуска ресурса, принимается путем сравнения оценок. Оценки вычисляются для каждого ресурса. Диспетчер кластерных ресурсов выбирает узел с наивысшей оценкой для конкретного ресурса. Если узел имеет отрицательный показатель для ресурса, ресурс не может работать на этом узле.
В кластере Pacemaker можно управлять решениями для кластера с помощью ограничений. Ограничения имеют оценку. Если ограничение имеет оценку меньше INFINITY
, Pacemaker считает его рекомендацией. Оценка, равная INFINITY
, указывает на обязательный характер.
Чтобы убедиться, что первичная реплика и ресурсы виртуального IP-адреса выполняются на одном узле, определите ограничение совместного размещения с оценкой INFINITY. Чтобы добавить ограничение совместного размещения, выполните приведенную ниже команду на одном узле.
RHEL 7
При создании ресурса ag_cluster
в RHEL 7 он создает ресурс как ag_cluster-master
. Используйте следующий формат команды в RHEL 7:
sudo pcs constraint colocation add virtualip ag_cluster-master INFINITY with-rsc-role=Master
RHEL 8
При создании ресурса ag_cluster
в RHEL 8 он создает ресурс как ag_cluster-clone
. Используйте следующий формат команды в RHEL 8:
sudo pcs constraint colocation add virtualip with master ag_cluster-clone INFINITY with-rsc-role=Master
Добавление ограничения упорядочения
Ограничение совместного размещения имеет неявное ограничение упорядочения. Оно перемещает ресурс виртуального IP-адреса перед перемещением ресурса группы доступности. Последовательность событий по умолчанию:
Пользователь выполняет команду pcs resource move
с узла node1 на узел node2 для первичной реплики группы доступности.
Ресурс виртуального IP-адреса останавливается в узле 1.
Ресурс виртуального IP-адреса запускается в узле 2.
Примечание.
На этом этапе IP-адрес временно указывает на узел 2, пока узел 2 все еще является вторичной репликой перед отработкой отказа.
Первичная реплика группы доступности на узле 1 понижается до вторичной.
Вторичная реплика группы доступности на узле 2 повышается до первичной.
Чтобы предотвратить ситуацию, когда IP-адрес временно указывает на узел с вторичной репликой перед отработкой отказа, добавьте ограничение упорядочения.
Чтобы добавить ограничение упорядочения, выполните приведенную ниже команду в одном узле.
RHEL 7
sudo pcs constraint order promote ag_cluster-master then start virtualip
RHEL 8
sudo pcs constraint order promote ag_cluster-clone then start virtualip
Внимание
После настройки кластера и добавления группы доступности в качестве ресурса кластера вы не можете использовать Transact-SQL для отработки отказа ресурсов группы доступности. Ресурсы кластера SQL Server в Linux не так сильно зависят от операционной системы, как если бы они находились в отказоустойчивом кластере Windows Server (WSFC). Служба SQL Server не знает о присутствии кластера. Вся оркестрация осуществляется с помощью средств управления кластерами. В RHEL или Ubuntu используйте pcs
, а в SLES — crm
.
Вручную выполните отработку отказа группы доступности с помощью pcs
. Не инициируйте отработку отказа с помощью Transact-SQL. Инструкции см. в статье Отработка отказа.
Связанный контент
Уровень кластеризации основан на расширении высокого уровня доступности (HAE), построенном на основе Pacemaker.
Дополнительные сведения о конфигурации кластера, параметрах агента ресурсов, управлении, рекомендациях и рекомендациях см. в разделе SUSE Linux Enterprise High Availability Extension.
Дорожная карта
Процедура создания группы доступности для обеспечения высокого уровня доступности на серверах Linux отличается от процедуры для отказоустойчивого кластера Windows Server. Ниже описывается общий порядок действий.
Настройте SQL Server в узлах кластера.
Создайте группу доступности.
Настройте диспетчер ресурсов кластера, например Pacemaker. Эти инструкции приведены в этой статье.
Способ настройки диспетчера ресурсов кластера зависит от конкретного дистрибутива Linux.
Внимание
В рабочих средах требуется агент ограждения для обеспечения высокой доступности. Примеры, приведенные в этой статье, не используют агенты ограждения. Они служат только для тестирования и проверки.
Кластер Linux использует ограждение для возврата кластера в известное состояние. Способ настройки ограждения зависит от дистрибутива и среды. В настоящее время ограждение недоступно в некоторых облачных средах. Дополнительные сведения см. в разделе SUSE Linux Enterprise High Availability Extension.
Добавление группы доступности в качестве ресурса в кластере
Необходимые компоненты
Для выполнения описанного ниже сценария нужны три компьютера для развертывания кластера с тремя узлами. Ниже описаны общие действия по настройке этих серверов.
Сначала необходимо настроить операционную систему в узлах кластера. Для этого пошагового руководства используйте SLES 12 с пакетом обновления 3 (SP3) с действительной подпиской на надстройку высокого уровня доступности.
Установите и настройте службу SQL Server во всех узлах. Подробные инструкции см. в руководстве по установке SQL Server на Linux.
Назначьте один узел первичным, а остальные — вторичными. Эти термины будут применяться далее в данном руководстве.
Убедитесь в том, что узлы, которые будут входить в кластер, могут взаимодействовать друг с другом.
В следующем примере показан файл /etc/hosts
с дополнениями для трех узлов: SLES1, SLES2 и SLES3.
127.0.0.1 localhost
10.128.16.33 SLES1
10.128.16.77 SLES2
10.128.16.22 SLES3
У всех узлов кластера должен быть доступ друг к другу через SSH. Таким средствам, как hb_report
или crm_report
(для устранения неполадок) и обозреватель журнала Hawk, не нужен пароль для доступа по SSH между узлами. В противном случае они могут только собирать данные из текущего узла. Если вы используете нестандартный порт SSH, воспользуйтесь параметром -X (см. страницу man
). Например, если вы используете порт SSH 3479, вызовите средство crm_report
с помощью следующей команды:
sudo crm_report -X "-p 3479" [...]
Дополнительные сведения см. в разделе "Прочее" руководства по администрированию SLES.
Создание учетных данных SQL Server для Pacemaker
Во всех экземплярах SQL Server создайте имя входа сервера для Pacemaker.
Следующий запрос Transact-SQL создает имя для входа:
USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
Во время создания группы доступности пользователю Pacemaker требуются ALTER
CONTROL
разрешения на группу доступности, VIEW DEFINITION
но до добавления в нее всех узлов.
Во всех экземплярах SQL Server сохраните учетные данные для имени входа SQL Server.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
На серверах Linux настройте группу доступности, а затем настройте кластерные ресурсы. Сведения о настройке группы доступности см. в разделе "Настройка группы доступности AlwaysOn SQL Server" для обеспечения высокой доступности в Linux
Установите расширение высокого уровня доступности.
Дополнительные сведения см. в статье об установке SUSE Linux Enterprise Server и расширении высокой доступности.
Установите пакет агента ресурсов SQL Server в обоих узлах.
sudo zypper install mssql-server-ha
Настройка первого узла
Ознакомьтесь с инструкциями по установке SLES.
Войдите как root
на физическую или виртуальную машину, которую вы хотите использовать в качестве узла кластера.
Запустите скрипт начальной загрузки с помощью следующей команды:
sudo ha-cluster-init
Если NTP не настроен для запуска во время загрузки, появится сообщение.
Если вы решите продолжить работу, скрипт автоматически создает ключи для доступа К SSH и средства синхронизации Csync2 и запускает службы, необходимые для обоих.
Чтобы настроить слой связи кластера (Corosync), выполните указанные ниже действия.
Введите сетевой адрес для привязки. По умолчанию скрипт предлагает сетевой адрес eth0. Можно ввести другой сетевой адрес, например bond0.
Введите адрес многоадресной рассылки. Скрипт предлагает случайный адрес, который можно использовать по умолчанию.
Введите порт многоадресной рассылки. Сценарий предлагает порт 5405 по умолчанию.
Чтобы настроить SBD ()
, введите постоянный путь к разделу блочного устройства, которое следует использовать для SBD. Путь должен быть одинаковым во всех узлах кластера.
Наконец, скрипт запустит службу Pacemaker, чтобы перевести кластер с одним узлом в оперативный режим и включить веб-интерфейс управления Hawk2. URL-адрес, используемый для Hawk2, отображается на экране.
Подробные сведения о процессе установки см. в файле /var/log/sleha-bootstrap.log
. Теперь у вас есть работающий кластер с одним узлом. Проверьте состояние кластера с помощью команды crm status:
sudo crm status
Можно также просмотреть конфигурацию кластера с помощью crm configure show xml
или crm configure show
.
Процедура начальной загрузки создает пользователя Linux с именем hacluster и паролем linux. Замените пароль по умолчанию надежным как можно скорее.
sudo passwd hacluster
Добавление узлов в существующий кластер
В работающий кластер с одним или несколькими узлами можно добавить дополнительные узлы с помощью скрипта начальной загрузки ha-cluster-join. Скрипту требуется доступ только к существующему узлу кластера. Он автоматически выполняет базовую установку на текущем компьютере. Выполните указанные ниже действия.
Если вы настроили существующие узлы кластера с помощью модуля кластера YaST
, перед запуском скрипта ha-cluster-join
убедитесь в том, что выполнены указанные ниже необходимые условия.
- Привилегированный пользователь в существующих узлах имеет ключи SSH для входа без пароля.
- В существующих узлах настроено средство
Csync2
. Дополнительные сведения см. в разделе "Настройка Csync2 с помощью YaST".
Войдите как root
на физическую или виртуальную машину, которая должна присоединиться к кластеру.
Запустите скрипт начальной загрузки с помощью следующей команды:
sudo ha-cluster-join
Если NTP не настроен для запуска во время загрузки, появится сообщение.
Если вы решите продолжить все равно, вам будет предложено ввести IP-адрес существующего узла. Введите IP-адрес.
Если вы еще не настроили доступ без пароля SSH между обоими компьютерами, вам также будет предложено ввести корневой пароль существующего узла.
После входа в указанный узел скрипт копирует конфигурацию Corosync, настраивает SSH и Csync2
и переводит текущий компьютер в режим "в сети" в качестве нового узла кластера. Помимо этого, он запускает службу, необходимую для Hawk. Если вы настроили общее хранилище с OCFS2
, также автоматически создается каталог точки подключения для файловой системы OCFS2
.
Повторите предыдущие действия для всех компьютеров, которые требуется добавить в кластер.
Подробные сведения о процессе см. в файле /var/log/ha-cluster-bootstrap.log
.
Проверьте состояние кластера с помощью команды sudo crm status
. Если вы успешно добавили второй узел, выходные данные аналогичны следующим:
sudo crm status
Вы увидите выходные данные, аналогичные следующему примеру.
3 nodes configured
1 resource configured
Online: [ SLES1 SLES2 SLES3]
Full list of resources:
admin_addr (ocf::heartbeat:IPaddr2): Started node1
Примечание.
admin_addr
— это виртуальный кластерный ресурс IP-адреса, который настраивается в процессе первоначальной установки кластера с одним узлом.
После добавления всех узлов проверьте, нужно ли настроить политику без кворума в глобальных параметрах кластера. Это особенно важно для кластеров с двумя узлами.
Задание свойства кластера cluster-recheck-interval
cluster-recheck-interval
указывает интервал опроса, с помощью которого кластер проверяет изменения параметров ресурса, ограничений или других параметров кластера. Если реплика выходит из строя, кластер пытается перезапустить ее с интервалом, который связан со значениями failure-timeout
и cluster-recheck-interval
. Например, если для failure-timeout
установлено значение 60 с, а для cluster-recheck-interval
— 120 с, то повторная попытка перезапуска предпринимается с интервалом, который больше 60 с, но меньше 120 с. Рекомендуется задать время ожидания сбоя 60 секунд и cluster-recheck-interval
значение, превышающее 60 секунд. Не рекомендуется задать cluster-recheck-interval
небольшое значение.
Чтобы изменить значение свойства на 2 minutes
, выполните следующую команду:
crm configure property cluster-recheck-interval=2min
Если у вас уже есть ресурс группы доступности, управляемый кластером Pacemaker, пакет Pacemaker 1.1.18-11.el7 представил изменение поведения для start-failure-is-fatal
параметра кластера при его значении false
. Это изменение влияет на рабочий процесс отработки отказа. В случае сбоя первичной реплики ожидается, что будет выполнена отработка отказа кластера на одну из доступных вторичных реплик. Вместо этого пользователи замечают, что кластер продолжает пытаться запустить сбой первичной реплики. Если первичная реплика не включается (из-за постоянного сбоя), кластер не выполняет отработку отказа на другую доступную вторичную реплику. Из-за этого изменения ранее рекомендуемая конфигурация start-failure-is-fatal
больше не является допустимой, а параметр должен быть возвращен обратно в значение true
по умолчанию.
Кроме того, нужно обновить ресурс группы доступности для включения свойства failure-timeout
.
Чтобы изменить значение свойства на true
, выполните следующую команду:
crm configure property start-failure-is-fatal=true
Измените существующее свойство failure-timeout
ресурса группы доступности на выполнение 60s
(замените ag1
именем ресурса группы доступности).
crm configure edit ag1
В текстовом редакторе добавьте meta failure-timeout=60s
после всех param
s и до любого op
.
Дополнительные сведения о свойствах кластера Pacemaker см. в статье Настройка ресурсов кластера.
Рекомендации по нескольким сетевым интерфейсам (сетевым адаптерам)
При настройке высокого уровня доступности с серверами с несколькими сетевыми адаптерами следуйте приведенным ниже рекомендациям.
Убедитесь hosts
, что файл настроен таким образом, чтобы IP-адреса сервера для нескольких сетевых адаптеров разрешались на имя узла сервера Linux на каждом узле.
При настройке кластера с помощью Pacemaker, используя имя узла серверов, следует настроить Corosync, чтобы настроить конфигурацию для всех сетевых адаптеров. Мы хотим только обмена данными Pacemaker/Corosync по одной сетевой адаптеру. После настройки кластера Pacemaker измените конфигурацию в corosync.conf
файле и обновите IP-адрес выделенной сетевой карты, которую вы хотите использовать для связи Pacemaker/Corosync.
Заданный <hostname>
в corosync.conf
файле должен совпадать с выходными данными, заданными при выполнении обратного поиска (ping -a <ip_address>
), и должно быть коротким именем, настроенным на узле. Убедитесь, hosts
что файл также представляет правильный IP-адрес для разрешения имен.
Ниже выделены изменения в corosync.conf
примере файла:
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
Поставщики кластеров Pacemaker требуют ограждения неудающегося узла с помощью устройства ограждения, настроенного для поддерживаемой настройки кластера. Если диспетчер ресурсов кластера не может определить состояние узла или ресурса на узле, ограждение снова приводит кластер к известному состоянию.
Ограждение на уровне ресурсов обеспечивает главным образом отсутствие повреждения данных во время сбоя путем настройки ресурса. Вы можете использовать ограждение на уровне ресурсов, например с распределенным реплицируемым блочным устройством (DRBD), чтобы пометить диск в узле как устаревший при отключении канала связи.
Ограждение на уровне узлов гарантирует, что в узле не выполняются никакие ресурсы. Это делается путем сброса узла, а реализация Pacemaker называется STONITH. Pacemaker поддерживает множество разных устройств ограждения, таких как источник бесперебойного питания или карты интерфейса управления для серверов.
Дополнительные сведения см. в разделе:
Во время инициализации кластера ограждение отключено, если конфигурация не обнаружена. Его можно включить позже, выполнив следующую команду:
sudo crm configure property stonith-enabled=true
Внимание
Отключение ограждения предназначено только для тестирования. Если вы планируете использовать Pacemaker в рабочей среде, следует запланировать реализацию ограждения в зависимости от среды и сохранить ее включено. SUSE не предоставляет агенты ограждения для облачных сред (включая Azure) или Hyper-V. Следовательно, поставщик кластера не предлагает поддержку запуска рабочих кластеров в этих средах. Мы работаем над этой проблемой. Решение будет доступно в будущих выпусках.
Ознакомьтесь с руководством по администрированию SLES.
Включение Pacemaker
Включите автоматический запуск Pacemaker.
Выполните приведенную ниже команду в каждом узле кластера.
systemctl enable pacemaker
Создание ресурса группы доступности
Приведенная ниже команда создает и настраивает ресурс группы доступности для трех реплик группы доступности [ag1]. Операции мониторинга и значения времени ожидания необходимо задать в SLES явно, так как время ожидания сильно зависит от рабочей нагрузки и его необходимо тщательно подбирать для каждого развертывания.
Выполните следующую команду в одном из узлов кластера:
Выполните команду crm configure
, чтобы открыть командную строку crm:
sudo crm configure
В командной строке crm выполните приведенную ниже команду, чтобы настроить свойства ресурса.
primitive ag_cluster \
ocf:mssql:ag \
params ag_name="ag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag_cluster ag_cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true" \
commit
Примечание.
При создании ресурса и периодически после этого агент ресурсов Pacemaker автоматически задает в группе доступности значение REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
на основе ее конфигурации. Например, если группа доступности содержит три синхронные реплики, агент задаст для REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
значение 1
. Дополнительную информацию и параметры конфигурации см. в разделе High Availability and Data Protection for Availability Group Configurations (Высокий уровень доступности и защита данных для конфигураций групп доступности).
Создание ресурса виртуального IP-адреса
Если вы не создали ресурс виртуального IP-адреса при запуске ha-cluster-init
, вы можете создать этот ресурс. Указанная ниже команда создает ресурс виртуального IP-адреса. Замените <**0.0.0.0**>
доступным в сети адресом, а <**24**>
— числом битов в маске подсети CIDR. Выполните команду в одном узле.
crm configure \
primitive admin_addr \
ocf:heartbeat:IPaddr2 \
params ip=<**0.0.0.0**> \
cidr_netmask=<**24**>
Добавление ограничения совместного размещения
Почти каждое решение в кластере Pacemaker, например выбор места запуска ресурса, принимается путем сравнения оценок. Оценки вычисляются для каждого ресурса, а диспетчер ресурсов кластера выбирает узел с наивысшей оценкой для конкретного ресурса. (Если узел имеет отрицательный показатель для ресурса, ресурс не может запуститься на этом узле.) Мы можем управлять решениями кластера с ограничениями. Ограничения имеют оценку. Если ограничение имеет оценку меньше бесконечности (INFINITY), то это только рекомендация. Оценка INFINITY означает, что это обязательно. Чтобы первичная реплика группы доступности и ресурс виртуального IP-адреса находились в одном узле, определите ограничение совместного размещения с оценкой INFINITY.
Чтобы задать ограничение совместного размещения для виртуального IP-адреса, выполняемого на том же узле, что и основной узел, выполните следующую команду на одном узле:
crm configure
colocation vip_on_master inf: \
admin_addr ms-ag_cluster:Master
commit
Добавление ограничения упорядочения
Ограничение совместного размещения имеет неявное ограничение упорядочения. Оно перемещает ресурс виртуального IP-адреса перед перемещением ресурса группы доступности. Последовательность событий по умолчанию:
- Пользователь выполняет команду
resource migrate
с узла node1 на узел node2 для первичной реплики группы доступности.
- Ресурс виртуального IP-адреса останавливается в узле 1.
- Ресурс виртуального IP-адреса запускается в узле 2. На этом этапе IP-адрес временно указывает на узел 2, пока узел 2 все еще является вторичной репликой перед отработкой отказа.
- Уровень главной реплики группы доступности в узле 1 понижается.
- Реплика группы доступности в узле 2 повышается до главной.
Чтобы предотвратить ситуацию, когда IP-адрес временно указывает на узел с вторичной репликой перед отработкой отказа, добавьте ограничение упорядочения.
Чтобы добавить ограничение упорядочения, выполните приведенную ниже команду в одном узле.
sudo crm configure \
order ag_first inf: ms-ag_cluster:promote admin_addr:start
Внимание
После настройки кластера и добавления группы доступности в качестве ресурса кластера вы не можете использовать Transact-SQL для отработки отказа ресурсов группы доступности. Ресурсы кластера SQL Server в Linux не так сильно зависят от операционной системы, как если бы они находились в отказоустойчивом кластере Windows Server (WSFC). Служба SQL Server не знает о присутствии кластера. Вся оркестрация осуществляется с помощью средств управления кластерами. В SLES используйте crm
.
Вручную выполните отработку отказа группы доступности с помощью crm
. Не инициируйте отработку отказа с помощью Transact-SQL. Дополнительные сведения см. в разделе Отработка отказа.
Дополнительные сведения см. в разделе:
Связанный контент
Дорожная карта
Действия по созданию группы доступности на серверах Linux для обеспечения высокой доступности отличаются от действий, выполняемых в отказоустойчивом кластере Windows Server. Ниже описывается общий порядок действий.
Руководство по установке SQL Server на Linux.
Настройте группу доступности SQL Server AlwaysOn для обеспечения высокой доступности в Linux.
Настройте диспетчер ресурсов кластера, например Pacemaker. Эти инструкции приведены в этой статье.
Способ настройки диспетчера ресурсов кластера зависит от конкретного дистрибутива Linux.
Внимание
В рабочих средах требуется агент ограждения для обеспечения высокой доступности. Примеры, приведенные в этой статье, не используют агенты ограждения. Они служат только для тестирования и проверки.
Кластер Linux использует ограждение для возврата кластера в известное состояние. Способ настройки ограждения зависит от дистрибутива и среды. В настоящее время ограждение недоступно в некоторых облачных средах.
Ограждение обычно реализуется в операционной системе и зависит от среды. Инструкции по установке ограждений см. в документации распространителя операционной системы.
Добавьте группу доступности в виде ресурса в кластере.
На всех узлах откройте порты брандмауэра. Откройте порт для службы высокой доступности Pacemaker, экземпляра SQL Server и конечной точки группы доступности. Tcp-порт по умолчанию для сервера под управлением SQL Server 1433
.
sudo ufw allow 2224/tcp
sudo ufw allow 3121/tcp
sudo ufw allow 21064/tcp
sudo ufw allow 5405/udp
sudo ufw allow 1433/tcp # Replace with TDS endpoint
sudo ufw allow 5022/tcp # Replace with DATA_MIRRORING endpoint
sudo ufw reload
Кроме того, можно отключить брандмауэр, но это не рекомендуется в рабочей среде:
sudo ufw disable
Установите пакеты Pacemaker. На всех узлах выполните следующие команды для Ubuntu 20.04. Дополнительные сведения об установке в предыдущих версиях см. в статье Ubuntu HA — MS SQL Server в Azure.
sudo apt-get install -y pacemaker pacemaker-cli-utils crmsh resource-agents fence-agents corosync python3-azure
Задайте пароль для пользователя по умолчанию, который создается при установке пакетов Pacemaker и Corosync. Используйте на всех узлах один и тот же пароль.
sudo passwd hacluster
Создайте кластер.
Перед созданием кластера необходимо создать ключ проверки подлинности на первичном сервере и скопировать его на другие серверы, участвующие в группе доступности.
Используйте следующий сценарий, чтобы создать ключ проверки подлинности на первичном сервере:
sudo corosync-keygen
Вы можете скопировать scp
созданный ключ на другие серверы:
sudo scp /etc/corosync/authkey dbadmin@server-02:/etc/corosync
sudo scp /etc/corosync/authkey dbadmin@server-03:/etc/corosync
Чтобы создать кластер, измените /etc/corosync/corosync.conf
файл на основном сервере:
sudo vim /etc/corosync/corosync.conf
Файл corosync.conf
должен выглядеть примерно так:
totem {
version: 2
cluster_name: agclustername
transport: udpu
crypto_cipher: none
crypto_hash: none
}
logging {
fileline: off
to_stderr: yes
to_logfile: yes
logfile: /var/log/corosync/corosync.log
to_syslog: yes
debug: off
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
provider: corosync_votequorum
}
nodelist {
node {
name: server-01
nodeid: 1
ring0_addr: 10.0.0.4
}
node {
name: server-02
nodeid: 2
ring0_addr: 10.0.0.5
}
node {
name: server-03
nodeid: 3
ring0_addr: 10.0.0.6
}
}
Замените corosync.conf
файл на других узлах:
sudo scp /etc/corosync/corosync.conf dbadmin@server-02:/etc/corosync
sudo scp /etc/corosync/corosync.conf dbadmin@server-03:/etc/corosync
pacemaker
Перезапустите и corosync
службы:
sudo systemctl restart pacemaker corosync
Подтвердите состояние кластера и проверьте конфигурацию:
sudo crm status
Рекомендации по нескольким сетевым интерфейсам (сетевым адаптерам)
При настройке высокого уровня доступности с серверами с несколькими сетевыми адаптерами следуйте приведенным ниже рекомендациям.
Убедитесь hosts
, что файл настроен таким образом, чтобы IP-адреса сервера для нескольких сетевых адаптеров разрешались на имя узла сервера Linux на каждом узле.
При настройке кластера с помощью Pacemaker, используя имя узла серверов, следует настроить Corosync, чтобы настроить конфигурацию для всех сетевых адаптеров. Мы хотим только обмена данными Pacemaker/Corosync по одной сетевой адаптеру. После настройки кластера Pacemaker измените конфигурацию в corosync.conf
файле и обновите IP-адрес выделенной сетевой карты, которую вы хотите использовать для связи Pacemaker/Corosync.
Заданный <hostname>
в corosync.conf
файле должен совпадать с выходными данными, заданными при выполнении обратного поиска (ping -a <ip_address>
), и должно быть коротким именем, настроенным на узле. Убедитесь, hosts
что файл также представляет правильный IP-адрес для разрешения имен.
Ниже выделены изменения в corosync.conf
примере файла:
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
Поставщики кластеров Pacemaker требуют ограждения неудающегося узла с помощью устройства ограждения, настроенного для поддерживаемой настройки кластера. Если диспетчер ресурсов кластера не может определить состояние узла или ресурса на узле, ограждение снова приводит кластер к известному состоянию.
Ограждение на уровне ресурсов гарантирует отсутствие повреждения данных при сбое. Вы можете использовать ограждение на уровне ресурсов, например с распределенным реплицируемым блочным устройством (DRBD), чтобы пометить диск в узле как устаревший при отключении канала связи.
Ограждение на уровне узлов гарантирует, что в узле не выполняются никакие ресурсы. Это делается путем сброса узла, а реализация Pacemaker называется STONITH. Pacemaker поддерживает множество разных устройств ограждения, таких как источник бесперебойного питания или карты интерфейса управления для серверов.
Дополнительные сведения см. в статьях Кластеры Pacemaker с нуля и Ограждение и Stonith.
Так как конфигурация ограждения на уровне узлов сильно зависит от вашей среды, мы отключим ее для этого руководства (ее можно настроить позже). Запустите следующий скрипт на первичном узле.
sudo crm configure property stonith-enabled=false
В этом примере отключение ограждения предназначено только для тестирования. Если вы планируете использовать Pacemaker в рабочей среде, следует запланировать реализацию ограждения в зависимости от среды и сохранить ее включено. Обратитесь к поставщику операционной системы за информацией об агентах ограждения для любого конкретного распределения.
Задание свойства кластера cluster-recheck-interval
Свойство cluster-recheck-interval
указывает интервал опроса, с помощью которого кластер проверяет изменения параметров ресурса, ограничений или других параметров кластера. Если реплика выходит из строя, кластер пытается перезапустить ее с интервалом, который связан со значениями failure-timeout
и cluster-recheck-interval
. Например, если для failure-timeout
установлено значение 60 с, а для cluster-recheck-interval
— 120 с, то повторная попытка перезапуска предпринимается с интервалом, который больше 60 с, но меньше 120 с. Необходимо задать параметр failure-timeout
со значением 60 секунд и параметр cluster-recheck-interval
со значением больше 60 секунд. Установка для cluster-recheck-interval
меньшего значения не рекомендуется.
Чтобы изменить значение свойства на 2 minutes
, выполните следующую команду:
sudo crm configure property cluster-recheck-interval=2min
Если у вас уже есть ресурс группы доступности, управляемый кластером Pacemaker, пакет Pacemaker 1.1.18-11.el7 представил изменение поведения для start-failure-is-fatal
параметра кластера при его значении false
. Это изменение влияет на рабочий процесс отработки отказа. В случае сбоя первичной реплики ожидается, что будет выполнена отработка отказа кластера на одну из доступных вторичных реплик. Вместо этого пользователи замечают, что кластер продолжает пытаться запустить сбой первичной реплики. Если первичная реплика не включается (из-за постоянного сбоя), кластер не выполняет отработку отказа на другую доступную вторичную реплику. Из-за этого изменения ранее рекомендуемая конфигурация start-failure-is-fatal
больше не является допустимой, а параметр должен быть возвращен обратно в значение true
по умолчанию.
Кроме того, нужно обновить ресурс группы доступности для включения свойства failure-timeout
.
Чтобы изменить значение свойства на true
, выполните следующую команду:
sudo crm configure property start-failure-is-fatal=true
Измените существующее свойство failure-timeout
ресурса группы доступности на выполнение 60s
(замените ag1
именем ресурса группы доступности).
sudo crm configure meta failure-timeout=60s
Установка агента ресурсов SQL Server для интеграции с Pacemaker
Выполните следующие команды на всех узлах.
sudo apt-get install mssql-server-ha
Создание учетных данных SQL Server для Pacemaker
Во всех экземплярах SQL Server создайте имя входа сервера для Pacemaker.
Следующий запрос Transact-SQL создает имя для входа:
USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
Во время создания группы доступности пользователю Pacemaker требуются ALTER
CONTROL
разрешения на группу доступности, VIEW DEFINITION
но до добавления в нее всех узлов.
Во всех экземплярах SQL Server сохраните учетные данные для имени входа SQL Server.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
Создание ресурса группы доступности
Чтобы создать ресурс группы доступности, используйте sudo crm configure
команду, чтобы задать свойства ресурса. В следующем примере создается ресурс ocf:mssql:ag
типа первичного или реплики для группы доступности с именем ag1
.
~$ sudo crm
configure
primitive ag1_cluster \
ocf:mssql:ag \
params ag_name="ag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s on-fail=demote interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag1 ag1_cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true"
commit
Примечание.
При создании ресурса и периодически после этого агент ресурсов Pacemaker автоматически задает в группе доступности значение REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
на основе ее конфигурации. Например, если группа доступности содержит три синхронные реплики, агент задаст для REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
значение 1
. Дополнительную информацию и параметры конфигурации см. в разделе High Availability and Data Protection for Availability Group Configurations (Высокий уровень доступности и защита данных для конфигураций групп доступности).
Создание ресурса виртуального IP-адреса
Чтобы создать ресурс виртуального IP-адреса, выполните указанную ниже команду на одном узле. Используйте доступный статический IP-адрес из сети. Перед выполнением этого скрипта замените значения между < ... >
на допустимый IP-адрес.
sudo crm configure primitive virtualip \
ocf:heartbeat:IPaddr2 \
params ip=10.128.16.240
В Pacemaker эквивалент имени виртуального сервера отсутствует. Чтобы использовать строку подключения, указывающую на строковое имя сервера, а не IP-адрес, зарегистрируйте IP-адрес ресурса и требуемое имя виртуального сервера в DNS. Для конфигураций аварийного восстановления зарегистрируйте имя и IP-адрес нужного виртуального сервера на DNS-серверах на основном сайте и сайте аварийного восстановления.
Добавление ограничения совместного размещения
Почти каждое решение в кластере Pacemaker, например выбор места запуска ресурса, принимается путем сравнения оценок. Оценки вычисляются для каждого ресурса, а диспетчер ресурсов кластера выбирает узел с наивысшей оценкой для конкретного ресурса. (Если узел имеет отрицательную оценку для ресурса, последний не может выполняться в этом узле.)
Используйте ограничения для настройки решений в кластере. Ограничения имеют оценку. Если ограничение имеет оценку меньше бесконечности (INFINITY), то это только рекомендация. Оценка, равная INFINITY, указывает на обязательный характер.
Чтобы убедиться, что первичная реплика и ресурс виртуального IP-адреса находятся на одном узле, определите ограничение совместного размещения с оценкой INFINITY. Чтобы добавить ограничение совместного размещения, выполните приведенную ниже команду на одном узле.
sudo crm configure colocation ag-with-listener INFINITY: virtualip-group ms-ag1:Master
Добавление ограничения упорядочения
Ограничение совместного размещения имеет неявное ограничение упорядочения. Оно перемещает ресурс виртуального IP-адреса перед перемещением ресурса группы доступности. Последовательность событий по умолчанию:
Пользователь выполняет команду pcs resource move
с node1
на node2
для первичной реплики группы доступности.
Ресурс виртуального IP-адреса останавливается в node1
.
Ресурс виртуального IP-адреса запускается в node2
.
На этом этапе IP-адрес временно указывает на node2
, пока node2
все еще является вторичной репликой перед отработкой отказа.
Первичная реплика группы доступности на node1
понижается до вторичной.
Вторичная реплика группы доступности на node2
повышается до первичной.
Чтобы предотвратить ситуацию, когда IP-адрес временно указывает на узел с вторичной репликой перед отработкой отказа, добавьте ограничение упорядочения.
Чтобы добавить ограничение упорядочения, выполните приведенную ниже команду в одном узле.
sudo crm configure order ag-before-listener Mandatory: ms-ag1:promote virtualip-group:start
После настройки кластера и добавления группы доступности в качестве ресурса кластера вы не можете использовать Transact-SQL для отработки отказа ресурсов группы доступности. Ресурсы кластера SQL Server в Linux не так сильно зависят от операционной системы, как если бы они находились в отказоустойчивом кластере Windows Server (WSFC). Служба SQL Server не имеет сведений о наличии кластера. Вся оркестрация осуществляется с помощью средств управления кластерами.
Связанный контент