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

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