Skip to Content
Version 6.2 by superadmin on 2026/06/15 21:57
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 (((
682 {{code language="java"}}
683 sudo crm_resource --list-standards
684 {{/code}}
685 )))
686 )))|(((
687 (((
688 {{code language="java"}}
689 sudo crm ra classes
690 {{/code}}
691 )))
692 )))
693 |(% colspan="2" %)(((
694 Вывод поддерживаемых агентов ресурсов кластера для определенного стандарта
695 )))
696 |(((
697 (((
698 (% style="text-align: left;" %)
699 доступные systemd агенты
700
701 {{code language="java"}}
702 sudo crm_resource --list-agents systemd
703 {{/code}}
704
705 (% style="text-align: left;" %)
706 доступные lsb агенты
707
708 {{code language="java"}}
709 sudo crm_resource --list-agents lsb
710 {{/code}}
711 )))
712 )))|(((
713 (((
714 {{code language="java"}}
715 sudo crm ra list systemd
716 {{/code}}
717
718 {{code language="java"}}
719 sudo crm ra list lsb
720 {{/code}}
721 )))
722 )))
723 |(((
724 (((
725 (% style="text-align: left;" %)
726 доступные OCF провайдеры
727
728 {{code language="java"}}
729 sudo crm_resource --list-ocf-providers
730 {{/code}}
731 )))
732 )))|(((
733 \\
734 )))
735 |(((
736 (((
737 (% style="text-align: left;" %)
738 доступные OCF агенты из проекта linux-ha провайдер heartbeat
739
740 {{code language="java"}}
741 sudo crm_resource --list-agents ocf:heartbeat
742 {{/code}}
743 )))
744 )))|(((
745 \\
746 )))
747 |(((
748 (((
749 (% style="text-align: left;" %)
750 доступный OCF провайдер для агента pgsql
751
752 {{code language="java"}}
753 sudo crm_resource --list-ocf-alternatives pgsql
754 {{/code}}
755 )))
756 )))|(((
757 \\
758 )))
759 |(((
760 (((
761 (% style="text-align: left;" %)
762 метаданные для класс:провайдер:агент
763
764 {{code language="java"}}
765 sudo crm_resource --show-metadata ocf:heartbeat:pgsql
766 {{/code}}
767 )))
768 )))|(((
769 \\
770 )))
771
772 Логи работы компонентов кластера
773
774 {{code language="java"}}
775 sudo tail /var/log/pcsd/pcsd.log
776 sudo tail /var/log/corosync/corosync.log
777 sudo cat /var/log/pacemaker/pacemaker.log
778 {{/code}}
779
780 запуск с ключом **-f** позволит следить за ними в реальном времени.
781
782 ----
783
784 == {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Созданиересурсовфенсинга"/}}Создание ресурсов фенсинга ==
785
786 Для защиты разделяемых ресурсов и изоляции узла кластера при его неисправности существует механизм фенсинга (изоляции).
787
788 Во избежание ситуации появления двух Мастеров (например, в следствии потери сетевой связанности между узлами) необходимо наличие устройств «фенсинга» на узлах с СУБД и сервисами. При возникновении сбоя такие устройства «фенсинга» изолируют «сбойнувший» узел – посылают команду на выключение питания или перезагрузку (//poweroff// или //hard-reset//).
789
790 Чтобы вывести список доступных агентов //fence-agents// используйте команду:
791
792 {{code language="bash"}}
793 sudo pcs stonith list
794 {{/code}}
795
796 (% style="font-weight: 400;" %)Для тестовых целей можно использовать следующую конфигурацию с агентом //external/ssh//:
797
798 {{code language="bash"}}
799 sudo crm
800 configure
801 primitive st-ssh stonith:external/ssh params hostlist="node1 node2"
802 clone fencing st-ssh
803 property stonith-enabled=true
804 commit
805 exit
806 {{/code}}
807
808 === {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Пример1.Использованиедвухмеханизмовфенсингаузловнапримерефенсингавиртуальныхмашинах"/}}Пример 1. Использование двух механизмов фенсинга узлов на примере фенсинга виртуальных машинах(%%) ===
809
810 При использовании виртуальных машин в качестве узлов кластера можно использовать агент //external/libvirt//. Далее рассмотрим настройку конфигурации, в которой сервер с гипервизором имеет адрес 10.1.30.249, а узлы, как описано выше. В примере будут использоваться два фенсинг механизма – //ssh// и //libvirt//.
811 Чтобы вывести необходимые настройки для выбранного агента выполните команду:
812
813 {{code language="bash"}}
814 sudo pcs stonith describe external/libvirt
815 {{/code}}
816
817 Основным механизмом фенсинга виртуальных машин является агент //libvirt// (или vcenter, xen и т.д.), но в случае, если хост виртуальной машины (гипервизор) не работает, фенсинг через //libvirt// никогда не будет успешным.
818
819 Идея состоит в том, чтобы реализовать второй механизм фенсинга, например, IPMI, который сработает при выходе из строя первого механизма.
820
821 Для демонстрации идеи, в этом примере наоборот первым механизмом фенсинга будет агент //ssh// (фенсинг узла на виртуальной машине), а вторым механизмом будет агент //libvirt// (фенсинг виртуальной машины на хосте гипервизора). Таким образом, что если виртуальная машина (node1 или node2) зависла и не может управляться агентом //ssh//, то фенсинг будет осуществлён через //libvirt// и, соответственно, сервер с гипервизором, на котором эта машина работает.
822
823 Обменяемся ssh ключами между узлами кластера (виртуальными машинами).
824 Для этого на узле //node1// сгенерируем ключ, передадим на узел //node2// и проверим сессию
825
826 {{code language="bash"}}
827 ssh-keygen
828 ssh-copy-id user@node2
829 ssh user@node2
830 exit
831 {{/code}}
832
833 аналогично на узле //node2//
834
835 {{code language="bash"}}
836 ssh-keygen
837 ssh-copy-id user@node1
838 ssh user@node1
839 exit
840 {{/code}}
841
842 Сконфигурируем ресурсы фенсинга
843
844 {{code language="bash"}}
845 sudo crm
846 confugure
847 primitive fence-node1-libvirt stonith:external/libvirt \
848 params hostlist=node1 hypervisor_uri="qemu+ssh://10.1.30.249/system" reset_method=power_cycle \
849 op monitor interval=180 timeout=30 \
850 meta target-role=Started
851 primitive fence-node1-ssh stonith:ssh \
852 params hostlist=node1 stonith-timeout=30 \
853 meta target-role=Started
854 primitive fence-node2-libvirt stonith:external/libvirt \
855 params hostlist=node2 hypervisor_uri="qemu+ssh://10.1.30.249/system" reset_method=power_cycle \
856 op monitor interval=180 timeout=30 \
857 meta target-role=Started
858 primitive fence-node2-ssh stonith:ssh \
859 params hostlist=node2 stonith-timeout=30 \
860 meta target-role=Started
861 location l-fence-node1-libvirt fence-node1-libvirt -inf: node1
862 location l-fence-node1-ssh fence-node1-ssh -inf: node1
863 location l-fence-node2-libvirt fence-node2-libvirt -inf: node2
864 location l-fence-node2-ssh fence-node2-ssh -inf: node2
865 fencing_topology \
866 node2: fence-node2-ssh fence-node2-libvirt \
867 node1: fence-node1-ssh fence-node1-libvirt
868 property cib-bootstrap-options: \
869 stonith-enabled=yes \
870 no-quorum-policy=ignore \
871 placement-strategy=balanced \
872 dc-version=1.1.12-ad083a8 \
873 cluster-infrastructure=corosync \
874 cluster-name=hacluster \
875 stonith-timeout=90 \
876 last-lrm-refresh=1420721144
877 rsc_defaults rsc-options: \
878 resource-stickiness=1 \
879 migration-threshold=3
880 op_defaults op-options: \
881 timeout=600 \
882 record-pending=true
883 commit
884 exit
885 {{/code}}
886
887 \\
888
889 {{info}}
890 Пояснение определения
891
892 {{code language="none"}}
893 fencing_topology \
894 node2: fence-node2-ssh fence-node2-libvirt \
895 node1: fence-node1-ssh fence-node1-libvirt
896 {{/code}}
897
898 означает: для фенсинга узла //node2// сначала использовать ресурс //fence-node2-ssh//, если это не удается, то использовать ресурс //fence-node2-libvirt//.
899 {{/info}}
900
901 Перезагружаем все виртуальные машины в кластере.
902
903 \\
904
905 === {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Пример2.Фенсингузловадаптеромудалённогосупервизора(RSA)"/}}Пример 2. Фенсинг узлов адаптером удалённого супервизора (RSA) ===
906
907 Реальная конфигурация не сильно отличается от тестовой, хотя для некоторых фенсинг устройств может потребоваться больше атрибутов. Например, устройство отключения IBM RSA (например, с адресами 10.1.31.101 и 10.1.31.102) может быть настроено следующим образом:
908
909 {{code language="java"}}
910 sudo crm
911 configure
912 primitive st-ibmrsa-1 stonith:external/ibmrsa-telnet \
913 params nodename=node1 ipaddr=10.1.31.101 \
914 userid=USERID passwd=PASSW0RD
915 primitive st-ibmrsa-2 stonith:external/ibmrsa-telnet \
916 params nodename=node2 ipaddr=10.1.31.102 \
917 userid=USERID passwd=PASSW0RD
918 # st-ibmrsa-1 может работать где угодно, но не на узле node1
919 location l-st-node1 st-ibmrsa-1 -inf: node1
920 # st-ibmrsa-2 может работать где угодно, но не на узле node2
921 location l-st-node2 st-ibmrsa-2 -inf: node2
922 commit
923
924 {{/code}}
925
926 \\
927
928 === {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Пример3.ФенсингузловагентомисточниковбесперебойногопитанияAPCPDU"/}}Пример 3. Фенсинг узлов агентом источников бесперебойного питания APC PDU ===
929
930 Ниже приведен полный пример двухузлового кластера, в котором каждый сервер имеет один источник питания, подключенный к общему APC PDU на разные розетки:
931
932 {{code language="bash"}}
933 sudo pcs stonith create node1-node2-power-apc stonith:apcmaster \
934 ipaddr="10.1.31.11" \
935 login="apc" \
936 password="apc" \
937 pcmk_host_list="node1,node2" \
938 pcmk_host_check="static-list" \
939 pcmk_host_map="node1:7;node2:8"
940 {{/code}}
941
942 //ipaddr// – это IP-адрес контроллера APC PDU. Внимание, это не IP-адрес узла, который будет изолирован.
943 //login// и //password// используются для предоставления учетных данных для входа в контроллер APC PDU.
944 //pcmk_host_map// – сопоставляет имя узла в //pacemaker// с номером порта на PDU, представляющем физическую розетку ИБП APC. Каждая запись в списке имеет формат <имя узла>:<номер порта PDU> (двоеточие отделяет узел от порта), а записи между собой разделяются точкой с запятой.
945
946 \\
947
948 === {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Пример4.ФенсингузловсрезервнымиисточникамипитанияинесколькимиисточникамибесперебойногопитанияAPCPDU"/}}Пример 4. Фенсинг узлов с резервными источниками питания и несколькими источниками бесперебойного питания APC PDU ===
949
950 Когда серверы имеют резервные источники питания с несколькими подключениями к источникам бесперебойного питания, важно, чтобы кластер //pacemaker// мог отключать питание всех блоков питания в сервере при попытке изолировать узел.
951 Для этого должно быть определение фенсинг агента для каждого PDU, который подаёт питание на серверы узлов в кластере.
952 В следующем примере определены два фенсинг агента APC:
953
954 {{code language="bash"}}
955 sudo pcs stonith create node1-node2-power-apc1 stonith:apcmaster \
956 ipaddr="10.1.30.11" \
957 login="apc" \
958 password="apc" \
959 pcmk_host_list="node1,node2" \
960 pcmk_host_check="static-list" \
961 pcmk_host_map="node1:7;node2:8"
962
963 sudo pcs stonith create node1-node2-power-apc2 stonith:apcmaster \
964 ipaddr="10.1.30.12" \
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 {{/code}}
971
972 В этом примере каждый сервер подключен к одному и тому же порту питания (физической розетке) на каждом из двух PDU. Это может быть не всегда, поэтому убедитесь, что //pcmk_host_map// отражает физическую конфигурацию каждого PDU.
973
974 Чтобы гарантировать, что все определенные порты питания (розетки) каждого PDU отключены одновременно, фенсинг агенты должны быть сгруппированы в уровень фенсинга. Уровень – это разделённый запятыми список фенсинг ресурсов, которые необходимо выполнить, чтобы изолировать (выключить сервер) узел кластера. Уровней может быть несколько, в зависимости от сложности кластера и количества доступных вариантов фенсинга. Каждый уровень является автономным, и выполнение фенсинга прекращается, когда все фенсинг агенты на данном уровне завершаются с успешным кодом выхода (завершения).
975
976 Если на уровне STONITH определено несколько агентов, все агенты должны успешно завершиться, хотя они не обязательно должны работать одновременно.
977
978 В продолжение этого примера, уровни STONITH можно определить следующим образом:
979
980 {{code language="bash"}}
981 sudo pcs stonith level add 1 node1 \
982 node1-node2-power-apc1,node1-node2-power-apc2
983 sudo pcs stonith level add 1 node2 \
984 node1-node2-power-apc1,node1-node2-power-apc2
985 {{/code}}
986
987 \\
988
989 === {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Пример5.Фенсингузловнавиртуальныхмашинах"/}}Пример 5. Фенсинг узлов на виртуальных машинах ===
990
991 При использовании виртуальных машин в качестве узлов кластера можно использовать агент //fence_virsh//. Далее рассмотрим настройку конфигурации, в которой сервер с гипервизором имеет адрес 10.1.30.249, а узлы, как описано выше.
992 Чтобы вывести необходимые настройки для выбранного агента используйте команду:
993
994 {{code language="bash"}}
995 sudo pcs stonith describe fence_virsh
996 {{/code}}
997
998 == {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Настройкадоступапоssh"/}}Настройка доступа по ssh ==
999
1000 Чтобы настроить доступ по ssh к серверу с гипервизором под пользователем root по ключу выполните следующие действия.
1001 На сервере в файле ///etc/ssh/sshd_config// установите значение параметра //PermitRootLogin// равное //yes//.
1002 Перезагрузите службу на сервере //sshd//:
1003
1004 {{code language="bash"}}
1005 sudo systemctl restart sshd.service
1006 {{/code}}
1007
1008 На каждом узле сгенерируйте ключи при помощи команды:
1009
1010 {{code language="bash"}}
1011 sudo ssh-keygen
1012 {{/code}}
1013
1014 На каждом узле отправьте публичный ключ на сервер с гипервизором (например, адрес сервера гипервизора //10.1.30.249//):
1015
1016 {{code language="bash"}}
1017 sudo ssh-copy-id root@10.1.30.249
1018 {{/code}}
1019
1020 На сервере в файле ///etc/ssh/sshd_config// закомментируйте параметр //PermitRootLogin// (чтобы он не применялся в конфигурации).
1021 Перезагрузите на сервере службу //sshd// для применения настроек:
1022
1023 {{code language="bash"}}
1024 sudo systemctl restart sshd.service
1025 {{/code}}
1026
1027 Для проверки работы //fence_virsh// перед настройкой можно использовать команду:
1028
1029 {{code language="bash"}}
1030 sudo fence_virsh -a 10.1.30.249 -l root -n node1 -x -k /home/user/.ssh/id_rsa -o list
1031 {{/code}}
1032
1033 Параметры команды:
1034 //-a 10.1.30.249// - IP-адрес сервера, на котором запущен гипервизор KVM;
1035 //-l root// - логин пользователя для подключения к серверу с гипервизором по ssh;
1036 //-n node1// — название виртуальной машины в гипервизоре;
1037 //-k /home/user/.ssh/id_rsa// - путь к ключу, созданному при помощи команды //ssh-keygen//.
1038 В результате выполнения команда выведет список всех виртуальных машин в гипервизоре.
1039 Теперь следует создать и настроить ресурсы фенсинга для всех узлов кластера. Выполните следующие действия.
1040 Создайте ресурс фенсинга //fence_node1// для первого узла (//node1//) при помощи команды:
1041
1042 {{code language="bash"}}
1043 sudo pcs stonith create fence_node1 fence_virsh pcmk_host_list="node1" ipaddr="10.1.30.249" login="root" \
1044 identity_file="/home/u/.ssh/id_rsa" pcmk_reboot_action="reboot" pcmk_monitor_timeout=60s plug=node1
1045 {{/code}}
1046
1047 Параметры команды:
1048 //pcmk_host_list// - какими узлами кластера может управлять данный ресурс;
1049 //plug// - название виртуальной машины в гипервизоре.
1050 Аналогично создайте ресурс //fence_node2// для узла //node2//.
1051
1052 {{code language="bash"}}
1053 sudo pcs stonith create fence_node2 fence_virsh pcmk_host_list="node2" ipaddr="10.1.30.249" login="root" \
1054 identity_file="/home/u/.ssh/id_rsa" pcmk_reboot_action="reboot" pcmk_monitor_timeout=60s plug=node2
1055 {{/code}}
1056
1057 После создания ресурсов фенсинга для каждого узла, необходимо настроить их таким образом, чтобы они __не__ запускались на тех узлах, для перезагрузки которых они созданы.
1058
1059 Для ресурса //fence_node1// выполните команду:
1060
1061 {{code language="bash"}}
1062 sudo pcs constraint location fence_node1 avoids node1=INFINITY
1063 {{/code}}
1064
1065 Выполните аналогичную команду для других узлов:
1066
1067 {{code language="bash"}}
1068 sudo pcs constraint location fence_node2 avoids node2=INFINITY
1069 {{/code}}
1070
1071 Перезагрузите все виртуальные машины в кластере.
1072 \\
1073
1074 ----
1075
1076 == {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Синхронизацияресурсовизфайловойсистемы"/}}Синхронизация ресурсов из файловой системы ==
1077
1078 \\
1079
1080 {{info title="Файлы, с которыми работает (модифицирует) Платформа (кроме исполняемых)"}}
1081 (% class="wiki-list0" %)
1082 1. Файл лицензии (% class="inline-code" %){{code language="none"}}/home/ultima-vmc/Neyross/ultima-vmc/licence{{/code}}(%%)
1083 Создаётся Платформой при первом запуске и меняется при обновлении лицензии через веб-интерфейс.
1084 Если лицензирование происходит через HID - файлы лицензии должны быть разные для разных физических машин. Если через несколько Guardant одной поставки - файлы могут быть одинаковы
1085 1. Конфигурационный файл (% class="inline-code" %){{code language="none"}}/usr/share/ultima-vmc/conf/application.conf{{/code}}(%%)
1086 Создаётся пустым при инсталляции ПО, перезаписывается в процессе первого запуска, в дальнейшем только читается
1087 1. Вспомогательный файл (% class="inline-code" %){{code language="none"}}/home/ultima-vmc/Neyross/ultima-vmc/activiti.cfg.xml{{/code}}(%%)
1088 Создаётся при первом запуске
1089 1. Если используются локальные ГИС-тайлы, то они лежат в (% class="inline-code" %){{code language="none"}}/home/ultima-vmc/Neyross/ultima-vmc/resources/ultima.vmc.gis.tiles{{/code}}(%%) (загружаются пользователем через веб-интерфейса)
1090 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}}(%%) загружаются лицензионныей файлы Нейротека, **которые должны быть разными для каждой физической машины**
1091 1. ...в будущем в папке (% class="inline-code" %){{code language="none"}}/home/ultima-vmc/Neyross/ultima-vmc/resources/{{/code}}(%%) могут появиться другие директории, которые нужно синхронизировать
1092 {{/info}}
1093
1094 Таким образом, должны синхронизироваться файли и каталоги 2, 3, 4 и 6. Файлы и каталоги 1 и 5 должны синхронизироваться в случаях определённых конфигураций и состава.
1095
1096 Для синхронизации объектов файловой системы (файлы и директории) между узлами будем использовать демон //rsyncd// (утилита //rsync//) с соответствующей конфигурвацией //rsyncd.conf//. Проверить налличие утилиты в составе развёрнутой операционной системы можно выполнив запрос состояния сервиса //rsync// (или, в зависимости от версии операционной системы, //rsyncd//):
1097
1098 {{code language="bash"}}
1099 user@node1:~$ sudo systemctl status rsync.service
1100 ● rsync.service - fast remote file copy program daemon
1101 Loaded: loaded (/lib/systemd/system/rsync.service; enabled; vendor preset: enabled)
1102 Active: inactive (dead)
1103 Condition: start condition failed at Tue 2021-11-16 09:35:14 MSK; 5h 12min ago
1104 Docs: man:rsync(1)
1105 man:rsyncd.conf(5)
1106
1107 Nov 16 09:35:14 node1 systemd[1]: Condition check resulted in fast remote file copy program daemon being skipped.
1108 {{/code}}
1109
1110 \\
1111
1112 {{info title="ВНИМАНИЕ"}}
1113 Для нормальной работы утилиты //rsync// пользователь, от имени которого работает утилита, должен иметь права записи в директорию, хранящую модифицируемые (синхронизируемые) файлы и директории. В нашем случае это будет пользователь //ultima-vmc//.
1114 {{/info}}
1115
1116 Таким образом, на каждом из узлов //node1// и //node2// необходимо поменять владельца только для одной директории (остальные находятся в домашней директории пользователя //ultima-vmc//):
1117
1118 {{code language="bash"}}
1119 sudo chown ultima-vmc:ultima-vmc /usr/share/ultima-vmc/conf/
1120 {{/code}}
1121
1122 Для того, что текущий пользователь имел возможность исполнять удалённо утилиту //rsync// от имени другого пользователя (напомним, в нашем случае от имени пользователя //ultima-vmc//) необходимо предоставить ему эти разрешения и, так как узлы у нас симметричные, то выполнить это необходимо на каждом из узлов //node1// и //node2//. (в примере таким пользователем является пользователь с именем //user//)
1123
1124 {{code language="bash"}}
1125 sudo su
1126 cat > /etc/sudoers.d/user << EOF
1127 user ALL=(ALL) NOPASSWD:/usr/bin/rsync
1128 EOF
1129 exit
1130 {{/code}}
1131
1132 Если узлы не обменялись ключами сессий //ssh// пользователей как описано в настройках фенсинга Пример 1, то необходимо это выполнить и обменяться ssh ключами между узлами кластера.
1133 Для этого на узле //node1// сгенерируем ключ, передадим его на узел //node2// и проверим сессию
1134
1135 {{code language="bash"}}
1136 ssh-keygen
1137 ssh-copy-id user@node2
1138 ssh user@node2
1139 exit
1140 {{/code}}
1141
1142 аналогично на узле //node2//
1143
1144 {{code language="bash"}}
1145 ssh-keygen
1146 ssh-copy-id user@node1
1147 ssh user@node1
1148 exit
1149 {{/code}}
1150
1151 Теперь можно выполнить синхронизацию объектов файловой системы. В нашем случае передать актуальные файлы с узла //node1// на узел //node2//
1152
1153 {{code language="bash"}}
1154 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
1155 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
1156 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/
1157 {{/code}}
1158
1159 \\
1160
1161 На этом можно остановиться, т.к. в реальном времени файловые объекты не изменяются в процессе штатной работы прикладных программных средств. Изменения могут возникать при:
1162
1163 * обновлении прикладных программных средств
1164 * расширении функций и/или изменении состава лицензий
1165 * изменении конфигурации прикладных программных средств
1166
1167 Во всех этих случаях, а также при восстановлении узла после сбоя, синхронизацию можно выполнять вручную по завершению восстановительных работ или внесённых изменений.
1168
1169 Автоматическая синхронизация пока не видится целесообразной.
1170
1171 \\
1172
1173 Автоматическую синхронизацию можно выполнять посредством утилиты //lsyncd//. Данная программа позволяет средствами //rsync// делать резервное копирование сразу же по появлению нового файла в указанной директории. По-сути, выполняется односторонняя синхронизация в реальном времени с помощью Lsyncd.
1174
1175 //Lsyncd// просматривает дерево локальных директорий с помощью интерфейса модуля мониторинга //inotify//. Он агрегирует и комбинирует события за несколько секунд и затем запускает процесс (или несколько процессов) синхронизации изменений. По умолчанию для этих целей используется //rsync//. Таким образом, //lsyncd// представляет собой легковесное решение для зеркалирования данных, сравнительно легкое в установке, не требующее специфичных файловых систем или блочных устройств, а также не влияющее на производительность файловой системы.
1176
1177 Для установки выполняем команды:
1178
1179 {{code language="bash"}}
1180 sudo apt install lsyncd
1181 {{/code}}
1182
1183 Разрешаем автозапуск сервиса и изменим пользователя, от имени которого запускается сервис (в нашем случае user):
1184
1185 {{code language="bash"}}
1186 sudo systemctl enable lsyncd
1187 sudo systemctl edit lsyncd
1188 ...
1189 User=user
1190 ...
1191 {{/code}}
1192
1193 Для настройки и запуска открываем конфигурационный файл:
1194
1195 {{code language="bash"}}
1196 sudo nano /etc/lsyncd.conf
1197 {{/code}}
1198
1199 Приводим его к виду:
1200
1201 {{code language="none"}}
1202 settings {
1203 logfile = "/var/log/lsyncd.log",
1204 statusFile = "/var/log/lsyncd.stat",
1205 statusInterval = 5,
1206 insist = true,
1207 nodaemon = false,
1208 }
1209 sync {
1210 default.rsyncssh,
1211 source = "/usr/share/ultima-vmc/conf/application.conf",
1212 host = "user@10.1.30.252",
1213 targetdir = "/usr/share/ultima-vmc/conf/application.conf",
1214 rsync = {
1215 _extra = { "-avz --rsync-path='sudo -u ultima-vmc rsync'" }
1216 }
1217 }
1218 sync {
1219 default.rsyncssh,
1220 source = "/home/ultima-vmc/Neyross/ultima-vmc/activiti.cfg.xml",
1221 host = "user@10.1.30.252",
1222 targetdir = "/home/ultima-vmc/Neyross/ultima-vmc/activiti.cfg.xml",
1223 rsync = {
1224 _extra = { "-avz --rsync-path='sudo -u ultima-vmc rsync'" }
1225 }
1226 }
1227 sync {
1228 default.rsyncssh,
1229 source = "/home/ultima-vmc/Neyross/ultima-vmc/resources/",
1230 host = "user@10.1.30.252",
1231 targetdir = "/home/ultima-vmc/Neyross/ultima-vmc/resources/",
1232 rsync = {
1233 _extra = { "-avzr --rsync-path='sudo -u ultima-vmc rsync'" }
1234 }
1235 }
1236 {{/code}}
1237
1238 где:
1239
1240 **settings** — общие настройки.
1241
1242 * //**logfile** //— путь до файла логов.
1243 * //**statusFile** //— файл, в который заносятся изменения, найденные с помощью inotify.
1244 * //**statusInterval** //— интервал в секундах для обновления statusFile.
1245 * //**insist** //— позволяет продолжить работу сервиса, даже если одна или несколько целевых директорий недоступны.
1246 * //**nodaemon** //— отключаться или нет от вызывающей стороны. Проще говоря, если разрешить, то будет больше информации по его работе. Для боевого режима можно отключить.
1247
1248 **sync **— настройка для синхронизации конкретного ресурса. Для каждого создается своя секция sync.
1249
1250 * //**default.rsyncssh**// — в качестве протокола будем использовать rsync через ssh.
1251 * //**source**// — указываем источник данных, откуда синхронизируем данные.
1252 * //**host**// — удаленный компьютер, на который будет идти передача данных. До знака @ указывается пользователь, под которым будет идти подключение.
1253 * **//targetdir//** — каталог на удаленном хосте, в который будет выполняться синхронизация.
1254 * //**rsync, _extra**// — дополнительные ключи запуска rsync. В нашем примере запускаем в режиме архивирования.
1255
1256 После на узле источника (node1) перезапускаем lsyncd:
1257
1258 {{code language="bash"}}
1259 sudo systemctl restart lsyncd
1260 {{/code}}
1261
1262 Мы можем задать права после синхронизации. Это настраивается в конфигурационном файле ///etc/lsyncd.conf// в блоке //sync// раздела //rsync//:
1263
1264 \\
1265
1266 {{code language="none"}}
1267 sync {
1268 ...
1269 rsync = {
1270 ...
1271 owner=true,
1272 chown="ultima-vmc:ultima-vmc"
1273 chmod="775"
1274 perms=true
1275 }
1276 }
1277 {{/code}}
1278
1279 //где~://
1280
1281 * //**owner** — говорит, сохранять ли владельца файла.//
1282 * //**chown** — задает конкретного владельца и группу.//
1283 * //**chmod** — задает права на синхронизированные файлы.//
1284 * //**perms** — говорит, сохранять ли права.//
1285
1286 При необходимости, мы можем установить некоторые значения для ограничения или обхода ограничений. Настройки задаются в блоке settings:
1287
1288 \\
1289
1290 {{code language="none"}}
1291 settings {
1292 ...
1293 statusInterval = 5
1294 maxDelays = 900,
1295 maxProcesses = 6,
1296 }
1297 {{/code}}
1298
1299 //где~://
1300
1301 * //**statusInterval** — задает интервал обновления статус-файла в секундах. Чем ниже значение, тем быстрее файлы попадают в очередь для синхронизации.//
1302 * //**maxDelays** — задает количество файлов в очереди, при достижении которого задачи синхронизации будут запускаться ниже таймера задержки.//
1303 * //**maxProcesses** — максимальное количество процессов, которое сможет запустить lsync.//
1304
1305 Мы можем настроить исключение файлов по маске, которые не нужно передавать в другую директорию. Это делается с помощью опций //exclude// или //excludeFrom// в разделе //sync//, например:
1306
1307 \\
1308
1309 {{code language="none"}}
1310 sync {
1311 ...
1312 exclude = { '*.bak' , '*.tmp' },
1313 }
1314 sync {
1315 ...
1316 excludeFrom="/etc/lsyncd.exclude",
1317 }
1318 {{/code}}
1319
1320 в первом блоке мы исключим все файлы, которые заканчиваются на //.bak// или //.tmp//. Для второго мы будем использовать файл ///etc/lsyncd.exclude//, в котором перечислим исключения.
1321
1322 Для второго блока создаем файл с исключениями:
1323
1324 {{code language="bash"}}
1325 nano /etc/lsyncd.exclude
1326 {{/code}}
1327
1328 {{code language="java"}}
1329 *.tmp
1330 *.bak
1331 testfile.txt
1332 test/
1333 {{/code}}
1334
1335 в данном примере мы игнорируем файлы, заканчиваются на //.bak// или //.tmp//,а также файл //testfile.txt// и содержимое каталога //test//.
1336
1337 \\
1338
1339 Файл конфигурации сервиса (демона) //rsync// :
1340
1341 {{code language="bash"}}
1342 sudo cat /etc/rsyncd.conf
1343 {{/code}}
1344
1345 cat /etc/default/rsync
1346
1347 Запуск rsync в режиме демона: sudo rsync ~-~-daemon
1348
1349 Создаем ресурс с именем //HA-neyross-rsync// типа //rsyncd// для управления конфигурацией исполняемого сервиса и сразу добавим созданный ресурс в группу, чтобы он запускался вместе на одном узле с другими ресурсами:
1350
1351 {{code language="bash"}}
1352 sudo pcs resource create HA-neyross-rsync lsb:rsync \
1353 op monitor depth="0" timeout="20s" interval="60s"
1354 --group master-group
1355 {{/code}}
1356
1357 ----
1358
1359 == {{id name="ОтказоустойчивыйкластерПлатформыНЕЙРОСС-Видыплановогообслуживанияотказоустойчивогокластера"/}}Виды планового обслуживания отказоустойчивого кластера ==
1360
1361 Для проведения регламентных работ необходимо периодически выводить из состава кластера отдельные узлы:
1362
1363 * Выведение из эксплуатации Мастера или Реплики для плановых работ нужно в следующих случаях
1364 * Замена вышедшего из строя оборудования (не приведшего к сбою);
1365 * Обновление оборудования;
1366 * Обновление программных средств;
1367 * Смена ролей Мастера и Реплики. Это нужно в случае, когда, серверы Мастера и Реплики отличаются по ресурсам. Например, у нас в составе отказоустойчивого кластера есть мощный сервер, выполняющий роль Мастера СУБД PostgreSQL, и слабый сервер, выполняющий роль Реплики. После сбоя более мощного сервера Мастера его функции переходят к более слабой Реплике. Логично, что после устранения причин сбоя на бывшем Мастере администратор вернёт роль Мастера обратно на мощный сервер.
1368
1369 {{info title="Важно!"}}
1370 Прежде чем производить смену ролей или вывод Мастера из эксплуатации, необходимо с помощью команды //crm_mon -Afr// убедиться, что в кластере присутствует синхронная реплика. И роль Мастера назначается всегда синхронной реплике.
1371 {{/info}}
1372
1373 Типовая процедура восстановления кластера с возвратом ролей (исходно NODE1 роль Master и NODE2 роль Slave). Например, требуется проведение регламента на железе узла NODE1.
1374
1375 * Перевод узла //node1// в //standby//
1376
1377 {{code language="java"}}
1378 sudo pcs node standby node1
1379 {{/code}}
1380
1381 \\
1382
1383 * Проверка в //crm_mon -Afr// состояние узла NODE1 STANDBY, роль //Master// перешла узлу NODE2, изменение состояния реплики (параметр HA-pgsql-data-status в значении DISCONNECT)
1384 * Останов, проведение регламентных работ, в //crm_mon -Afr// состояние узла NODE1 OFFLINE
1385 * Запуск узла NODE1 , в //crm_mon -Afr// состояние узла STANDBY
1386 * Очистка директории СУБД и файла блокировки
1387
1388 {{code language="java"}}
1389 sudo rm /var/lib/pgsql/tmp/PGSQL.lock
1390 sudo su - postgres
1391 rm -rf /var/lib/postgresql/12/main/*
1392 {{/code}}
1393
1394 \\
1395
1396 * Передача текущей копии БД с действующего узла в роли //Master//
1397
1398 {{code language="java"}}
1399 pg_basebackup -U postgres -D /var/lib/postgresql/12/main -h 10.1.30.252 -X stream -P
1400 exit
1401 {{/code}}
1402
1403 \\
1404
1405 * Сброс ошибок ресурсов
1406
1407 {{code language="java"}}
1408 sudo pcs resource cleanup
1409 {{/code}}
1410
1411 \\
1412
1413 * Выход узла NODE1 из standby, в //crm_mon -Afr// состояние узла //Slave//, изменение состояния реплики (параметр HA-pgsql-data-status в значении STREAMING|SYNC)
1414
1415 {{code language="java"}}
1416 sudo pcs node unstandby node1
1417 {{/code}}
1418
1419 \\
1420
1421 * Перевод узла NODE2 в //standby//
1422
1423 {{code language="java"}}
1424 sudo pcs node standby node2
1425 {{/code}}
1426
1427 \\
1428
1429 * Проверка в// crm_mon -Afr// состояние узла// node2 //STANDBY, роль// Master// перешла узлу// node1//, изменение состояния реплики (параметр HA-pgsql-data-status в значении DISCONNECT)
1430
1431 * Выход узла //node2// из //standby//, в //crm_mon -Afr// состояние узла //Slave//, изменение состояния реплики (параметр HA-pgsql-data-status в значении STREAMING|SYNC)
1432
1433 {{code language="java"}}
1434 sudo pcs node unstandby node2
1435 {{/code}}
1436
1437
1438 \\

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