Wiki source code of Отказоустойчивый кластер Платформы НЕЙРОСС

Last modified by superadmin on 2026/06/24 21:40

version	line-number	content
5.1	1	В данном разделе приведена пошаговая инструкция по развёртыванию кластера «с нуля», обеспечивающего базовую функциональность горячего резервирования сервера Платформы НЕЙРОСС с нативным типом установки (в среде ОС).
1.1	2
	3	{{info}}
	4	Ниже рассмотрен пример построения кластера при работе нативной версии в среде ОС Ubuntu Server 20.04.3 LTS. При необходимости разворачивания кластера в среде ОС Astra Linux рекомендуем обратиться к специалистам компании ИТРИУМ, мы вышлем подготовленный файл.
	5	{{/info}}
	6
	7	{{error}}
	8	При необходимости горячего резервирования контейнеризированной версии Платформы НЕЙРОСС рекомендуем обратиться к специалистам компании ИТРИУМ.
	9	{{/error}}
	10
5.1	11	== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Общиесведения"/}}Общие сведения(%%) ==
1.1	12
5.1	13	Отказоустойчивый кластер обеспечивает высокий уровень готовности резервного сервера для максимальной доступности сервисов системы. Самый простой кластер состоит из 2-х узлов (компьютеров, серверов), образующих его, настроенных на мониторинг друг друга и управление соответствующими ресурсами кластера.
1.1	14
	15	[[image:attach:Platform_Cluster_Scheme.png\|\|width="400"]]
	16
	17	\\
	18
	19	Для настройки кластера и его ресурсов можно применять любую из двух утилит //pcs// или //crm//. При этом настройку можно осуществлять и той и другой в любом удобном порядке, поэтому некоторые действия описаны с использование одной утилиты, а некоторые – другой.
	20
5.1	21	== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Действиянакаждомсервере(NODE1иNODE2)"/}}Действия на каждом сервере (NODE 1 и NODE2)(%%) ==
1.1	22
5.1	23	Актуализируйте и обновите версии пакетов:
1.1	24
	25	{{code language="bash"}}
	26	sudo apt update
	27	sudo apt upgrade
	28
	29	{{/code}}
	30
	31	Установите программные средства, необходимые для работы Платформы НЕЙРОСС (на момент написания страницы из репозитория инсталлировался PostgreSQL версии 12):
	32
	33	{{code language="bash"}}
	34	sudo apt install postgresql
	35	sudo apt install -y openjdk-8-jdk traceroute
	36	{{/code}}
	37
	38	Установите пакеты //pacemaker// и //corosync//, а также соответствующие необходимые утилиты. Рекомендуется выполнять установку из-под root для правильного создания пользователя //hacluster// и настройки пользовательского доступа.
	39
	40	{{code language="bash"}}
	41	sudo su
	42	apt install pacemaker pcs resource-agents fence-agents corosync ntp rsync
	43	exit
	44
	45	{{/code}}
	46
	47	Укажите в файле //hosts// IP-адреса всех узлов кластера в явном виде:
	48
	49	{{code language="bash"}}
	50	sudo nano /etc/hosts
	51	10.1.30.251 node1
	52	10.1.30.252 node2
	53	{{/code}}
	54
	55	Настройте службу синхронизации времени на сервер точного времени, перезапустите службу, проверьте работу, выполнив последовательно команды ниже:
	56
	57	{{code language="bash"}}
	58	sudo nano /etc/ntp.conf
	59	sudo systemctl restart ntp
	60	sudo ntpq -p
	61
	62	{{/code}}
	63
	64	Проверьте наличие пользователя //hacluster// (его создает //pacemaker// в процессе установки):
	65
	66	{{code language="bash"}}
	67	sudo cat /etc/passwd \| grep hacluster
	68	{{/code}}
	69
	70	Вывод команды приведён в коде ниже:
	71
2.1	72	{{code language="java"}}
1.1	73	hacluster:x:113:117::/var/lib/pacemaker:/usr/sbin/nologin
	74	{{/code}}
	75
	76	Измените пароль пользователя //hacluster// (ниже код на примере пароля 123456)
	77
	78	{{code language="bash"}}
	79	sudo passwd hacluster
	80	123456
	81	123456
	82
	83	{{/code}}
	84
	85	\\
	86
	87	{{info}}
	88	Пакет //resource-agents,// устанавливаемый из стандартного репозитория, имеет версию ниже 4.8.0, и значит в нём не исправлена несовместимость с PostgreSQL 12 в части мониторинга 'WAL receiver process'.
	89	Решением является установка пакета версии 4.8.0 и выше или исправление соответствующего файла руками (на обоих серверах).
	90
	91	Для откройте для редактирование файл //pgsql//:
	92
	93	{{code language="bash"}}
	94	sudo nano /usr/lib/ocf/resource.d/heartbeat/pgsql
	95
	96	{{/code}}
	97
	98	Найдите строку:
	99
2.1	100	{{code language="java"}}
1.1	101	receiver_parent_pids=`ps -ef \| tr -s " " \| grep "[w]al receiver process" \| cut -d " " -f 3`
	102	{{/code}}
	103
	104	И замените её на:
	105
