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

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