Как сделать кластер линукс
Обновлено: 02.07.2024
Для развертывания кластера используются два подсоединённых к сети компьютера с установленной ОС Astra Linux. Каждый из этих компьютеров будет выполнять роль узла кластера, поэтому далее они будут называться Узел 1 и Узел 2.
Параметры сети:
- Сеть 192.168.23.0/24;
- Адрес маршрутизатора (шлюза) сети 192.168.23.1;
- Предполагается, что в сети отстутствует служба DNS, поэтому адреса узлов задаются с помощью файла /etc/hosts.
Параметры узлов
| Параметр | Узел 1 | Узел 2 |
|---|---|---|
| Имя узла | pcmk-1 | pcmk-2 |
| Статический IP-адрес узла | 192.168.23.101 | 192.168.23.102 |
- В качестве адреса кластера будет использован адрес 192.168.23.100;
- Для тестирования отказоустойчивости используется рабочая станция, подключенная к той же сети;
Настройка сетевого соединения и имен узлов
Присвоить узлу статический IP-адрес 192.168.23.101:
sudo nmcli c d path 1sudo nmcli c m path 1 ip4 192.168.23.101/24 gw4 192.168.23.1
sudo nmcli c m path 1 ipv4.method manual
sudo nmcli c u path 1
Присвоить узлу статический IP-адрес 192.168.23.102:
sudo nmcli c d path 1sudo nmcli c m path 1 ip4 192.168.23.102/24 gw4 192.168.23.1
sudo nmcli c m path 1 ipv4.method manual
sudo nmcli c u path 1
Записать имена узлов в файл /etc/hosts и удалить строку 127.0.1.1:
sudo sed -i '$a 192.168.23.101\tpcmk-1' /etc/hostssudo sed -i '$a 192.168.23.102\tpcmk-2' /etc/hosts
sudo sed -i "/127\.0\.1\.1/d" /etc/hosts
Установить имя узла pcmk-1:
Установить имя узла pcmk-2:
Установка кластерного ПО
Установка кластерного ПО выполняется на каждом узле.Установить пакеты кластерного ПО:
Назначить пользователю hacluster пароль (для примера использован пароль 123):
Инициализация кластера
Собрать кластер (для примера используется имя кластера astracluster):
sudo pcs cluster auth pcmk-1 pcmk-2 -u hacluster -p 123sudo pcs cluster setup --name astracluster pcmk-1 pcmk-2 --force
STONITH (Shoot The Other Node In The Head) - технология отвечающая за физическое устранение узла из кластера обеспечивающая полное обесточивание нееисправных узлов, чтобы исключить повреждение данных. Поскольку в тесте устройства управления электропитанием не зайдествованы, эту возможность удобнее отключить, иначе будет постоянно выдаваться предупреждение, что STONITH не сконфигурирован
На кластерах находящихся в эксплуатации STONITH обязательно должен быть настроен и включён для предотвращения событий, приводящих к повреждению данных. Процедура добавления узла в кластер занимает некоторое время, обычно не более 1 минуты.Посмотреть состояние узлов кластера можно командой:
Если кластер успешно стартовал, то состояние узлов кластера в выводе команды pcs status будет таким:
Проверить правильность конфигурации кластера можно командой:
sudo crm_verify -L
Если конфигурация кластера содержит ошибки, утилита crm_verify о них сообщит.
Если узел кластера выключался/перезагружался, то считается, что узел работает нештатно, и решение о возможности его повторного включения в кластер может принять только человек. Автоматическое включение узлов в кластер не применяется. Для возврата узла в кластер требуется повторно добавить его в кластер, выполнив на нём команду:
Перейти в каталог /tmp:
Установить пакеты PostgreSQL:
Создать базу данных cluster:
Создать в базе данных таблицу info:
sudo -u postgres psql -d cluster -c "CREATE TABLE info (text varchar(80));"Добавить в таблицу запись:
sudo -u postgres psql -d cluster -c "INSERT INTO info VALUES ('Test DB - $(hostname)');"Задать пароль пользователю БД postgres:
sudo -u postgres psql -c "ALTER USER postgres WITH PASSWORD '123';"Разрешить СУБД PostgreSQL принимать внешние подключения:
sudo sed -i '/^listen_addresses/s/localhost/*/' /etc/postgresql/9.6/main/postgresql.confТак как в дальнейшем работой сервиса будет управлять Corosync, следует исключить PostgreSQL из автоматической загрузки:
Перезапустить кластер БД main:
Задать значение глобального таймаута на операции со всеми ресурсами:
На рабочем кластере не рекомендуется использовать глобальный таймаут, следует задавать таймауты для каждой операции у каждого ресурса кластера, исходя из реальных значений временных интервалов, полученных на конкретной аппаратной платформе.Добавить IP-адрес кластра 192.168.23.100 как ресурс ClusterIP:
sudo pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.23.100 cidr_netmask=32 op monitor interval=30sДобавить службу PostgreSQL как ресурс Database:
sudo pcs resource create Database ocf:heartbeat:pgsql \
pgctl="/usr/lib/postgresql/9.6/bin/pg_ctl" \
pgdata="/var/lib/postgresql/9.6/main" \
config="/etc/postgresql/9.6/main/postgresql.conf" \
socketdir="/var/run/postgresql/" \
op monitor interval=1min
"Database должен работать на узле, где размещён ClusterIP":
sudo pcs constraint colocation add Database with ClusterIP INFINITY"Сначала запускается ClusterIP, затем Database":
Тест должен продемонстрировать отказоустойчивость двухузлового кластера Active/Passive
Подготовка теста
Установить клиентский пакет PostgreSQL:
На рабочей станции, находящейся в одной сети с кластером, создать сценарий test-request.sh следующего содержания:
Установить созданному файлу сценария права на исполнение
Сценарий будет отправлять запрос кластеру 1 раз в секунду и выводить полученное содержимое на экран.
Если в данный момент ресурс ClusterIP размещён на узле 1, то вывод сценарий будет таким:
Отключение от сети узла кластера
Найти узел кластера, на котором размещены ресурсы, выполнив команду на любом узле:
На узле с кластерными ресурсами отключить сетевое соединение
Кластерные ресурсы мигрируют на другой узел кластера и вывод скрипта test-request.sh изменится. Например, е сли кластерные ресурсы располагались на узле 1, то после отключения узла 1 от сети, ресурсы переместятся на узел 2.
Включить сетевое соединение на отключённом от сети узле:
и дождаться его возвращение в кластер. После возвращения узла в кластер выполненная на любом из узлов команда
Если вывод команды на разных узлах различается - значит узел еще не вернулся в кластер.
Выключение узла кластера
Найти узел кластера, на котором размещены ресурсы, выполнив команду на любом узле:
Выключить узел с кластерными ресурсами, перезагрузив его:
Кластерные ресурсы мигрируют на другой узел кластера и вывод скрипта test-request.sh изменится.
Если кластерные ресурсы располагались на узле 2, то после выключения узла 2 ресурсы переместятся на узел 1.
Когда выключенный узел загрузится вернуть его в кластер, выполнив на нём команду:
Для управления узлом кластера существует небольшой набор команд, среди которых:mosctl - контроль над узлом. Позволяет изменять параметры узла - такие, как block, stay, lstay, delay и т.д
Давайте рассмотрим несколько параметров этой утилиты:
stay - позволяет останавливать миграцию процессов на другие узлы с текущей машины. Отменяется параметром nostay или -stay
lstay - запрещает только локальным процессам миграцию, а процессы с других машин могут продолжать это делать. Отменяется параметром nolstay или -lstay.
block - запрещает удаленным/гостевым процессам выполнятся на этом узле. Отменяется параметром noblock или -block.
bring - возвращает обратно все процессы с текущего узла выполняемые на других машинах кластера. Этот параметр может не срабатывать, пока мигрировавший процесс не получит прерывание от системы.
setdelay устанавливает время, после которого процесс начинает мигрировать.
Ведь согласитесь - в случае, если время выполнения процесса меньше секунды смысл переносить его на другие машины сети исчезает. Именно это время и выставляется утилитой mosctl с параметром setdecay. Пример:
mosctl setdecay 1 500 200
устанавливает время перехода на другие узлы 500 миллисекунд в случае, если процесс запущен как slow и 200 милисекунд для fast процессов. Обратите внимание, что параметр slow всегда должен быть больше или равен параметру fast.
mosrun - запускает приложение в кластере. например mosrun -e -j5 make запустит make на 5-ом узле кластера, при этом все его дочерние процессы будут также выполнятся на 5-ом узле. Правда здесь есть один нюанс, при чем довольно существенный:
в случае, если дочерние процессы выполняются быстрее чем установленная утилитой mosctl задержка (delay) то процесс не будет мигрировать на другие узлы кластера. у mosrun еще довольно много различных интересных параметров, но подробно узнать
о них вы сможете из руководства по этой утилите. (man mosrun)
mon - как мы уже знаем, это монитор кластера, который в псевдографическом виде отображает загрузку каждого рабочего узла вашего кластера, количество свободной и занятой памяти узлов и выдает много другой, не менее интересной информации.
mtop - модифицированная для использования на узлах кластера версия команды top. Отображает на экране динамическую информацию о процессах, запущенных на данном узле, и узлах, куда мигрировали ваши процессы.
mps - тоже модифицированная версия команды ps. Добавлено еще одно поле - номер узла, на который мигрировал процесс.
Вот на мой взгляд и все основные утилиты. На самом деле конешно можно обойтись даже без них. Например используя для контроля над кластером /proc/mosix.
Там кроме того, что можно найти основную информацию о настройках узла, процессах запущенных с других узлов и т.д.,а также поменять часть параметров.
Давайте рассмотрим один из примеров:
Допустим, что у нас в кластере работают две машины (два узла), один из которых с номером 1 (366 Celeron), другой - с номером 5(PIII450). Экспериментировать мы будем на 5-ом узле. 1-й узел в это время простаивал. ;-)
Итак, запускаем на 5-м узле утилиту crark для подбора пароля к rar архиву.Если кто из вас пробовал работать с подобными утилитами, то он должен знать, что процесс подбора пароля "кушает" до 99 процентов процессора. Ну что же - после запуска мы наблюдаем, что процесс остается на этом, 5-ом узле. Разумно - ведь именно у этого узла производительность превышает 1-й узел почти в два раза.
Далее мы просто запустили сборку kde 2.0. Смотрим таблицу процессов и видим, что crark успешно мигрировал на 1-й узел, освободив процессор и память (да, да - память точно также освобождается) для make. А как только make закончил свою работу - crark вернулся обратно, на родной ему 5-й узел.
Интересный эффект получается, если crark запускать на более медленном 1-м узле.
Там мы наблюдаем практически противоположный результат - процесс сразу-же мигрирует на 5-й, более быстрый узел. При этом он возвращается обратно, когда хозяин пятого компьютера начинает какие-то действия с системой. Давайте в конце разберемся, зачем и как мы можем использовать кластер в своей повседневной жизни.
Для начала нужно раз и навсегда запомнить - кластер выгоден только в том случае, когда в вашей сети есть энное количество машин, которые частенько простаивают и вы хотите использовать их ресурсы например для сборки KDE или для любых серьезных процессов. Ведь благодаря кластеру из 10 машин можно одновременно
компилировать до 10 тяжелых программ на том-же C++. Или подбирать какой-то пароль,
не прекращая ни на секунду этого процесса независимо от нагрузки на ваш компьютер.
Да и вообще - это просто интересно ;-).
В заключение хочу сказать, что в этой статье не рассмотрены все возможности MOSIX, т.к. я просто до них еще не добрался. Если доберусь - ждите продолжения. :-)
Сил моих больше нет! Ткните, пожалуйста, носом - где подробно описывается создание отказоустойчивого кластера из серверов на ,допустим, Дебиане. И описывается подробно его работа. P.S. Прошу сильно не пинать.
Последнее исправление: geladil 11.06.13 20:30:46 (всего исправлений: 1)
Ок. Как сделать так, чтобы при краше одного сервера, его задачи автоматически начал выполнять другой сервер? Без потерь данных и задержек.
Ок. Как сделать так, чтобы при краше одного сервера, его задачи автоматически начал выполнять другой сервер? Без потерь данных и задержек.
Зависит от задач. Я как раз на debian сделал 3 кластера для виртуалок на kvm. Бегает и прыгает на heartbeat/drbd.
А без задач нельзя? Ну, допустим задача - хостинг.
А без задач нельзя? Ну, допустим задача - хостинг.
Без правильно заданного вопроса - ты не получишь нужного тебе ответа.
I. Варианты организации системы хранения данных
DRBD репликация блочных устройств. Кластер высокой доступности с использование сетевой репликации блочных устройств на основе DRBD технологии. Данный метод позволяет в реальном масштабе времени синхронизировать жесткие диски компьютера. В результате чего в любой момент времени имеется полная копия данных на вторичной машине. Выключив первичную машину сможем, без лишних движений, начать работу на вторичной машине, с места разъединения. Данная технология накладывает ограничения на кол-во узлов кластера. Кол-во узлов не может быть более 2-х. При не верном конфигурировании и обслуживании возможны ситуации splitbrain (расщепления сознания). Ситуация проявляется когда оба узла считают себя главными. Данную ситуации необходимо разрешать исходя из конкретно сложившихся условий расщепления.
Зеркальный рейд из нескольких СХД. Кластер высокой доступности с использованием СХД. Система Хранения Данных - это отдельно выделенный специализированный сервер, способный отдавать по сети жесткие диски в качестве блочных устройств. Для данного метода необходимо, помимо двух узлов кластера, наличие двух СХД. Отказоустойчивость дисковой подсистемы достигается за счет применения на каждой виртуальной машине зеркального рейда собранного из разных физических СХД. В данном подходе при выходе из строя первичного узла кластера работа будет переключена на второй узел, а при выходе из строя одного СХД работа перемещается на второй. Данный вариант превосходит первый по маштабируемости. Возможно подключение более чем 2 узлов кластера, более чем двух СХД, за счет чего возможно увеличивать коэффициент отказоустойчивости.
II. Автоматизация управления ресурсами кластера
Для управления ресурсами кластера подразумевается использование проекта Pacemaker. Данная технология обучается тому, что и по каким условиям, должно располагаться и функционировать в кластере. Технология в следствии программирования может быть обучена любому поведению.
III. Автоматизация failover
Для надежного аварийного переключения, в любой момент времени, все узлы кластера должны знать о своем общем состоянии. Это возможно решить с помощью технологии Сorosync. Данная технология в составе Pacemaker способна с высокой точность определять доступность сервиса и настаивать на перераспределении ресурсов.
Величины непрерывности В следствии failover, когда несущий узел прекращает функционирование, простой в работе определяется формулой:
Для пользователей будет выглядеть как перезагрузка сервера.В штатных ситуациях, в условиях доступности несущего узла переключение возможно намного эффективнее:
Этот документ описывает, как создать кластер с тремя узлами в Ubuntu 20.04 и добавить в него ранее созданную группу доступности в качестве ресурса. Для обеспечения высокого уровня доступности группе доступности в Linux требуется три узла — см. статью Высокий уровень доступности и защита данных для конфигураций групп доступности.
На этом этапе интеграция SQL Server с Pacemaker в Linux реализована не на таком уровне, как с WSFC в Windows. Внутри SQL сведения о наличии кластера отсутствуют, вся оркестрация осуществляется снаружи, а сама служба управляется Pacemaker как автономный экземпляр. Кроме того, имя виртуальной сети относится только к WSFC. В Pacemaker его эквивалент отсутствует. Динамические административные представления Always On, запрашивающие сведения о кластере, возвращают пустые строки. Вы по-прежнему можете создать прослушиватель, чтобы использовать его для прозрачного переподключения после отработки отказа, но требуется вручную зарегистрировать имя прослушивателя на DNS-сервере с IP, использованным для создания ресурса виртуального IP-адреса (как описано в следующих разделах).
В следующих разделах описаны действия по настройке решения отказоустойчивого кластера.
Схема действий
Действия по созданию группы доступности на серверах Linux для обеспечения высокой доступности отличаются от действий, выполняемых в отказоустойчивом кластере Windows Server. Ниже описывается общий порядок действий.
Настройте диспетчер ресурсов кластера, например Pacemaker. Эти инструкции приведены в этом документе.
Способ настройки диспетчера ресурсов кластера зависит от конкретного дистрибутива Linux.
Для обеспечения высокого уровня доступности в рабочих средах требуется агент ограждения, например STONITH. В примерах в этой документации агенты ограждения не используются. Примеры приводятся только для тестирования и проверки.
Кластер Linux использует ограждение для возврата кластера в известное состояние. Способ настройки ограждения зависит от дистрибутива и среды. В настоящее время ограждение недоступно в некоторых облачных средах. Дополнительные сведения см. в статье о политиках поддержки для кластеров RHEL с высоким уровнем доступности на платформах виртуализации.
Ограждение обычно реализуется в операционной системе и зависит от среды. Инструкции по установке ограждений см. в документации распространителя операционной системы.
Установка и настройка Pacemaker в каждом узле кластера
Откройте порты брандмауэра на всех узлах. Откройте порт для службы высокой доступности Pacemaker, экземпляра SQL Server и конечной точки группы доступности. TCP-порт по умолчанию для сервера, где выполняется SQL Server, имеет значение 1433.
Кроме того, можно просто отключить брандмауэр.
Установите пакеты Pacemaker. Выполните следующие команды на всех узлах.
Задайте пароль для пользователя по умолчанию, который создается при установке пакетов Pacemaker и Corosync. Используйте на всех узлах один и тот же пароль.
Включение и запуск службы pcsd и Pacemaker
Следующая команда включает и запускает службу pcsd и Pacemaker. Выполните ее на всех узлах. Это позволяет узлам повторно подключаться к кластеру после перезагрузки.
Команда включения Pacemaker может завершиться с ошибкой "pacemaker Default-Start contains no runlevels, aborting" (pacemaker Default-Start не содержит уровни выполнения, прерывание). Она безвредна и позволяет продолжить настройку кластера.
Создание кластера
Удалите любые существующие конфигурации кластера со всех узлов.
Команда sudo apt-get install pcs одновременно устанавливает pacemaker, corosync и pcs и запускает все 3 эти службы. При запуске corosync создается файл шаблона /etc/cluster/corosync.conf. Для успешного выполнения дальнейших действий этот файл должен отсутствовать, поэтому можно остановить выполнение pacemaker/corosync и удалить /etc/cluster/corosync.conf, тогда дальнейшие действия пройдут успешно. Команда pcs cluster destroy делает то же самое, и вы можете использовать ее в качестве средства однократной начальной настройки кластера.
Следующая команда удаляет все существующие файлы конфигурации кластера и останавливает все службы кластера. Это приводит к окончательному уничтожению кластера. Запустите ее в качестве первого шага в подготовительной среде. Обратите внимание, что команда pcs cluster destroy отключает службу pacemaker, которую требуется снова включить. Выполните на всех узлах следующую команду.
Команда уничтожает все существующие ресурсы кластера.
Из-за известной проблемы, изучением которой уже занимается поставщик услуг кластеризации, при запуске кластера (pcs cluster start) возникает указанная ниже ошибка. Это связано с тем, что файл журнала, который настроен в /etc/corosync/corosync.conf и создается при выполнении команды установки кластера, является неверным. Чтобы обойти эту ошибку, измените файл журнала на /var/log/corosync/corosync.log. Кроме того, можно создать файл /var/log/cluster/corosync.log.
Указанная ниже команда создает кластер с тремя узлами. Перед выполнением данного сценария замените значения между < . > . Выполните следующую команду на первичном узле.
Если кластер был настроен ранее на тех же узлах, используйте параметр --force при выполнении команды pcs cluster setup. Обратите внимание, что это эквивалентно команде pcs cluster destroy. Службу Pacemaker необходимо включить повторно с помощью команды sudo systemctl enable pacemaker.
Настройка ограждения (STONITH)
Поставщики кластера Pacemaker требуют, чтобы STONITH был включен, а устройство ограждения настроено для поддерживаемой установки кластера. Если диспетчер ресурсов кластера не может определить состояние узла или ресурса в нем, для перевода кластера в известное состояние используется ограждение. Ограждение на уровне ресурсов гарантирует отсутствие повреждений данных в случае сбоя за счет настройки ресурса. Вы можете использовать ограждение на уровне ресурсов, например с распределенным реплицируемым блочным устройством (DRBD), чтобы пометить диск в узле как устаревший при отключении канала связи. Ограждение на уровне узлов гарантирует, что в узле не выполняются никакие ресурсы. Это осуществляется путем сброса узла, а соответствующая реализация для Pacemaker называется STONITH (что дословно расшифровывается как "застрелить другой узел"). Pacemaker поддерживает множество разных устройств ограждения, например источник бесперебойного питания или карты интерфейса управления для серверов. Дополнительные сведения см. в статьях Кластеры Pacemaker с нуля и Ограждение и Stonith
Так как конфигурация ограждения на уровне узлов сильно зависит от вашей среды, мы отключим ее для этого руководства (ее можно настроить позже). Запустите следующий скрипт на первичном узле.
Отключение STONITH выполняется только в целях тестирования. Если вы планируете использовать Pacemaker в рабочей среде, следует спланировать реализацию STONITH с учетом особенностей среды и поддерживать ее в рабочем состоянии. Обратитесь к поставщику операционной системы за информацией об агентах ограждения для любого конкретного распределения.
Задание свойства кластера 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 , выполните следующую команду:
Чтобы изменить значение свойства на true , выполните следующую команду:
Измените существующее свойство failure-timeout ресурса группы доступности на выполнение 60s (замените ag1 именем ресурса группы доступности).
Установка агента ресурсов SQL Server для интеграции с Pacemaker
Выполните следующие команды на всех узлах.
Создание учетных данных SQL Server для Pacemaker
На всех серверах SQL Server создайте имя для входа на сервер с помощью Pacemaker. Следующий запрос Transact-SQL создает имя для входа:
При создании группы доступности пользователю Pacemaker потребуются разрешения на изменение, управление и просмотр определения для группы доступности после ее создания, но до того, как в нее будут добавлены узлы.
На всех серверах SQL Server сохраните учетные данные для входа SQL Server.
Создание ресурса группы доступности
Чтобы создать ресурс группы доступности, используйте команду pcs resource create и задайте свойства ресурса. Приведенная ниже команда ocf:mssql:ag создает ресурс типа «основной/подчиненный» для группы доступности ag1 .
При создании ресурса и периодически после этого агент ресурсов 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-адрес.
В Pacemaker эквивалент имени виртуального сервера отсутствует. Чтобы использовать строку подключения, указывающую на строковое имя сервера, а не IP-адрес, зарегистрируйте IP-адрес ресурса и требуемое имя виртуального сервера в DNS. Для конфигураций аварийного восстановления зарегистрируйте имя и IP-адрес нужного виртуального сервера на DNS-серверах на основном сайте и сайте аварийного восстановления.
Добавление ограничения совместного размещения
Почти каждое решение в кластере Pacemaker, например выбор места запуска ресурса, принимается путем сравнения оценок. Оценки вычисляются для каждого ресурса, а диспетчер ресурсов кластера выбирает узел с наивысшей оценкой для конкретного ресурса. (Если узел имеет отрицательную оценку для ресурса, последний не может выполняться в этом узле.) Используйте ограничения для настройки решений в кластере. Ограничения имеют оценку. Если ограничение имеет оценку меньше бесконечности (INFINITY), то это только рекомендация. Оценка, равная INFINITY, указывает на обязательный характер. Чтобы убедиться, что первичная реплика и ресурс виртуального IP-адреса находятся на одном узле, определите ограничение совместного размещения с оценкой INFINITY. Чтобы добавить ограничение совместного размещения, выполните приведенную ниже команду на одном узле.
Добавление ограничения упорядочения
Ограничение совместного размещения имеет неявное ограничение упорядочения. Оно перемещает ресурс виртуального IP-адреса перед перемещением ресурса группы доступности. Последовательность событий по умолчанию:
Пользователь выполняет команду pcs resource move с узла node1 на узел node2 для первичной реплики группы доступности.
Ресурс виртуального IP-адреса останавливается на node1.
Ресурс виртуального IP-адреса запускается на node2.
На этом этапе IP-адрес временно указывает на node2, пока node2 все еще является вторичной репликой перед отработкой отказа.
Первичная реплика группы доступности на node1 понижается до вторичной.
Вторичная реплика группы доступности на node2 повышается до первичной.
Чтобы предотвратить ситуацию, когда IP-адрес временно указывает на узел с вторичной репликой перед отработкой отказа, добавьте ограничение упорядочения.
Чтобы добавить ограничение упорядочения, выполните приведенную ниже команду в одном узле.
После настройки кластера и добавления группы доступности в качестве ресурса кластера вы не можете использовать Transact-SQL для отработки отказа ресурсов группы доступности. Ресурсы кластера SQL Server в Linux не так сильно зависят от операционной системы, как если бы они находились в отказоустойчивом кластере Windows Server (WSFC). Служба SQL Server не имеет сведений о наличии кластера. Вся оркестрация осуществляется с помощью средств управления кластерами. В RHEL или Ubuntu используйте pcs .
Читайте также: