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

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