2.1	106	{{code language="java"}}
1.1	107	receiver_parent_pids=`ps -ef \| tr -s " " \| grep "[w]al\s*receiver" \| cut -d " " -f 3`
	108	{{/code}}
	109
	110	Чтобы сохранить изменения и выйти выполните ^O и ^X.
	111	{{/info}}
	112
	113
	114	Добавьте в автозагрузку и запустите службу конфигурации //pacemaker~://
	115
	116	{{code language="bash"}}
	117	sudo systemctl enable pcsd.service
	118	sudo systemctl start pcsd.service
	119	{{/code}}
	120
	121	== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Действиянапервомузле(NODE1)"/}}Действия на первом узле (NODE1) ==
	122
	123	Определите авторизацию на узлах (имена узлов //node1// и //node2//) под пользователем //hacluster//:
	124
	125	{{code language="bash"}}
	126	sudo pcs cluster auth node1 addr=10.1.30.251 node2 addr=10.1.30.252 -u hacluster -p 123456
	127	{{/code}}
	128
	129	Если команда не выполнилась (это может зависеть от версии //pacemaker//), то выполните:
	130
	131	{{code language="bash"}}
	132	sudo pcs host auth node1 addr=10.1.30.251 node2 addr=10.1.30.252 -u hacluster -p 123456
	133	{{/code}}
	134
	135	Создайте кластер с именем //HACLUSTER// из двух узлов:
	136
	137	{{code language="bash"}}
	138	sudo pcs cluster setup HACLUSTER node1 addr=10.1.30.251 node2 addr=10.1.30.252
	139	{{/code}}
	140
	141	Если возникают ошибки с текстом "...//the host seems to be in a cluster already//...", то необходимо выполнить:
	142
	143	{{code language="bash"}}
	144	sudo pcs cluster setup --force HACLUSTER node1 addr=10.1.30.251 node2 addr=10.1.30.252
	145	{{/code}}
	146
	147	При необходимости проверить конфигурацию (на всех серверах должен быть файл с одинаковым содержимым) выполните:
	148
2.1	149	{{code language="java"}}
1.1	150	cat /etc/corosync/corosync.conf
	151	totem {
	152	version: 2
	153	cluster_name: HACLUSTER
	154	transport: knet
	155	crypto_cipher: aes256
	156	crypto_hash: sha256
	157	}
	158
	159	nodelist {
	160	node {
	161	ring0_addr: 10.1.30.251
	162	name: node1
	163	nodeid: 1
	164	}
	165
	166	node {
	167	ring0_addr: 10.1.30.252
	168	name: node2
	169	nodeid: 2
	170	}
	171	}
	172
	173	quorum {
	174	provider: corosync_votequorum
	175	two_node: 1
	176	}
	177
	178	logging {
	179	to_logfile: yes
	180	logfile: /var/log/corosync/corosync.log
	181	to_syslog: yes
	182	timestamp: on
	183	}
	184	{{/code}}
	185
	186	Включите и запустите все кластеры на всех узлах:
	187
	188	{{code language="bash"}}
	189	sudo pcs cluster enable --all
	190	sudo pcs cluster start --all
	191
	192	{{/code}}
	193
	194
	195	При использовании двух узлов включите //stonith//. Он нужен для «добивания» серверов, которые не смогли полностью завершить рабочие процессы, игнорируйте кворум:
	196
	197	{{code language="bash"}}
	198	sudo pcs property set stonith-enabled=true
	199	sudo pcs property set no-quorum-policy=ignore
	200	{{/code}}
	201
	202	Без сконфигурированного //stonith// кластер не начнёт управлять ресурсами. Поэтому, в этом месте для простоты старта работы кластера сначала можно выключить //stonith~://
	203
	204	{{code language="bash"}}
	205	sudo pcs property set stonith-enabled=false
	206	{{/code}}
	207
	208	Потом, когда будет сконфигурирован //stonith//, включить его обратно (описано ниже) для обеспечения фенсинга.
	209	\\Запросите статус на обоих узлах:
	210
	211	{{code language="bash"}}
	212	sudo pcs status
	213	{{/code}}
	214
	215	В случае //stonith-enabled=true// вы увидите:
	216
2.1	217	{{code language="java"}}
1.1	218	Cluster name: HACLUSTER
	219
	220	WARNINGS:
	221	No stonith devices and stonith-enabled is not false
	222
	223	Cluster Summary:
	224	* Stack: corosync
	225	* Current DC: node1 (version 2.0.3-4b1f869f0f) - partition with quorum
	226	* Last updated: Wed Oct 20 14:06:00 2021
	227	* Last change: Wed Oct 20 14:05:17 2021 by root via cibadmin on node1
	228	* 2 nodes configured
	229	* 0 resource instances configured
	230
	231	Node List:
	232	* Online: [ node1 node2 ]
	233
	234	Full List of Resources:
	235	* No resources
	236
	237	Daemon Status:
	238	corosync: active/enabled
	239	pacemaker: active/enabled
	240	pcsd: active/enabled
	241	{{/code}}
	242
	243	\\
	244
	245	{{info}}
	246	Для мониторинга (отслеживания) состояния кластера в реальном времени можно использовать команду на любом из узлов:
	247
	248	{{code language="bash"}}
	249	sudo crm_mon -Afr
	250	{{/code}}
	251	{{/info}}
	252
	253
	254	Добавьте виртуальный сетевой адрес как ресурс (помним про тайм-ауты) кластера с именем //virtual_ip//, который и будет основным адресом платформы НЕЙРОСС:
	255
	256	{{code language="bash"}}
	257	sudo pcs resource create virtual_ip ocf:heartbeat:IPaddr2 ip=10.1.30.250 cidr_netmask=13 meta migration-threshold="0" \
	258	op monitor timeout="60s" interval="10s" on-fail="restart" \
	259	op stop timeout="60s" interval="0s" on-fail="ignore" \
	260	op start timeout="60s" interval="0s" on-fail="stop"
	261	{{/code}}
	262
	263
	264	Отключите запуск //postgresql.service// при загрузке системы. Включать и отключать сервис при необходимости теперь будет //pacemaker//.
	265
	266	{{code language="bash"}}
	267	sudo systemctl disable postgresql.service
	268	{{/code}}
	269
	270
	271	На узле (в нашем случае это node1), который первоначально будет являться Мастером, инициализируйте новую базу данных:
	272
	273	{{code language="bash"}}
	274	sudo -u postgres /usr/lib/postgresql/12/bin/initdb -D /var/lib/postgresql/12/main
	275	{{/code}}
	276
	277	Если база уже запущена, то остановите процесс //postgresql//, очистите директорию ///var/lib/postgresql/12/main//
	278
	279	{{code language="bash"}}
	280	sudo systemctl stop postgresql.service
	281	sudo su - postgres
	282	rm -rf /var/lib/postgresql/12/main/*
	283	{{/code}}
	284
	285	и выполните команду инициализации новой базы ещё раз.
	286	\\Запустите СУБД PostgreSQL:
	287
	288	{{code language="bash"}}
	289	sudo -u postgres /usr/lib/postgresql/12/bin/pg_ctl -D /var/lib/postgresql/12/main start
	290	{{/code}}
	291
	292	Создайте пользователя для репликации базы:
	293
	294	{{code language="bash"}}
	295	sudo -u postgres /usr/lib/postgresql/12/bin/createuser --replication -P repl
	296	{{/code}}
	297
	298	Установите пароль, например, //12345.//
	299	\\Откройте на редактирование файл ///var/lib/postgresql/12/main/pg_hba.conf~://
	300
	301	{{code language="bash"}}
	302	sudo -u postgres nano /var/lib/postgresql/12/main/pg_hba.conf
	303	{{/code}}
	304
	305	Добавьте в него необходимые разрешения следующим образом:
	306
2.1	307	{{code language="java"}}
1.1	308	# TYPE DATABASE USER ADDRESS METHOD
	309	# "local" is for Unix domain socket connections only
	310	local all all trust
	311	# IPv4 local connections:
	312	host all all 127.0.0.1/32 trust
	313	# IPv6 local connections:
	314	host all all ::1/128 trust
	315	# Allow replication connections from localhost, by a user with the
	316	# replication privilege.
	317	local replication all trust
	318	host replication all 127.0.0.1/32 trust
	319	host replication all ::1/128 trust
	320	host replication all 10.0.0.0/13 trust
	321	host all all 10.0.0.0/13 trust
	322	{{/code}}
	323
	324	Сохраните изменения.
	325
	326
	327	Откройте на редактирование файл ///var/lib/postgresql/12/main/postgresql.conf~://
	328
	329	{{code language="bash"}}
	330	sudo -u postgres nano /var/lib/postgresql/12/main/postgresql.conf
	331	{{/code}}
	332
	333	Добавьте (или расскомментируйте) следующие строки:
	334
2.1	335	{{code language="java"}}
1.1	336	listen_addresses = '*'
	337	wal_level = replica
	338	logging_collector = on
	339	hot_standby = on
	340	wal_keep_segments = 10
	341	{{/code}}
	342
	343
	344	Перезапустите СУБД PostgreSQL:
	345
	346	{{code language="bash"}}
	347	sudo -u postgres /usr/lib/postgresql/12/bin/pg_ctl -D /var/lib/postgresql/12/main stop
	348	sudo -u postgres /usr/lib/postgresql/12/bin/pg_ctl -D /var/lib/postgresql/12/main start
	349	{{/code}}
	350
	351
	352	Выполните установку Платформы НЕЙРОСС на этом узле и пройдите этапы первого запуска по адресу //10.1.30.250.//
	353
	354	{{error}}
	355	Во избежание в момент перезагрузки узла node1 перехвата общего адреса узлом node2 перед выполнением сохранения параметров и перезапуска узла node1 останавливаем узел node2 и запускаем только после начала включения узла node1.
	356	{{/error}}
	357
	358	\\
	359
	360	== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Навторомузле(NODE2)"/}}На втором узле (NODE2) ==
	361
	362	Отключите запуск //postgresql.service// при загрузке системы. Включать и отключать сервис при необходимости теперь будет //pacemaker//.
	363
	364	{{code language="bash"}}
	365	sudo systemctl disable postgresql.service
	366	{{/code}}
	367
	368	Остановите процесс //postgresql//, если он ещё запущен.
	369	Очистите директорию ///var/lib/postgresql/12/main/~://
	370
	371	{{code language="bash"}}
	372	sudo systemctl stop postgresql.service
	373	sudo su - postgres
	374	rm -rf /var/lib/postgresql/12/main/*
	375	{{/code}}
	376
	377	Скопируйте базу данных с NODE1 при помощи команды:
	378
	379	{{code language="bash"}}
	380	pg_basebackup -U postgres -D /var/lib/postgresql/12/main -h 10.1.30.251 -X stream -P
	381	exit
	382	{{/code}}
	383
	384	В результате в директории ///var/lib/postgresql/12/main// узла //node2// появится содержимое директории ///var/lib/postgresql/12/main// узла NODE1//.
	385	//
	386	Установите Платформу НЕЙРОСС на этом узле и __не проходите__ этап первого запуска.
	387	Отключите запуск //ultima-vmc.service// при загрузке системы на этом узле кластера. Включать и отключать сервис при необходимости теперь будет //pacemaker//.
	388
	389	{{code language="bash"}}
	390	sudo systemctl stop ultima-vmc.service
	391	sudo systemctl disable ultima-vmc.service
	392	{{/code}}
	393
	394	== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-ПродолжениенаузлеNODE1"/}}Продолжение на узле NODE1 ==
	395
	396	Создайте ресурс с именем //HA-pgsql// типа //pgsql// для управления конфигурацией PostgreSQL:
	397
	398	{{code language="bash"}}
	399	sudo pcs resource create HA-pgsql pgsql pgctl="/usr/lib/postgresql/12/bin/pg_ctl" \
	400	psql="/usr/lib/postgresql/12/bin/psql" \
	401	pgdata="/var/lib/postgresql/12/main" rep_mode="sync" \
	402	node_list="node1 node2" master_ip="10.1.30.250" \
	403	restart_on_promote="false" check_wal_receiver="true" pgport="5432" \
	404	primary_conninfo_opt="password=12345" repuser="repl"
	405	{{/code}}
	406
	407	В некоторых описаниях настройки упоминается ещё параметр config="/etc/postgresql/12/main/postgresql.conf".
	408
	409	{{info}}
5.1	410	Если не выполнено исправление //resource-agents// (описано выше), то настройка параметра //check_wal_receiver="true"//, приведёт на узле NODE2 к появлению ошибки в //HA-pgsql-receiver-status// (вывод команды //sudo crm_mon -Afr//) и ежеминутных предупреждений в логах //(journalctl -f) "WARNING: wal receiver process is not running//". Настройка параметра(%%)// check_wal_receiver="false"// отключает проверку и мониторинг 'WAL receiver process'.
1.1	411	{{/info}}
	412
	413
	414	\\Для созданного выше ресурса//HA-pgsql //укажите, что он может иметь одно из нескольких состояний и менять их в зависимости от типа узла (master и slave):
	415
	416	{{code language="bash"}}
	417	sudo pcs resource promotable HA-pgsql promoted-max=1 promoted-node-max=1 clone-max=2 clone-node-max=1 notify=true
	418	{{/code}}
	419
	420
	421	Создайте связь двух созданных выше ресурсов (//HA-pgsql// и //virtual_ip//), чтобы они запускались вместе на одном узле, и установите очерёдность запуска таким образом, чтобы ресурс //virtual_ip// запускался только после успешного запуска ресурса //HA-pgsql//. Для этого создайте группу ресурсов //master-group// и добавьте в неё ресурсы:
	422
	423	{{code language="bash"}}
	424	sudo pcs resource group add master-group virtual_ip
	425	sudo pcs constraint colocation add master-group with Master HA-pgsql-clone
	426	sudo pcs constraint order promote HA-pgsql-clone then start master-group symmetrical=false kind=Mandatory
	427	sudo pcs constraint order demote HA-pgsql-clone then stop master-group symmetrical=false kind=Optional
	428	{{/code}}
	429
	430
	431	Отключите запуск //ultima-vmc.service// при загрузке системы на этом узле кластера. Включать и отключать сервис при необходимости теперь будет //pacemaker//.
	432
	433	{{code language="bash"}}
	434	sudo systemctl stop ultima-vmc.service
	435	sudo systemctl disable ultima-vmc.service
	436	{{/code}}
	437
	438	\\
	439
	440	== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-ПродолжениенаузлеNODE2"/}}Продолжение на узле NODE2 ==
	441
	442	Скопируйте файл //application.conf// с узла NODE1 на узел //NODE2//, для этого на NODE2 выполните:
	443
	444	{{code language="bash"}}
	445	scp /usr/share/ultima-vmc/conf/application.conf user@10.1.30.252:/usr/share/ultima-vmc/conf/application.conf
	446	{{/code}}
	447
	448	Скопируйте содержимое каталога ///home/ultima-vmc/// с узла NODE1 на узел NODE2, для этого на NODE2 выполните:
	449
	450	{{code language="bash"}}
	451	sudo scp -r /home/ultima-vmc/* user@10.1.30.252:/home/ultima-vmc/
	452	{{/code}}
	453
	454	Установите в явном виде владельца для скопированных файлов, для этого на NODE2 выполните:
	455
	456	{{code language="bash"}}
	457	sudo chown -R ultima-vmc:ultima-vmc /home/ultima-vmc/
	458	sudo chown ultima-vmc:ultima-vmc /usr/share/ultima-vmc/conf/application.conf
	459	{{/code}}
	460
	461	== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-НаузлеNODE1"/}}На узле NODE1 ==
	462
	463	Создайте ресурс с именем //HA-neyross// типа //systemd// для управления конфигурацией исполняемого сервиса и добавьте созданный ресурс в группу //master-group//, чтобы он запускался вместе на одном узле с другими ресурсами:
	464
	465	{{code language="bash"}}
	466	sudo pcs resource create HA-neyross systemd:ultima-vmc.service \
	467	op monitor OCF_CHECK_LEVEL="0" timeout="20s" interval="10s" \
	468	--group master-group
	469	{{/code}}
	470
	471	Иначе (менее подходящее решение), создайте ресурс с именем HA-neyross типа //anything// для управления конфигурацией исполняемой программы:
	472
	473	{{code language="bash"}}
	474	sudo pcs resource create HA-neyross ocf:heartbeat:anything \
	475	binfile=... cmdline_options=... user=... \
	476	op monitor OCF_CHECK_LEVEL="0" timeout="20s" interval="10s" \
	477	--group master-group
	478	{{/code}}
	479
5.1	480	в параметрах (%%)//binfile//, (%%)//cmdline_options// и (%%)//user// укажите соответственно исполняемый файл с полным путём от корня, параметры запуска исполняемого файла, имя пользователя системы (от имени которого будет выполняться файл), всё указывается в кавычках(%%)
	481	параметры (%%)//cmdline_options// и (%%)//user// не являются обязательными
1.1	482
	483	== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Созданиересурсафенсинга"/}}Создание ресурса фенсинга ==
	484
	485	Для защиты разделяемых ресурсов и изоляции узла кластера при его неисправности существует механизм фенсинга (изоляции).
	486	Чтобы вывести список доступных агентов изоляции //fence-agents// используйте команду:
	487
2.1	488	{{code language="java"}}
1.1	489	sudo pcs stonith list
	490	{{/code}}
	491
	492
	493	Для тестовых целей можно использовать следующую конфигурацию с агентом //external/ssh//:
	494
2.1	495	{{code language="java"}}
1.1	496	sudo crm
	497	configure
	498	primitive st-ssh stonith:external/ssh params hostlist="node1 node2"
	499	clone fencing st-ssh
	500	property stonith-enabled=true
	501	commit
	502	exit
	503	{{/code}}
	504
	505	\\
	506
	507	== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Заключение"/}}Заключение ==
	508
	509	Финальный вывод команды мониторинга
	510
	511	{{code language="bash"}}
	512	sudo crm_mon -Afr
	513	{{/code}}
	514
	515	выглядит следующим образом:
	516
2.1	517	{{code language="java"}}
1.1	518	Cluster Summary:
	519	* Stack: corosync
	520	* Current DC: node1 (version 2.0.3-4b1f869f0f) - partition with quorum
	521	* Last updated: Mon Nov 1 17:02:05 2021
	522	* Last change: Mon Nov 1 16:54:44 2021 by root via crm_attribute on node1
	523	* 2 nodes configured
	524	* 6 resource instances configured
	525
	526	Node List:
	527	* Online: [ node1 node2 ]
	528
	529	Full List of Resources:
	530	* Clone Set: HA-pgsql-clone [HA-pgsql] (promotable):
	531	* Masters: [ node1 ]
	532	* Slaves: [ node2 ]
	533	* Resource Group: master-group:
	534	* virtual_ip (ocf::heartbeat:IPaddr2): Started node1
	535	* HA-neyross (systemd:ultima-vmc.service): Started node1
	536	* Clone Set: fencing [st-ssh]:
	537	* Started: [ node1 node2 ]
	538
	539	Node Attributes:
	540	* Node: node1:
	541	* HA-pgsql-data-status : LATEST
	542	* HA-pgsql-master-baseline : 00000000077D6EF8
	543	* HA-pgsql-receiver-status : normal (master)
	544	* HA-pgsql-status : PRI
	545	* master-HA-pgsql : 1000
	546	* Node: node2:
	547	* HA-pgsql-data-status : STREAMING\|SYNC
	548	* HA-pgsql-receiver-status : normal
	549	* HA-pgsql-status : HS:sync
	550	* master-HA-pgsql : 100
	551
	552	Migration Summary:
	553
	554	{{/code}}
	555
	556	//HA-pgsql-status//
	557	PRI – состояние мастера
	558	HS:sync – синхронная реплика
	559	HS:async – асинхронная реплика
	560	HS:alone – реплика не может подключится к мастеру
	561	STOP – PostgreSQL остановлен
	562	//HA-pgsql-data-status//
	563	LATEST – состояние, присущее мастеру. Данный узел является мастером.
	564	STREAMING:SYNC/ASYNC – показывает состояние репликации и тип репликации (SYNC/ASYNC)
	565	DISCONNECT – реплика не может подключиться к мастеру. Обычно такое бывает, когда нет соединения от реплики к мастеру.
	566	//HA-pgsql-master-baseline//
	567	Показывает линию времени. Линия времени меняется каждый раз после выполнения команды promote на узле-реплике. После этого СУБД начинает новый отсчет времени.
	568	//HA-pgsql-receiver-status//
	569	normal (master) – состояние, присущее мастеру. Данный узел является мастером.
	570	normal – нормальное состояние, присущее узлу-реплике. На ведомом устройстве запущен и работает процесс приёмника WAL.
	571	Error – на ведомом устройстве не работает процесс приёмника WAL или отсутствует коммуникация отправителя и приёмника WAL.
	572
	573	\\
	574
	575	На этом базовая настройка отказоустойчивого кластера PostgreSQL и Платформы НЕЙРОСС окончена.
	576
	577	Дополнительно стоит обратить внимание, что сервис //pcsd// имеет встроенный пользовательский веб-интерфейс, который доступен по адресу любого узла на порту 2224. Работает очень медленно. На данном примере ссылка на него будет:
	578
	579	{{code/}}
	580
5.1	581	Браузеру «не понравится» самоподписанный сертификат, но с этим надо согласиться или подложить на узлы доверенные сертификаты. Веб-интерфейс также доступен и по общему виртуальному адресу и тому же порту 2224.
1.1	582
	583	Для входа необходимо использовать учётные данные пользователя кластера — //hacluster// и его пароль.
	584
	585	При первом входе необходимо выполнить добавление существующего кластера командой //+ Add Existing// и ввести имя одного из узлов кластера.
	586
	587	Через некоторое время запись о кластере появится в пользовательском интерфейсе. Выбрав кластер путём выбора соответствующего чекбокса справа отобразится обобщённая сводная информация о кластере, его узлах и ресурсах. Нажав левой клавишей мыши по имени кластера вы сможете перейти в управление кластером, узлами и ресурсами.
	588
	589	== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Полезныекоманды"/}}Полезные команды ==
	590
	591	Для мониторинга (отслеживания) состояния кластера в реальном времени можно использовать команду:
	592
	593	{{code language="bash"}}
	594	sudo crm_mon -Afr
	595	{{/code}}
	596
	597	Перевод узла в standby
	598
	599	{{code language="bash"}}
	600	sudo pcs node standby node2
	601	{{/code}}
	602
	603	Возврат узла из standby
	604
	605	{{code language="bash"}}
	606	sudo pcs node unstandby node2
	607	{{/code}}
	608
	609	Если PostgreSQL (ресурс HA-pgsql) остаётся в состоянии "Stopped" на узле node2 и "Failed Resource Actions" листинг выводит "error", выполните для диагностики:
	610
	611	{{code language="bash"}}
	612	sudo pcs resource debug-start postgresql
	613	{{/code}}
	614
	615	Если узел сообщит:
	616	'//My data may be inconsistent. You have to remove /var/lib/pgsql/tmp/PGSQL.lock file to force start.'//
	617	Необходимо удалить файл /var/lib/pgsql/tmp/PGSQL.lock для возможности старта
	618	Для удаления и очистки счётчика сбоев выполните:
	619
	620	{{code language="bash"}}
	621	sudo rm /var/lib/pgsql/tmp/PGSQL.lock
	622	sudo pcs resource cleanup HA-pgsql
	623	{{/code}}
	624
	625
	626	Проверка конфигурации:
	627
	628	{{code language="bash"}}
	629	sudo crm_verify -L -VVV
	630	{{/code}}
	631
	632	При отсутствии ошибок:
	633
2.1	634	{{code language="java"}}
1.1	635	(unpack_config) notice: On loss of quorum: Ignore
	636	{{/code}}
	637
	638
	639	Проверка сбоев у конкретного ресурса (например, //HA-pgsql//), которые препятствуют его старту:
	640
	641	{{code language="bash"}}
	642	sudo pcs resource failcount show HA-pgsql
	643	{{/code}}
	644
	645
	646	Проверка сбоев у всех ресурсов, которые препятствуют их старту:
	647
	648	{{code language="bash"}}
	649	sudo pcs resource failcount show
	650	{{/code}}
	651
	652
	653	Очистка счётчика всех сбоев (применяется после устранения причин сбоя):
	654
	655	{{code language="bash"}}
	656	sudo pcs resource cleanup
	657	{{/code}}
	658
	659
	660	Очистка счётчика сбоев фенсинга узла NODE2 (применяется после устранения причин сбоя):
	661
	662	{{code language="bash"}}
	663	sudo stonith_admin --cleanup --history=node2
	664	{{/code}}
	665
	666	\\
	667
	668	\|=(((
5.1	669	утилита crm_resource
1.1	670	)))\|=(((
5.1	671	утилита crm
1.1	672	)))
	673	\|(% colspan="2" %)(((
5.1	674	Вывод поддерживаемых стандартов (классов) ресурсов кластера
1.1	675	)))
	676	\|(((
	677	(((
2.1	678	{{code language="java"}}
1.1	679	sudo crm_resource --list-standards
	680	{{/code}}
	681	)))
	682	)))\|(((
	683	(((
2.1	684	{{code language="java"}}
1.1	685	sudo crm ra classes
	686	{{/code}}
	687	)))
	688	)))
	689	\|(% colspan="2" %)(((
5.1	690	Вывод поддерживаемых агентов ресурсов кластера для определенного стандарта
1.1	691	)))
	692	\|(((
	693	(((
	694	(% style="text-align: left;" %)
	695	доступные systemd агенты
	696
2.1	697	{{code language="java"}}
1.1	698	sudo crm_resource --list-agents systemd
	699	{{/code}}
	700
	701	(% style="text-align: left;" %)
	702	доступные lsb агенты
	703
2.1	704	{{code language="java"}}
1.1	705	sudo crm_resource --list-agents lsb
	706	{{/code}}
	707	)))
	708	)))\|(((
	709	(((
2.1	710	{{code language="java"}}
1.1	711	sudo crm ra list systemd
	712	{{/code}}
	713
2.1	714	{{code language="java"}}
1.1	715	sudo crm ra list lsb
	716	{{/code}}
	717	)))
	718	)))
	719	\|(((
	720	(((
	721	(% style="text-align: left;" %)
	722	доступные OCF провайдеры
	723
2.1	724	{{code language="java"}}
1.1	725	sudo crm_resource --list-ocf-providers
	726	{{/code}}
	727	)))
	728	)))\|(((
	729	\\
	730	)))
	731	\|(((
	732	(((
	733	(% style="text-align: left;" %)
	734	доступные OCF агенты из проекта linux-ha провайдер heartbeat
	735
2.1	736	{{code language="java"}}
1.1	737	sudo crm_resource --list-agents ocf:heartbeat
	738	{{/code}}
	739	)))
	740	)))\|(((
	741	\\
	742	)))
	743	\|(((
	744	(((
	745	(% style="text-align: left;" %)
	746	доступный OCF провайдер для агента pgsql
	747
2.1	748	{{code language="java"}}
1.1	749	sudo crm_resource --list-ocf-alternatives pgsql
	750	{{/code}}
	751	)))
	752	)))\|(((
	753	\\
	754	)))
	755	\|(((
	756	(((
	757	(% style="text-align: left;" %)
	758	метаданные для класс:провайдер:агент
	759
2.1	760	{{code language="java"}}
1.1	761	sudo crm_resource --show-metadata ocf:heartbeat:pgsql
	762	{{/code}}
	763	)))
	764	)))\|(((
	765	\\
	766	)))
	767
	768	Логи работы компонентов кластера
	769
2.1	770	{{code language="java"}}
1.1	771	sudo tail /var/log/pcsd/pcsd.log
	772	sudo tail /var/log/corosync/corosync.log
	773	sudo cat /var/log/pacemaker/pacemaker.log
	774	{{/code}}
	775
5.1	776	запуск с ключом -f позволит следить за ними в реальном времени.
1.1	777
	778	----
	779
	780	== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Созданиересурсовфенсинга"/}}Создание ресурсов фенсинга ==
	781
	782	Для защиты разделяемых ресурсов и изоляции узла кластера при его неисправности существует механизм фенсинга (изоляции).
	783
	784	Во избежание ситуации появления двух Мастеров (например, в следствии потери сетевой связанности между узлами) необходимо наличие устройств «фенсинга» на узлах с СУБД и сервисами. При возникновении сбоя такие устройства «фенсинга» изолируют «сбойнувший» узел – посылают команду на выключение питания или перезагрузку (//poweroff// или //hard-reset//).
	785
	786	Чтобы вывести список доступных агентов //fence-agents// используйте команду:
	787
	788	{{code language="bash"}}
	789	sudo pcs stonith list
	790	{{/code}}
	791
5.1	792	(% style="font-weight: 400;" %)Для тестовых целей можно использовать следующую конфигурацию с агентом //external/ssh//:
1.1	793
	794	{{code language="bash"}}
	795	sudo crm
	796	configure
	797	primitive st-ssh stonith:external/ssh params hostlist="node1 node2"
	798	clone fencing st-ssh
	799	property stonith-enabled=true
	800	commit
	801	exit
	802	{{/code}}
	803
5.1	804	=== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Пример1.Использованиедвухмеханизмовфенсингаузловнапримерефенсингавиртуальныхмашинах"/}}Пример 1. Использование двух механизмов фенсинга узлов на примере фенсинга виртуальных машинах(%%) ===
1.1	805
	806	При использовании виртуальных машин в качестве узлов кластера можно использовать агент //external/libvirt//. Далее рассмотрим настройку конфигурации, в которой сервер с гипервизором имеет адрес 10.1.30.249, а узлы, как описано выше. В примере будут использоваться два фенсинг механизма – //ssh// и //libvirt//.
	807	Чтобы вывести необходимые настройки для выбранного агента выполните команду:
	808
	809	{{code language="bash"}}
	810	sudo pcs stonith describe external/libvirt
	811	{{/code}}
	812
	813	Основным механизмом фенсинга виртуальных машин является агент //libvirt// (или vcenter, xen и т.д.), но в случае, если хост виртуальной машины (гипервизор) не работает, фенсинг через //libvirt// никогда не будет успешным.
	814
	815	Идея состоит в том, чтобы реализовать второй механизм фенсинга, например, IPMI, который сработает при выходе из строя первого механизма.
	816
	817	Для демонстрации идеи, в этом примере наоборот первым механизмом фенсинга будет агент //ssh// (фенсинг узла на виртуальной машине), а вторым механизмом будет агент //libvirt// (фенсинг виртуальной машины на хосте гипервизора). Таким образом, что если виртуальная машина (node1 или node2) зависла и не может управляться агентом //ssh//, то фенсинг будет осуществлён через //libvirt// и, соответственно, сервер с гипервизором, на котором эта машина работает.
	818
	819	Обменяемся ssh ключами между узлами кластера (виртуальными машинами).
	820	Для этого на узле //node1// сгенерируем ключ, передадим на узел //node2// и проверим сессию
	821
	822	{{code language="bash"}}
	823	ssh-keygen
	824	ssh-copy-id user@node2
	825	ssh user@node2
	826	exit
	827	{{/code}}
	828
	829	аналогично на узле //node2//
	830
	831	{{code language="bash"}}
	832	ssh-keygen
	833	ssh-copy-id user@node1
	834	ssh user@node1
	835	exit
	836	{{/code}}
	837
	838	Сконфигурируем ресурсы фенсинга
	839
	840	{{code language="bash"}}
	841	sudo crm
	842	confugure
	843	primitive fence-node1-libvirt stonith:external/libvirt \
	844	params hostlist=node1 hypervisor_uri="qemu+ssh://10.1.30.249/system" reset_method=power_cycle \
	845	op monitor interval=180 timeout=30 \
	846	meta target-role=Started
	847	primitive fence-node1-ssh stonith:ssh \
	848	params hostlist=node1 stonith-timeout=30 \
	849	meta target-role=Started
	850	primitive fence-node2-libvirt stonith:external/libvirt \
	851	params hostlist=node2 hypervisor_uri="qemu+ssh://10.1.30.249/system" reset_method=power_cycle \
	852	op monitor interval=180 timeout=30 \
	853	meta target-role=Started
	854	primitive fence-node2-ssh stonith:ssh \
	855	params hostlist=node2 stonith-timeout=30 \
	856	meta target-role=Started
	857	location l-fence-node1-libvirt fence-node1-libvirt -inf: node1
	858	location l-fence-node1-ssh fence-node1-ssh -inf: node1
	859	location l-fence-node2-libvirt fence-node2-libvirt -inf: node2
	860	location l-fence-node2-ssh fence-node2-ssh -inf: node2
	861	fencing_topology \
	862	node2: fence-node2-ssh fence-node2-libvirt \
	863	node1: fence-node1-ssh fence-node1-libvirt
	864	property cib-bootstrap-options: \
	865	stonith-enabled=yes \
	866	no-quorum-policy=ignore \
	867	placement-strategy=balanced \
	868	dc-version=1.1.12-ad083a8 \
	869	cluster-infrastructure=corosync \
	870	cluster-name=hacluster \
	871	stonith-timeout=90 \
	872	last-lrm-refresh=1420721144
	873	rsc_defaults rsc-options: \
	874	resource-stickiness=1 \
	875	migration-threshold=3
	876	op_defaults op-options: \
	877	timeout=600 \
	878	record-pending=true
	879	commit
	880	exit
	881	{{/code}}
	882
	883	\\
	884
	885	{{info}}
	886	Пояснение определения
	887
	888	{{code language="none"}}
	889	fencing_topology \
	890	node2: fence-node2-ssh fence-node2-libvirt \
	891	node1: fence-node1-ssh fence-node1-libvirt
	892	{{/code}}
	893
	894	означает: для фенсинга узла //node2// сначала использовать ресурс //fence-node2-ssh//, если это не удается, то использовать ресурс //fence-node2-libvirt//.
	895	{{/info}}
	896
5.1	897	Перезагружаем все виртуальные машины в кластере.
1.1	898
	899	\\
	900
	901	=== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Пример2.Фенсингузловадаптеромудалённогосупервизора(RSA)"/}}Пример 2. Фенсинг узлов адаптером удалённого супервизора (RSA) ===
	902
	903	Реальная конфигурация не сильно отличается от тестовой, хотя для некоторых фенсинг устройств может потребоваться больше атрибутов. Например, устройство отключения IBM RSA (например, с адресами 10.1.31.101 и 10.1.31.102) может быть настроено следующим образом:
	904
2.1	905	{{code language="java"}}
1.1	906	sudo crm
	907	configure
	908	primitive st-ibmrsa-1 stonith:external/ibmrsa-telnet \
	909	params nodename=node1 ipaddr=10.1.31.101 \
	910	userid=USERID passwd=PASSW0RD
	911	primitive st-ibmrsa-2 stonith:external/ibmrsa-telnet \
	912	params nodename=node2 ipaddr=10.1.31.102 \
	913	userid=USERID passwd=PASSW0RD
	914	# st-ibmrsa-1 может работать где угодно, но не на узле node1
	915	location l-st-node1 st-ibmrsa-1 -inf: node1
	916	# st-ibmrsa-2 может работать где угодно, но не на узле node2
	917	location l-st-node2 st-ibmrsa-2 -inf: node2
	918	commit
	919
	920	{{/code}}
	921
	922	\\
	923
	924	=== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Пример3.ФенсингузловагентомисточниковбесперебойногопитанияAPCPDU"/}}Пример 3. Фенсинг узлов агентом источников бесперебойного питания APC PDU ===
	925
	926	Ниже приведен полный пример двухузлового кластера, в котором каждый сервер имеет один источник питания, подключенный к общему APC PDU на разные розетки:
	927
	928	{{code language="bash"}}
	929	sudo pcs stonith create node1-node2-power-apc stonith:apcmaster \
	930	ipaddr="10.1.31.11" \
	931	login="apc" \
	932	password="apc" \
	933	pcmk_host_list="node1,node2" \
	934	pcmk_host_check="static-list" \
	935	pcmk_host_map="node1:7;node2:8"
	936	{{/code}}
	937
	938	//ipaddr// – это IP-адрес контроллера APC PDU. Внимание, это не IP-адрес узла, который будет изолирован.
	939	//login// и //password// используются для предоставления учетных данных для входа в контроллер APC PDU.
	940	//pcmk_host_map// – сопоставляет имя узла в //pacemaker// с номером порта на PDU, представляющем физическую розетку ИБП APC. Каждая запись в списке имеет формат <имя узла>:<номер порта PDU> (двоеточие отделяет узел от порта), а записи между собой разделяются точкой с запятой.
	941
	942	\\
	943
	944	=== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Пример4.ФенсингузловсрезервнымиисточникамипитанияинесколькимиисточникамибесперебойногопитанияAPCPDU"/}}Пример 4. Фенсинг узлов с резервными источниками питания и несколькими источниками бесперебойного питания APC PDU ===
	945
	946	Когда серверы имеют резервные источники питания с несколькими подключениями к источникам бесперебойного питания, важно, чтобы кластер //pacemaker// мог отключать питание всех блоков питания в сервере при попытке изолировать узел.
	947	Для этого должно быть определение фенсинг агента для каждого PDU, который подаёт питание на серверы узлов в кластере.
	948	В следующем примере определены два фенсинг агента APC:
	949
	950	{{code language="bash"}}
	951	sudo pcs stonith create node1-node2-power-apc1 stonith:apcmaster \
	952	ipaddr="10.1.30.11" \
	953	login="apc" \
	954	password="apc" \
	955	pcmk_host_list="node1,node2" \
	956	pcmk_host_check="static-list" \
	957	pcmk_host_map="node1:7;node2:8"
	958
	959	sudo pcs stonith create node1-node2-power-apc2 stonith:apcmaster \
	960	ipaddr="10.1.30.12" \
	961	login="apc" \
	962	password="apc" \
	963	pcmk_host_list="node1,node2" \
	964	pcmk_host_check="static-list" \
	965	pcmk_host_map="node1:7;node2:8"
	966	{{/code}}
	967
	968	В этом примере каждый сервер подключен к одному и тому же порту питания (физической розетке) на каждом из двух PDU. Это может быть не всегда, поэтому убедитесь, что //pcmk_host_map// отражает физическую конфигурацию каждого PDU.
	969
	970	Чтобы гарантировать, что все определенные порты питания (розетки) каждого PDU отключены одновременно, фенсинг агенты должны быть сгруппированы в уровень фенсинга. Уровень – это разделённый запятыми список фенсинг ресурсов, которые необходимо выполнить, чтобы изолировать (выключить сервер) узел кластера. Уровней может быть несколько, в зависимости от сложности кластера и количества доступных вариантов фенсинга. Каждый уровень является автономным, и выполнение фенсинга прекращается, когда все фенсинг агенты на данном уровне завершаются с успешным кодом выхода (завершения).
	971
	972	Если на уровне STONITH определено несколько агентов, все агенты должны успешно завершиться, хотя они не обязательно должны работать одновременно.
	973
	974	В продолжение этого примера, уровни STONITH можно определить следующим образом:
	975
	976	{{code language="bash"}}
	977	sudo pcs stonith level add 1 node1 \
	978	node1-node2-power-apc1,node1-node2-power-apc2
	979	sudo pcs stonith level add 1 node2 \
	980	node1-node2-power-apc1,node1-node2-power-apc2
	981	{{/code}}
	982
	983	\\
	984
	985	=== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Пример5.Фенсингузловнавиртуальныхмашинах"/}}Пример 5. Фенсинг узлов на виртуальных машинах ===
	986
	987	При использовании виртуальных машин в качестве узлов кластера можно использовать агент //fence_virsh//. Далее рассмотрим настройку конфигурации, в которой сервер с гипервизором имеет адрес 10.1.30.249, а узлы, как описано выше.
	988	Чтобы вывести необходимые настройки для выбранного агента используйте команду:
	989
	990	{{code language="bash"}}
	991	sudo pcs stonith describe fence_virsh
	992	{{/code}}
	993
	994	== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Настройкадоступапоssh"/}}Настройка доступа по ssh ==
	995
	996	Чтобы настроить доступ по ssh к серверу с гипервизором под пользователем root по ключу выполните следующие действия.
	997	На сервере в файле ///etc/ssh/sshd_config// установите значение параметра //PermitRootLogin// равное //yes//.
	998	Перезагрузите службу на сервере //sshd//:
	999
	1000	{{code language="bash"}}
	1001	sudo systemctl restart sshd.service
	1002	{{/code}}
	1003
	1004	На каждом узле сгенерируйте ключи при помощи команды:
	1005
	1006	{{code language="bash"}}
	1007	sudo ssh-keygen
	1008	{{/code}}
	1009
	1010	На каждом узле отправьте публичный ключ на сервер с гипервизором (например, адрес сервера гипервизора //10.1.30.249//):
	1011
	1012	{{code language="bash"}}
	1013	sudo ssh-copy-id root@10.1.30.249
	1014	{{/code}}
	1015
	1016	На сервере в файле ///etc/ssh/sshd_config// закомментируйте параметр //PermitRootLogin// (чтобы он не применялся в конфигурации).
	1017	Перезагрузите на сервере службу //sshd// для применения настроек:
	1018
	1019	{{code language="bash"}}
	1020	sudo systemctl restart sshd.service
	1021	{{/code}}
	1022
	1023	Для проверки работы //fence_virsh// перед настройкой можно использовать команду:
	1024
	1025	{{code language="bash"}}
	1026	sudo fence_virsh -a 10.1.30.249 -l root -n node1 -x -k /home/user/.ssh/id_rsa -o list
	1027	{{/code}}
	1028
	1029	Параметры команды:
	1030	//-a 10.1.30.249// - IP-адрес сервера, на котором запущен гипервизор KVM;
	1031	//-l root// - логин пользователя для подключения к серверу с гипервизором по ssh;
	1032	//-n node1// — название виртуальной машины в гипервизоре;
	1033	//-k /home/user/.ssh/id_rsa// - путь к ключу, созданному при помощи команды //ssh-keygen//.
	1034	В результате выполнения команда выведет список всех виртуальных машин в гипервизоре.
	1035	Теперь следует создать и настроить ресурсы фенсинга для всех узлов кластера. Выполните следующие действия.
	1036	Создайте ресурс фенсинга //fence_node1// для первого узла (//node1//) при помощи команды:
	1037
	1038	{{code language="bash"}}
	1039	sudo pcs stonith create fence_node1 fence_virsh pcmk_host_list="node1" ipaddr="10.1.30.249" login="root" \
	1040	identity_file="/home/u/.ssh/id_rsa" pcmk_reboot_action="reboot" pcmk_monitor_timeout=60s plug=node1
	1041	{{/code}}
	1042
	1043	Параметры команды:
	1044	//pcmk_host_list// - какими узлами кластера может управлять данный ресурс;
	1045	//plug// - название виртуальной машины в гипервизоре.
	1046	Аналогично создайте ресурс //fence_node2// для узла //node2//.
	1047
	1048	{{code language="bash"}}
	1049	sudo pcs stonith create fence_node2 fence_virsh pcmk_host_list="node2" ipaddr="10.1.30.249" login="root" \
	1050	identity_file="/home/u/.ssh/id_rsa" pcmk_reboot_action="reboot" pcmk_monitor_timeout=60s plug=node2
	1051	{{/code}}
	1052
	1053	После создания ресурсов фенсинга для каждого узла, необходимо настроить их таким образом, чтобы они __не__ запускались на тех узлах, для перезагрузки которых они созданы.
	1054
	1055	Для ресурса //fence_node1// выполните команду:
	1056
	1057	{{code language="bash"}}
	1058	sudo pcs constraint location fence_node1 avoids node1=INFINITY
	1059	{{/code}}
	1060
	1061	Выполните аналогичную команду для других узлов:
	1062
	1063	{{code language="bash"}}
	1064	sudo pcs constraint location fence_node2 avoids node2=INFINITY
	1065	{{/code}}
	1066
	1067	Перезагрузите все виртуальные машины в кластере.
	1068	\\
	1069
	1070	----
	1071
	1072	== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Синхронизацияресурсовизфайловойсистемы"/}}Синхронизация ресурсов из файловой системы ==
	1073
	1074	\\
	1075
	1076	{{info title="Файлы, с которыми работает (модифицирует) Платформа (кроме исполняемых)"}}
	1077	(% class="wiki-list0" %)
	1078	1. Файл лицензии (% class="inline-code" %){{code language="none"}}/home/ultima-vmc/Neyross/ultima-vmc/licence{{/code}}(%%)
	1079	Создаётся Платформой при первом запуске и меняется при обновлении лицензии через веб-интерфейс.
	1080	Если лицензирование происходит через HID - файлы лицензии должны быть разные для разных физических машин. Если через несколько Guardant одной поставки - файлы могут быть одинаковы
	1081	1. Конфигурационный файл (% class="inline-code" %){{code language="none"}}/usr/share/ultima-vmc/conf/application.conf{{/code}}(%%)
	1082	Создаётся пустым при инсталляции ПО, перезаписывается в процессе первого запуска, в дальнейшем только читается
	1083	1. Вспомогательный файл (% class="inline-code" %){{code language="none"}}/home/ultima-vmc/Neyross/ultima-vmc/activiti.cfg.xml{{/code}}(%%)
	1084	Создаётся при первом запуске
	1085	1. Если используются локальные ГИС-тайлы, то они лежат в (% class="inline-code" %){{code language="none"}}/home/ultima-vmc/Neyross/ultima-vmc/resources/ultima.vmc.gis.tiles{{/code}}(%%) (загружаются пользователем через веб-интерфейса)
	1086	1. Если используется распознавание лиц, то в папке (% class="inline-code" %){{code language="none"}}/home/ultima-vmc/Neyross/ultima-vmc/resources/neurotech{{/code}}(%%) лежат загружаемые через веб-интерфейс ресурсные файлы Нейротека. При этом в папке (% class="inline-code" %){{code language="none"}}/home/ultima-vmc/Neyross/ultima-vmc/resources/neurotech-licence{{/code}}(%%) загружаются лицензионныей файлы Нейротека, которые должны быть разными для каждой физической машины
	1087	1. ...в будущем в папке (% class="inline-code" %){{code language="none"}}/home/ultima-vmc/Neyross/ultima-vmc/resources/{{/code}}(%%) могут появиться другие директории, которые нужно синхронизировать
	1088	{{/info}}
	1089
	1090	Таким образом, должны синхронизироваться файли и каталоги 2, 3, 4 и 6. Файлы и каталоги 1 и 5 должны синхронизироваться в случаях определённых конфигураций и состава.
	1091
	1092	Для синхронизации объектов файловой системы (файлы и директории) между узлами будем использовать демон //rsyncd// (утилита //rsync//) с соответствующей конфигурвацией //rsyncd.conf//. Проверить налличие утилиты в составе развёрнутой операционной системы можно выполнив запрос состояния сервиса //rsync// (или, в зависимости от версии операционной системы, //rsyncd//):
	1093
	1094	{{code language="bash"}}
	1095	user@node1:~$ sudo systemctl status rsync.service
	1096	● rsync.service - fast remote file copy program daemon
	1097	Loaded: loaded (/lib/systemd/system/rsync.service; enabled; vendor preset: enabled)
	1098	Active: inactive (dead)
	1099	Condition: start condition failed at Tue 2021-11-16 09:35:14 MSK; 5h 12min ago
	1100	Docs: man:rsync(1)
	1101	man:rsyncd.conf(5)
	1102
	1103	Nov 16 09:35:14 node1 systemd[1]: Condition check resulted in fast remote file copy program daemon being skipped.
	1104	{{/code}}
	1105
	1106	\\
	1107
	1108	{{info title="ВНИМАНИЕ"}}
	1109	Для нормальной работы утилиты //rsync// пользователь, от имени которого работает утилита, должен иметь права записи в директорию, хранящую модифицируемые (синхронизируемые) файлы и директории. В нашем случае это будет пользователь //ultima-vmc//.
	1110	{{/info}}
	1111
	1112	Таким образом, на каждом из узлов //node1// и //node2// необходимо поменять владельца только для одной директории (остальные находятся в домашней директории пользователя //ultima-vmc//):
	1113
	1114	{{code language="bash"}}
	1115	sudo chown ultima-vmc:ultima-vmc /usr/share/ultima-vmc/conf/
	1116	{{/code}}
	1117
	1118	Для того, что текущий пользователь имел возможность исполнять удалённо утилиту //rsync// от имени другого пользователя (напомним, в нашем случае от имени пользователя //ultima-vmc//) необходимо предоставить ему эти разрешения и, так как узлы у нас симметричные, то выполнить это необходимо на каждом из узлов //node1// и //node2//. (в примере таким пользователем является пользователь с именем //user//)
	1119
	1120	{{code language="bash"}}
	1121	sudo su
	1122	cat > /etc/sudoers.d/user << EOF
	1123	user ALL=(ALL) NOPASSWD:/usr/bin/rsync
	1124	EOF
	1125	exit
	1126	{{/code}}
	1127
	1128	Если узлы не обменялись ключами сессий //ssh// пользователей как описано в настройках фенсинга Пример 1, то необходимо это выполнить и обменяться ssh ключами между узлами кластера.
	1129	Для этого на узле //node1// сгенерируем ключ, передадим его на узел //node2// и проверим сессию
	1130
	1131	{{code language="bash"}}
	1132	ssh-keygen
	1133	ssh-copy-id user@node2
	1134	ssh user@node2
	1135	exit
	1136	{{/code}}
	1137
	1138	аналогично на узле //node2//
	1139
	1140	{{code language="bash"}}
	1141	ssh-keygen
	1142	ssh-copy-id user@node1
	1143	ssh user@node1
	1144	exit
	1145	{{/code}}
	1146
	1147	Теперь можно выполнить синхронизацию объектов файловой системы. В нашем случае передать актуальные файлы с узла //node1// на узел //node2//
	1148
	1149	{{code language="bash"}}
	1150	rsync -avz -e ssh --rsync-path="sudo -u ultima-vmc rsync" /usr/share/ultima-vmc/conf/application.conf user@10.1.30.252:/usr/share/ultima-vmc/conf/application.conf
	1151	rsync --rsync-path="sudo -u ultima-vmc rsync" -avz -e ssh /home/ultima-vmc/Neyross/ultima-vmc/activiti.cfg.xml user@10.1.30.252:/home/ultima-vmc/Neyross/ultima-vmc/activiti.cfg.xml
	1152	rsync -avzr -e ssh --rsync-path="sudo -u ultima-vmc rsync" /home/ultima-vmc/Neyross/ultima-vmc/resources/ 10.1.30.252:/home/ultima-vmc/Neyross/ultima-vmc/resources/
	1153	{{/code}}
	1154
	1155	\\
	1156
	1157	На этом можно остановиться, т.к. в реальном времени файловые объекты не изменяются в процессе штатной работы прикладных программных средств. Изменения могут возникать при:
	1158
	1159	* обновлении прикладных программных средств
	1160	* расширении функций и/или изменении состава лицензий
	1161	* изменении конфигурации прикладных программных средств
	1162
	1163	Во всех этих случаях, а также при восстановлении узла после сбоя, синхронизацию можно выполнять вручную по завершению восстановительных работ или внесённых изменений.
	1164
	1165	Автоматическая синхронизация пока не видится целесообразной.
	1166
	1167	\\
	1168
	1169	Автоматическую синхронизацию можно выполнять посредством утилиты //lsyncd//. Данная программа позволяет средствами //rsync// делать резервное копирование сразу же по появлению нового файла в указанной директории. По-сути, выполняется односторонняя синхронизация в реальном времени с помощью Lsyncd.
	1170
	1171	//Lsyncd// просматривает дерево локальных директорий с помощью интерфейса модуля мониторинга //inotify//. Он агрегирует и комбинирует события за несколько секунд и затем запускает процесс (или несколько процессов) синхронизации изменений. По умолчанию для этих целей используется //rsync//. Таким образом, //lsyncd// представляет собой легковесное решение для зеркалирования данных, сравнительно легкое в установке, не требующее специфичных файловых систем или блочных устройств, а также не влияющее на производительность файловой системы.
	1172
	1173	Для установки выполняем команды:
	1174
	1175	{{code language="bash"}}
	1176	sudo apt install lsyncd
	1177	{{/code}}
	1178
	1179	Разрешаем автозапуск сервиса и изменим пользователя, от имени которого запускается сервис (в нашем случае user):
	1180
	1181	{{code language="bash"}}
	1182	sudo systemctl enable lsyncd
	1183	sudo systemctl edit lsyncd
	1184	...
	1185	User=user
	1186	...
	1187	{{/code}}
	1188
	1189	Для настройки и запуска открываем конфигурационный файл:
	1190
	1191	{{code language="bash"}}
	1192	sudo nano /etc/lsyncd.conf
	1193	{{/code}}
	1194
	1195	Приводим его к виду:
	1196
	1197	{{code language="none"}}
	1198	settings {
	1199	logfile = "/var/log/lsyncd.log",
	1200	statusFile = "/var/log/lsyncd.stat",
	1201	statusInterval = 5,
	1202	insist = true,
	1203	nodaemon = false,
	1204	}
	1205	sync {
	1206	default.rsyncssh,
	1207	source = "/usr/share/ultima-vmc/conf/application.conf",
	1208	host = "user@10.1.30.252",
	1209	targetdir = "/usr/share/ultima-vmc/conf/application.conf",
	1210	rsync = {
	1211	_extra = { "-avz --rsync-path='sudo -u ultima-vmc rsync'" }
	1212	}
	1213	}
	1214	sync {
	1215	default.rsyncssh,
	1216	source = "/home/ultima-vmc/Neyross/ultima-vmc/activiti.cfg.xml",
	1217	host = "user@10.1.30.252",
	1218	targetdir = "/home/ultima-vmc/Neyross/ultima-vmc/activiti.cfg.xml",
	1219	rsync = {
	1220	_extra = { "-avz --rsync-path='sudo -u ultima-vmc rsync'" }
	1221	}
	1222	}
	1223	sync {
	1224	default.rsyncssh,
	1225	source = "/home/ultima-vmc/Neyross/ultima-vmc/resources/",
	1226	host = "user@10.1.30.252",
	1227	targetdir = "/home/ultima-vmc/Neyross/ultima-vmc/resources/",
	1228	rsync = {
	1229	_extra = { "-avzr --rsync-path='sudo -u ultima-vmc rsync'" }
	1230	}
	1231	}
	1232	{{/code}}
	1233
	1234	где:
	1235
	1236	settings — общие настройки.
	1237
	1238	* //logfile //— путь до файла логов.
	1239	* //statusFile //— файл, в который заносятся изменения, найденные с помощью inotify.
	1240	* //statusInterval //— интервал в секундах для обновления statusFile.
	1241	* //insist //— позволяет продолжить работу сервиса, даже если одна или несколько целевых директорий недоступны.
	1242	* //nodaemon //— отключаться или нет от вызывающей стороны. Проще говоря, если разрешить, то будет больше информации по его работе. Для боевого режима можно отключить.
	1243
	1244	sync — настройка для синхронизации конкретного ресурса. Для каждого создается своя секция sync.
	1245
	1246	* //default.rsyncssh// — в качестве протокола будем использовать rsync через ssh.
	1247	* //source// — указываем источник данных, откуда синхронизируем данные.
	1248	* //host// — удаленный компьютер, на который будет идти передача данных. До знака @ указывается пользователь, под которым будет идти подключение.
	1249	* //targetdir// — каталог на удаленном хосте, в который будет выполняться синхронизация.
	1250	* //rsync, _extra// — дополнительные ключи запуска rsync. В нашем примере запускаем в режиме архивирования.
	1251
	1252	После на узле источника (node1) перезапускаем lsyncd:
	1253
	1254	{{code language="bash"}}
	1255	sudo systemctl restart lsyncd
	1256	{{/code}}
	1257
	1258	Мы можем задать права после синхронизации. Это настраивается в конфигурационном файле ///etc/lsyncd.conf// в блоке //sync// раздела //rsync//:
	1259
	1260	\\
	1261
	1262	{{code language="none"}}
	1263	sync {
	1264	...
	1265	rsync = {
	1266	...
	1267	owner=true,
	1268	chown="ultima-vmc:ultima-vmc"
	1269	chmod="775"
	1270	perms=true
	1271	}
	1272	}
	1273	{{/code}}
	1274
	1275	//где~://
	1276
	1277	* //owner — говорит, сохранять ли владельца файла.//
	1278	* //chown — задает конкретного владельца и группу.//
	1279	* //chmod — задает права на синхронизированные файлы.//
	1280	* //perms — говорит, сохранять ли права.//
	1281
	1282	При необходимости, мы можем установить некоторые значения для ограничения или обхода ограничений. Настройки задаются в блоке settings:
	1283
	1284	\\
	1285
	1286	{{code language="none"}}
	1287	settings {
	1288	...
	1289	statusInterval = 5
	1290	maxDelays = 900,
	1291	maxProcesses = 6,
	1292	}
	1293	{{/code}}
	1294
	1295	//где~://
	1296
	1297	* //statusInterval — задает интервал обновления статус-файла в секундах. Чем ниже значение, тем быстрее файлы попадают в очередь для синхронизации.//
	1298	* //maxDelays — задает количество файлов в очереди, при достижении которого задачи синхронизации будут запускаться ниже таймера задержки.//
	1299	* //maxProcesses — максимальное количество процессов, которое сможет запустить lsync.//
	1300
	1301	Мы можем настроить исключение файлов по маске, которые не нужно передавать в другую директорию. Это делается с помощью опций //exclude// или //excludeFrom// в разделе //sync//, например:
	1302
	1303	\\
	1304
	1305	{{code language="none"}}
	1306	sync {
	1307	...
	1308	exclude = { '.bak' , '.tmp' },
	1309	}
	1310	sync {
	1311	...
	1312	excludeFrom="/etc/lsyncd.exclude",
	1313	}
	1314	{{/code}}
	1315
	1316	в первом блоке мы исключим все файлы, которые заканчиваются на //.bak// или //.tmp//. Для второго мы будем использовать файл ///etc/lsyncd.exclude//, в котором перечислим исключения.
	1317
	1318	Для второго блока создаем файл с исключениями:
	1319
	1320	{{code language="bash"}}
	1321	nano /etc/lsyncd.exclude
	1322	{{/code}}
	1323
2.1	1324	{{code language="java"}}
1.1	1325	*.tmp
	1326	*.bak
	1327	testfile.txt
	1328	test/
	1329	{{/code}}
	1330
5.1	1331	в данном примере мы игнорируем файлы, заканчиваются на //.bak// или //.tmp//,а также файл //testfile.txt// и содержимое каталога //test//.
1.1	1332
	1333	\\
	1334
	1335	Файл конфигурации сервиса (демона) //rsync// :
	1336
	1337	{{code language="bash"}}
	1338	sudo cat /etc/rsyncd.conf
	1339	{{/code}}
	1340
	1341	cat /etc/default/rsync
	1342
	1343	Запуск rsync в режиме демона: sudo rsync ~-~-daemon
	1344
	1345	Создаем ресурс с именем //HA-neyross-rsync// типа //rsyncd// для управления конфигурацией исполняемого сервиса и сразу добавим созданный ресурс в группу, чтобы он запускался вместе на одном узле с другими ресурсами:
	1346
	1347	{{code language="bash"}}
	1348	sudo pcs resource create HA-neyross-rsync lsb:rsync \
	1349	op monitor depth="0" timeout="20s" interval="60s"
	1350	--group master-group
	1351	{{/code}}
	1352
	1353	----
	1354
	1355	== {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Видыплановогообслуживанияотказоустойчивогокластера"/}}Виды планового обслуживания отказоустойчивого кластера ==
	1356
	1357	Для проведения регламентных работ необходимо периодически выводить из состава кластера отдельные узлы:
	1358
	1359	* Выведение из эксплуатации Мастера или Реплики для плановых работ нужно в следующих случаях
	1360	* Замена вышедшего из строя оборудования (не приведшего к сбою);
	1361	* Обновление оборудования;
	1362	* Обновление программных средств;
5.1	1363	* Смена ролей Мастера и Реплики. Это нужно в случае, когда, серверы Мастера и Реплики отличаются по ресурсам. Например, у нас в составе отказоустойчивого кластера есть мощный сервер, выполняющий роль Мастера СУБД PostgreSQL, и слабый сервер, выполняющий роль Реплики. После сбоя более мощного сервера Мастера его функции переходят к более слабой Реплике. Логично, что после устранения причин сбоя на бывшем Мастере администратор вернёт роль Мастера обратно на мощный сервер.
1.1	1364
	1365	{{info title="Важно!"}}
	1366	Прежде чем производить смену ролей или вывод Мастера из эксплуатации, необходимо с помощью команды //crm_mon -Afr// убедиться, что в кластере присутствует синхронная реплика. И роль Мастера назначается всегда синхронной реплике.
	1367	{{/info}}
	1368
	1369	Типовая процедура восстановления кластера с возвратом ролей (исходно NODE1 роль Master и NODE2 роль Slave). Например, требуется проведение регламента на железе узла NODE1.
	1370
	1371	* Перевод узла //node1// в //standby//
	1372
2.1	1373	{{code language="java"}}
1.1	1374	sudo pcs node standby node1
	1375	{{/code}}
	1376
	1377	\\
	1378
	1379	* Проверка в //crm_mon -Afr// состояние узла NODE1 STANDBY, роль //Master// перешла узлу NODE2, изменение состояния реплики (параметр HA-pgsql-data-status в значении DISCONNECT)
	1380	* Останов, проведение регламентных работ, в //crm_mon -Afr// состояние узла NODE1 OFFLINE
	1381	* Запуск узла NODE1 , в //crm_mon -Afr// состояние узла STANDBY
	1382	* Очистка директории СУБД и файла блокировки
	1383
2.1	1384	{{code language="java"}}
1.1	1385	sudo rm /var/lib/pgsql/tmp/PGSQL.lock
	1386	sudo su - postgres
	1387	rm -rf /var/lib/postgresql/12/main/*
	1388	{{/code}}
	1389
	1390	\\
	1391
	1392	* Передача текущей копии БД с действующего узла в роли //Master//
	1393
2.1	1394	{{code language="java"}}
1.1	1395	pg_basebackup -U postgres -D /var/lib/postgresql/12/main -h 10.1.30.252 -X stream -P
	1396	exit
	1397	{{/code}}
	1398
	1399	\\
	1400
	1401	* Сброс ошибок ресурсов
	1402
2.1	1403	{{code language="java"}}
1.1	1404	sudo pcs resource cleanup
	1405	{{/code}}
	1406
	1407	\\
	1408
	1409	* Выход узла NODE1 из standby, в //crm_mon -Afr// состояние узла //Slave//, изменение состояния реплики (параметр HA-pgsql-data-status в значении STREAMING\|SYNC)
	1410
2.1	1411	{{code language="java"}}
1.1	1412	sudo pcs node unstandby node1
	1413	{{/code}}
	1414
	1415	\\
	1416
	1417	* Перевод узла NODE2 в //standby//
	1418
2.1	1419	{{code language="java"}}
1.1	1420	sudo pcs node standby node2
	1421	{{/code}}
	1422
	1423	\\
	1424
	1425	* Проверка в// crm_mon -Afr// состояние узла// node2 //STANDBY, роль// Master// перешла узлу// node1//, изменение состояния реплики (параметр HA-pgsql-data-status в значении DISCONNECT)
	1426
	1427	* Выход узла //node2// из //standby//, в //crm_mon -Afr// состояние узла //Slave//, изменение состояния реплики (параметр HA-pgsql-data-status в значении STREAMING\|SYNC)
	1428
2.1	1429	{{code language="java"}}
1.1	1430	sudo pcs node unstandby node2
	1431	{{/code}}
	1432
	1433
	1434	\\