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

Платформа НЕЙРОСС