8. ОТКАЗОУСТОЙЧИВЫЙ КЛАСТЕР

Раздел «Отказоустойчивый кластер» включает следующие компоненты:
«Необходимое окружение и библиотеки»,
«Подготовительные этапы к установке кластера»,
«Действия в программе установке wiSLA»,
«Настройка скриптов для учёта кратковременных обрывов связи»,
«Действия по восстановлению работы кластера при выходе из строя одного из узлов ЦОД1»,
«Действия по восстановлению работы кластера при выходе из строя одного из узлов ЦОД2»,
«Действия по восстановлению работы кластера при выходе из строя третьей точки опоры».

Необходимое окружение и библиотеки
Подготовительные этапы к установке кластера
Действия в программе установки wiSLA
Настройка скриптов для учёта кратковременных обрывов связи
Действия по восстановлению работы кластера при выходе из строя одного из узлов ЦОД1
Действия по восстановлению работы кластера при выходе из строя одного из узлов ЦОД2
Действия по восстановлению работы кластера при выходе из строя третьей точки опоры

Необходимое окружение и библиотеки

Необходимые пакеты для установщика на oracle linux 8

autogen-libopts-5.18.12-8.el8.x86_64.rpm           ntpdate-4.2.6p5-29.el7.centos.2.x86_64.rpm
compat-openssl10-1.0.2o-4.el8.x86_64.rpm           pv-1.6.6-7.el8.x86_64.rpm
dialog-1.3-13.20171209.el8.x86_64.rpm              python3-bcrypt-3.1.6-2.el8.1.x86_64.rpm
glibc-langpack-ru-2.28-225.0.4.el8_8.6.x86_64.rpm  python3-paramiko-2.12.0-1.el8.noarch.rpm
libsodium-1.0.18-2.el8.x86_64.rpm                  python3-pynacl-1.3.0-5.el8.x86_64.rpm
ntp-4.2.6p5-29.el7.centos.2.x86_64.rpm             uuid-1.6.2-43.el8.x86_64.rpm

libnsl-2.28-225.0.4.el8_8.6.x86_64.rpm - пакет который ставился на 1-й и 4-й сервера
compat-openssl10-1.0.2o-4.el8.x86_64.rpm - для pgpool
uuid-1.6.2-43.el8.x86_64.rpm glibc-langpack-ru-2.28-225.0.4.el8_8.6.x86_64.rpm -Postgresql требует пакеты glibc-langpack-ru и uuid

На узлах 2,5(hadoop) должна быть организована "общая папка" , при создании файла в примонтированном gluster на одном узле, он должен появляться на другом

Скрипт для чистки всего(кроме pgpool), следует запускать перед установкой и после удаления из установщика.

Установщик не чистит папки в home директории. И установщик может не убрать процессы java, postgres, pgpool, если возникают проблемы при установке, запуске, остановки - проверить наличие процессов

for i in $(seq 1 7);
do
ssh 0001wislatest0$i sudo killall java
ssh 0001wislatest0$i sudo killall postgres 
ssh 0001wislatest0$i 'rm -rf /opt/wisla5/* /home/wisla/{hadoop,zookeeper,hbase,postgresql}'
done
ssh 0001wislatest02 rm -rf /mnt/glusterVol/* #где glusterVol - куда примонтировали gluster.

На самом деле установщик при установке видит что папки в home есть и на glusterVol есть папка hadoop, установщик предлагает на каждую папку запрос об удалении. Однако лучшим вариантом будет "почистить скриптом", т.к. это упростит работу.

Подготовительные этапы к установке кластера

Преимущества кластера

Настройка отказоустойчивого кластера wiSLA позволяет решить 2 задачи:

в случае отказа одного из ЦОД система сохраняет работоспособность;
в кластере работает балансировка нагрузки, что позволяет более эффективно использовать
аппаратные ресурсы серверов.

В примере будет показана установка системы wiSLA на отказоустойчивый контур, который включает в себя семь серверов, распределённых между двумя ЦОД (по три в каждом) и одним дополнительным сервером – «третьей точкой опоры» (см. рисунок 66). Для взаимодействия между серверами выделена подсеть «межсерверного взаимодействия».

Рис. 66 Логическая группировка серверов в отказоустойчивом контуре wiSLA

Дополнительно могут быть развернуты wisla contactor portals (но не на 3 и 6 ноде, где уже есть портал оператора)

Отказоустойчивый контур должен состоять минимум из двух блоков (ЦОД), которые включают в себя сервера с основными компонентами, и дополнительного сервера (третей точки опоры), с помощью которого контролируется доступность основных ЦОД и целостность кластера. Всего для отказоустойчивого контура должно быть выделено не менее пяти отдельных серверов. Желательно, чтобы аппаратная конфигурация серверов была одинаковой. В этом случае можно производить установку и обновление системы с помощью программы установки без ручного изменения параметров распределения оперативной памяти по компонентам.

В таблице приведён пример настройки отказоустойчивого контура, который содержит два ЦОД (по три сервера на каждом) и один дополнительный сервер (третья точки опоры).

Таблица 8 – Топология кластера (пример).

ЦОД / сервер	Имя сервера (hostname) / IP-адрес	Компоненты
ЦОД1	wislaserver01 / 192.168.1.101	PostgreSQL: Master Pgpool HBase: HRegionServer Hadoop: DataNode Zookeeper
	wislaserver02 / 192.168.1.102	HBase: HMaster, HRegionServer Hadoop: NameNode, DataNode Zookeeper
	wislaserver03 / 192.168.1.103	APP-server WEB-server HBase: HRegionServer Hadoop: DataNode Zookeeper
ЦОД2	wislaserver04 / 192.168.1.104	PostgreSQL: Slave Pgpool HBase: HRegionServer Hadoop: DataNode Zookeeper
	wislaserver05 / 192.168.1.105	HBase: HMaster, HRegionServer Hadoop: NameNode, DataNode Zookeeper
	wislaserver06 / 192.168.1.106	APP-server WEB-server HBase: HRegionServer Hadoop: DataNode Zookeeper
Дополнительный сервер	wislaserver07 / 192.168.1.107	Zookeeper, wiSLA-Installer

Предварительно для каждого сервера контура требуется базовая настройка, которая описана в разделе «Подготовка операционной системы к запуску программы установки». Для серверов с Hadoop NameNode (wislaserver02 и wislaserver05) потребуется дополнительно примонтировать блочное устройство, объем диска на обоих серверах должен быть одинаковым. Для серверов с Pgpool (wislaserver01 и wislaserver04) должен быть выделен IP-адрес в подсети межсерверного взаимодействия, который будет использовать Pgpool. Далее в примерах настройки используется «192.168.1.110».

На серверах с Pgpool (wislaserver01 и wislaserver04) также требуется убедиться в отсутствии alias-интерфейса

«eth0:10», где eth0 – корневой интерфейс, на котором настроена подсеть межсерверного взаимодействия, фактически может отличаться.

Настройка беспарольного доступа по SSH для межсерверного взаимодействия

Для корректной установки системы wiSLA и взаимодействия серверов контура должен быть организован беспарольный доступ по SSH под пользователем wisla по принципу «каждый с каждым». Также требуется беспарольный доступ под пользователем root между серверами с Pgpool и третей точкой опоры. При этом для доступа с сервера на сервер используется hostname. Для этого требуется выполнить следующие шаги:

!Внимание, возможно требуется после копирования длинных команд - заменять пробелы на пробелы

!Внимание, при изменении топологии, возможно корректирование предлагаемых комманд

1. На 7-й сервере добавить хосты в /etc/hosts

mkdir installDir; pushd installDir
host_prefix=0001wislatest0
echo 192.168.1.101 "$host_prefix"1 >> hostsForALL
echo 192.168.1.102 "$host_prefix"2>> hostsForALL
echo 192.168.1.103 "$host_prefix"3>> hostsForALL
echo 192.168.1.104 "$host_prefix"4>> hostsForALL
echo 192.168.1.105 "$host_prefix"5>> hostsForALL
echo 192.168.1.106 "$host_prefix"6>> hostsForALL
echo 192.168.1.107 "$host_prefix"7>> hostsForALL
cat hostsForALL | sudo tee -a /etc/hosts
hostnames="0001wislatest01 0001wislatest02 0001wislatest03 0001wislatest04 0001wislatest05 0001wislatest06 0001wislatest07"
hostnames_1_6="0001wislatest01 0001wislatest02 0001wislatest03 0001wislatest04 0001wislatest05 0001wislatest06"
hostnames_1_4_7="0001wislatest01 0001wislatest04 0001wislatest07"

2. На каждом сервере контура под пользователем wisla выполнить генерацию ключей, пароль оставить пустым (можно вообще 1 ключ создать и скопировать его везде):

su -l wisla
cd /home/wisla
ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa # или ssh-keygen -t rsa

Если не известен пароль, то необходимо:

зайти на хост на который нужно подключиться 
скопировать содержимое ~/.ssh/*.pub #ssh-keygen -t rsa если нет файла
добавить в конец файла ~/.ssh/authorized_keys

4. Скопировать /etc/hosts на каждый хост

for i in $hostnames_1_6; do cat hostsForALL | ssh "$i" 'sudo tee -a /etc/hosts';done 
for i in $hostnames_1_6; do ssh "$i" "sudo hostnamectl set-hostname $i";done

5. С каждого сервера контура под пользователем wisla выполнить копирование ключа на все остальные сервера для пользователя wisla и для пользователя root для части серверов(На серверах с Pgpool и дополнительном сервере под пользователем wisla выполнить копирование ключа на другие сервера с Pgpool или дополнительный сервер для пользователя root):

host_keys="$(for i in $hostnames;do ssh \"$i\" 'cat /home/wisla/.ssh/*.pub'; done)"

for i in $hostnames;do echo "$host_keys" | ssh "$i" tee -a /home/wisla/.ssh/authorized_keys; done

host_keys="$(for i in $hostnames_1_4_7;do ssh "$i" 'cat /home/wisla/.ssh/*.pub'; done)"

for i in $hostnames_1_4_7;do echo "$host_keys"| ssh "$i" 'sudo mkdir -p /root/.ssh; sudo tee -a /root/.ssh/authorized_keys'; done

6. Выполнить разовое подключение по SSH под пользователем wisla с каждого сервера на другие сервера, чтобы подтвердить добавление ключей удалённых серверов (по умолчанию отпечаток ключа будет храниться в файле /home/wisla/.ssh/known_hosts). При этом на вопрос «Are you sure you want to continue connecting (yes/no)?» требуется отвечать «yes». При подключении пароль удалённого сервера запрашиваться не должен.

Выполнить команду на каждом сервере под пользователем wisla:

for i in $hostnames; do ssh "$i" exit; done

Выполнить команду на 1 4 7 серверах под пользователем wisla:

for i in $hostnames_1_4_7; do ssh root@"$i" exit; done

В некоторых случаях доступ по root из ssh невозможен: следует проверить файл /etc/security/access.conf(ROOT:ALL) и файл /etc/ssh/sshd_config (PermitRootLogin yes)

Установка GlusterFS

GlusterFS – распределённая, параллельная, линейно масштабируемая файловая система с возможностью защиты от сбоев. Предварительно на серверах wislaserver02 и wislaserver05 должны быть созданы lvm-разделы абсолютно одинакового размера. Далее в примере используется «/dev/sdb1», фактически название раздела может отличаться.

Действия по установке и настройке GlusterFS выполняются под пользователем root.

Для установки GlusterFS на серверах wislaserver02 и wislaserver05 требуется выполнить следующие шаги:
1. Загрузить установочные пакеты GlusterFS по ссылке ftp://ftp.wellink.ru/Deploies/Centos/cluster/glusterfs.tar.gz ;
2. Подключиться к серверу по SSH под пользователем root;
3. Перейти в каталог с архивом, распаковать архив, установить необходимые пакеты glusterfs, glusterfs-server, glusterfs-cli,:

tar zxvf glusterfs.tar.gz
yum install glusterfs-3.5.2-1.el6.x86_64.rpm glusterfs-api-3.5.2-1.el6.x86_64.rpm
glusterfs-cli-3.5.2-1.el6.x86_64.rpm glusterfs-fuse-3.5.2-1.el6.x86_64.rpm glusterfs-georeplication-3.5.2-1.el6.x86_64.rpm glusterfs-libs-3.5.2-1.el6.x86_64.rpm glusterfsserver-3.5.2-1.el6.x86_64.rpm

Настройка GlusterFS

Для настройки работы GlusterFS требуется выполнить следующие шаги:

1. Рекомендовано на серверах wislaserver02 и wislaserver05 отформатировать раздел для glusterfs в файловую систему xfs:

mkfs.xfs /dev/sdb1

2. Смонтировать раздел, добавить в автозапуск и запустить glusterfs на wislaserver02 и wislaserver05:

mkdir -p /mnt/gluster && mount /dev/sdb1 /mnt/gluster && mkdir -p /mnt/gluster/brick
echo "/dev/sdb1 /mnt/gluster xfs defaults 0 0" >> /etc/fstab
systemctl start glusterd # /etc/init.d/glusterd start

3. На сервере wislaserver02 выполнить команды:

gluster peer probe "$host_prefix"5
gluster volume create namenodevol rep 2 transport tcp "$host_prefix"2:/mnt/gluster/brick
"$host_prefix"5:/mnt/gluster/brick
gluster volume start namenodevol
mkdir /mnt/glusterVol; mount -t glusterfs "$host_prefix"2:/namenodevol /mnt/glusterVol/
chown wisla:wisla -R /mnt/glusterVol

4. На сервере wislaserver05 выполнить команды:

mkdir /mnt/glusterVol; mount -t glusterfs "$host_prefix"5:/namenodevol /mnt/glusterVol/ 
chown wisla:wisla -R /mnt/glusterVol

Внимание, следует протестировать что файл созданный на одном узле в /mnt/glusterVol ,должен появиться в том же месте на другом узле

5. На сервере wislaserver02 выполнить команды:

touch /mnt/glusterVol/test_file.txt

6. На сервере wislaserver05 проверить наличие файла и затем файл можно удалить

ls /mnt/glusterVol/test_file.txt
rm -f /mnt/glusterVol/test_file.txt

Действия в программе установки wiSLA

Шаги для установки wiSLA описаны в разделе «Работа с программой установки». Но есть ряд отличий в процессе, они будут приведены ниже.
Программа установки предварительно должна быть скопирована на сервер wislaserver07 в домашний каталог пользователя wisla. Права на файл должны быть у пользователя wisla, и файл должен быть исполняемым. Далее требуется выполнить действия, которые перечислены в блоке «Перечень действий для установки wiSLA», с учётом отличий в настройках, которые описаны ниже:

После запуска установщика можно подложить файл топологии и конфигурации по привычному пути, но это "на свой страх и риск".

1. Запуск программы установки.

2. Запуск установки системы.

3. Топология. Потребуется указать топологию, описанную выше в таблице 8:

Application servers: wislaserver03 wislaserver06
Operator Web servers: wislaserver03 wislaserver06
Contractor Web servers: wislaserver03 wislaserver06
Postgres main (single server): wislaserver01
Postgres slaves: wislaserver04
Pgpool servers: wislaserver01 wislaserver04
Zookeeper quorum: wislaserver01 wislaserver02 wislaserver03 wislaserver04 wislaserver05 wislaserver06
wislaserver07
Hadoop/HBase masters: wislaserver02 wislaserver05
Hadoop/HBase workers: wislaserver01 wislaserver02 wislaserver03 wislaserver04 wislaserver05 wislaserver06

4. Ожидание инициализации модулей .

5. Оценка параметров сервера и подбор оптимальных значений по распределению памяти.

Нужно учитывать, что программа установки делает оценку физических параметров того сервера, на котором была запущена. Поэтому, если аппаратная конфигурация серверов контура отличается, то следует рассчитать распределение памяти и вручную изменять предлагаемые настройки модулей системы по ходу установки.

6. Выбор версии и архитектуры Java Runtime Environment.

7. Настройка компонента Zookeper.

8. Настройка компонента Hadoop:

Name directory: /mnt/glusterVol
Zookeeper quorum: wislaserver01:2181 wislaserver02:2181 wislaserver03:2181 wislaserver04:2181
wislaserver05:2181 wislaserver06:2181 wislaserver07:2181
Replication count: 4

Для настройки «Replication count» используется число, которое высчитывается по формуле:
(HadoopWorkersCount / 2) + 1, где HadoopWorkersCount – количество серверов, заданное в топологии в строке «Hadoop/HBase workers».

Также стоит отметить, что путь hdfs://wisla. Надо в hosts прописать на 1,3,4,6 сервере 127.0.0.1 wisla. Что-то где-то прибито гвоздями и порт должен быть 8020. wisla:8020 или - wisla не имеет разницы, так как это порт по умолчанию.

9. Настройка компонента HBase, стоит проверить путь к хадупу hdfs://wisla.

10. Настройка компонента PostgreSQL (без изменений). Возможно стоит взять более широкую маску сети(/24) причем раз это сеть, можно адрес сети написать
После шага 10 «Настройка компонента PostgreSQL» появится дополнительный шаг для конфигурирования Pgpool, на котором потребуется задать настройки:

Trust host or network: 192.168.1.0/24
Specifies the virtual IP address: 192.168.1.110
Specifies the netmask for virtual IP address: 255.255.255.0
Virtual interface: eth0

Trust host or network – подсеть межсерверного взаимодействия.
Specifies the virtual IP address – IP-адрес, который выделен для работы pgpool в подсети межсерверного взаимодействия.
Specifies the netmask for virtual IP address – маска подсети межсерверного взаимодействия.
Virtual interface – корневой интерфейс, на котором настроена подсеть межсерверного взаимодействия на серверах wislaserver01 и wislaserver04.

Указываем сеть в которой работает СУЩЕСТВУЮЩИЙ интерфейс, и указываем IP который НЕ используется. Также указываем СУЩЕСТВУЮЩИЙ интерфейс. pgpool на него навесит ip (причем ip уже должен быть назначен на всех хостах которые подключены в сеть, куда смотрит интерфейс). возможно стоит взять более широкую маску сети(/24)

a) для корректной работы pgpool желателен отдельный сетевой интерфейс. К примеру он может быть вланом.
b) pgpool назначает на интерфейс ip, а :10 это номер псевдонима.
c) в сети, на которую смотрит интерфейс должны быть назначены ip в той же подсети.
d) активный pgpool назначает на этот интерфейс ip.
e) если вы обращаетесь к PostgreSQL то должны быть подключены к сети, в которой есть pgpool

11. Настройка компонента WildFly:

app host for portal ... - пишем соответствующие ip для данных хостов

12. Настройка топологии wiSLA.

13. Настройки модуля сбора данных:

wiProbe destination - указываем, куда будут программные или аппаратные зонды стучаться

14. Настройки интеграции LDAP.

15. Настройки дополнительных ресурсов wiSLA.

16. Настройка рассылки уведомлений.

17. Настройка оператора портала.

Обращаем ваше внимание, если вы получаете доступ к порталу с помощью проброса портов или через прокси сервер, то вам необходимо отредактировать пункт HOST и в Whitelisted domains установить необходимые IP-адреса.

18. Подтверждение настроек.

19. Автоматический запуск после установки.

20. Реиндексация wildfly (не бд).

21. Начало работы с порталом.

Настройка скриптов для учёта кратковременных обрывов связи

Для настройки учёта кратковременных обрывов связи необходимо выполнить следующие шаги:

Предварительно следует создать каталог /opt/wisla5/scripts/ на серверах ЦОД1 и ЦОД2. Владельцем каталогов должен быть пользователь wisla. На серверах wislaserver03 и wislaserver06 эти каталоги будут созданы автоматически после установки wiSLA. Далее приведена команда для создания каталога:
```
mkdir -p /opt/wisla5/scripts
```
Архив со скриптами можно загрузить по ссылке ftp://ftp.wellink.ru/Deploies/Centos/cluster/failover_scripts.tar.gz, скопировать на любой из серверов кластера для пользователя wisla и распаковать с помощью команды:
```
tar zxvf failover_scripts.tar.gz
```
Владельцем скриптов и конфигурационных файлов должен быть пользователь wisla.
На сервере wislaserver04 в каталоге /opt/wisla5/pgpool/current/sbin/ переименовать файл ifconfig на ifconfig1 с помощью команды:
```
sudo mv /opt/wisla5/pgpool/current/sbin/ifconfig /opt/wisla5/pgpool/current/sbin/ifconfig1
```

Скопировать скрипты на сервера контура.
Для копирования рекомендуется использовать консольную утилиту scp. Пример команды копирования:

scp TRUSTED_SERVERS wisla@wislaserver01:/opt/wisla5/scripts/

В примере администратор находится в каталоге с распакованными скриптами, копирует файл
TRUSTED_SERVERS на сервер wislaserver01 в каталог /opt/wisla5/scripts/.
Таблица 7 – Размещение скриптов для учёта кратковременных обрывов связи.

Сервер	Файл	Путь
wislaserver01	TRUSTED_SERVERS	/opt/wisla5/scripts/
	isolation_test.sh	/opt/wisla5/scripts/
	pgpool_connect.sh	/opt/wisla5/scripts/
	DATA_PROCESSING_CENTER_SERVERS	/opt/wisla5/pgpool/current/
	TRUSTED_SERVERS	/opt/wisla5/pgpool/current/
	failover.sh	/opt/wisla5/pgpool/current/
wislaserver02	TRUSTED_SERVERS	/opt/wisla5/scripts/
wislaserver02	isolation_test.sh	/opt/wisla5/scripts/
wislaserver03	TRUSTED_SERVERS	/opt/wisla5/scripts/
wislaserver03	isolation_test.sh	/opt/wisla5/scripts/
wislaserver04	TRUSTED_SERVERS	/opt/wisla5/scripts/
	isolation_test.sh	/opt/wisla5/scripts/
	pgpool_connect.sh	/opt/wisla5/scripts/
	DATA_PROCESSING_CENTER_SERVERS	/opt/wisla5/pgpool/current/
	TRUSTED_SERVERS	/opt/wisla5/pgpool/current/
	failover.sh	/opt/wisla5/pgpool/current/
	ifconfig	/opt/wisla5/pgpool/current/sbin/
wislaserver05	TRUSTED_SERVERS	/opt/wisla5/scripts/
wislaserver05	isolation_test.sh	/opt/wisla5/scripts/
wislaserver06	TRUSTED_SERVERS	/opt/wisla5/scripts/
wislaserver06	isolation_test.sh	/opt/wisla5/scripts/

Сконфигурировать файлы со списком серверов и скрипты. Файл должен завершаться пустой строкой. Редакторы vi (vim) и nano делают это автоматически при сохранении файла.
wislaserver01:
В файле /opt/wisla5/scripts/TRUSTED_SERVERS указать список серверов ЦОД2 и третью точку опоры:
```
wislaserver04
wislaserver05
wislaserver06
wislaserver07
```
В файле /opt/wisla5/pgpool/current/DATA_PROCESSING_CENTER_SERVERS указать список
серверов ЦОД1:
```
wislaserver01
wislaserver02
wislaserver03
```
В файле /opt/wisla5/pgpool/current/TRUSTED_SERVERS указать третью точку опоры:
```
wislaserver07
```
В конфигурационном файле /opt/wisla5/pgpool/current/etc/pgpool.conf в опции trusted_servers (по умолчанию строка 442) указать сервер с pgpool ЦОД2 и третью точку опоры:
```
trusted_servers = 'wislaserver04,wislaserver07'
```
wislaserver02:
В файле /opt/wisla5/scripts/TRUSTED_SERVERS указать список серверов ЦОД2 и третью точку опоры:
```
wislaserver04
wislaserver05
wislaserver06
wislaserver07
```
wislaserver03:
В файле /opt/wisla5/scripts/TRUSTED_SERVERS указать список серверов ЦОД2 и третью точку опоры:
```
wislaserver04
wislaserver05
wislaserver06
wislaserver07
```
wislaserver04:
В файле /opt/wisla5/scripts/TRUSTED_SERVERS указать список серверов ЦОД1 и третью точку опоры:
```
wislaserver01
wislaserver02
wislaserver03
wislaserver07
```
В файле /opt/wisla5/pgpool/current/DATA_PROCESSING_CENTER_SERVERS указать список серверов ЦОД2:
```
wislaserver04
wislaserver05
wislaserver06
```
В файле /opt/wisla5/pgpool/current/TRUSTED_SERVERS указать третью точку опоры:
```
wislaserver07
```
В скрипте /opt/wisla5/pgpool/current/sbin/ifconfig указать (отредактировать) дополнительный IPадрес, который был зарезервирован для работы pgpool:
```
PGPOOL_ALIAS="192.168.1.110"
```
В конфигурационном файле /opt/wisla5/pgpool/current/etc/pgpool.conf в опции trusted_servers (строка 442) указать сервер с pgpool ЦОД1 и третью точку опоры:
```
trusted_servers = 'wislaserver01,wislaserver07'
```
wislaserver05:
В файле /opt/wisla5/scripts/TRUSTED_SERVERS указать список серверов ЦОД1 и третью точку опоры:
```
wislaserver01
wislaserver02
wislaserver03
wislaserver07
```
wislaserver06:
В файле /opt/wisla5/scripts/TRUSTED_SERVERS указать список серверов ЦОД1 и третью точку опоры:
```
wislaserver01
wislaserver02
wislaserver03
wislaserver07
```
Добавить в crontab задачи на запуск скриптов. Для этого под пользователем wisla нужно выполнить команду:
```
crontab -e
```
Открывается конфигурация cron для пользователя wisla в редакторе vim.
wislaserver01:
```
*/1 * * * * /opt/wisla5/scripts/isolation_test.sh
*/1 * * * * /opt/wisla5/scripts/pgpool_connect.sh
```
wislaserver02:
```
*/1 * * * * /opt/wisla5/scripts/isolation_test.sh
```
wislaserver03:
```
*/1 * * * * /opt/wisla5/scripts/isolation_test.sh
```
wislaserver04:
```
*/1 * * * * /opt/wisla5/scripts/isolation_test.sh
*/1 * * * * /opt/wisla5/scripts/pgpool_connect.sh
```
wislaserver05:
```
*/1 * * * * /opt/wisla5/scripts/isolation_test.sh
```
wislaserver06:
```
*/1 * * * * /opt/wisla5/scripts/isolation_test.sh
```
Перезапустить систему, используя программу установки wiSLA – в разделе Maintenance вначале выполнить «Stop all», затем «Start all».

Действия по восстановлению работы кластера при выходе из строя одного из узлов ЦОД1

Отказоустойчивый кластер фактически рассчитан только на один отказ одного из узлов кластера, после которого требуется восстановление его работы. В случае выхода из строя двух узлов система перестаёт функционировать.

при статусе:

psql -p 19999 -c "show pool_nodes"

node_id | hostname | port | status | lb_weight | role
---------+---------------+------+--------+-----------+---------
0 | wislaserver01 | 5432 | 3 | 0.500000 | standby
1 | wislaserver04 | 5432 | 2 | 0.500000 | primary

1)стопнуть вторую ноду из инсталлера
2)запустить вторую ноду из инсталлера

/opt/wisla5/pgpool/current/bin/pcp_recovery_node -p 9898 -h 10.198.2.17 -U wisla 1
#Password:  wisla

Дождаться выполнения -> все ок

Выход из строя ЦОД1

При выходе из строя ЦОД1 все компоненты переходят в активный режим на ЦОД2:

Pgpool на сервере wislaserver04 переводит PostgreSQL в режим master и активирует alias на интерфейс на сервере;
Hadoop и HBase на сервере wislaserver05 переходят в режим active;
wiSLA на сервере wislaserver06 забирает себе все задачи, которые ранее были распределены
между двумя серверами.

В данном случае требуется восстановить согласованность данных и перенести активные модули на ЦОД1. Потребуется полная остановка и запуск системы на обоих ЦОД. Для этого нужно выполнить следующие действия:
1. Восстановить связь между узлами кластера.
2. В отдельной сессии SSH на сервере wislaserver07 под пользователем wisla запустить программу установки.
3. В разделе «Maintenance» -> «wiSLA management» остановить wiSLA на всех серверах:

Stop_all

4. В разделе «Maintenance» -> «Pgpool management» запустить Pgpool на сервере wislaserver01:

Start on wislaserver01

5. Убедиться в том, что Pgpool на сервере wislaserver01 активирован. Для этого в разделе «Statuses» выбрать «Pgpool status».
6. В отдельной сессии SSH открыть shell сервера wislaserver04 под пользователем wisla.
7. На сервере wislaserver04 выполнить команду для просмотра состояния узлов PostgreSQL:

psql -p 19999 -c "show pool_nodes"

8. Убедиться в том, что сервер wislaserver04 имеет status «2» (активен) и role «primary», а wislaserver01 имеет status «3» (неактивен) и role «standby»:

node_id | hostname | port | status | lb_weight | role
---------+---------------+------+--------+-----------+---------
0 | wislaserver01 | 5432 | 3 | 0.500000 | standby
1 | wislaserver04 | 5432 | 2 | 0.500000 | primary

9. На сервере wislaserver04 выполнить команду:

ip a

и убедиться в наличии alias «eth0:10» на интерфейсе «eth0» .
10. В отдельной сессии SSH открыть командную строку сервера wislaserver01 под пользователем wisla.
11. На сервере wislaserver01 выполнить команду:

ip a

и убедиться в отсутствии alias «eth0:10» на интерфейсе «eth0».
12. На сервере wislaserver04 выполнить команду:

LD_LIBRARY_PATH=/opt/wisla5/pgpool/current/lib/ pcp_recovery_node -d 0 127.0.0.1 9898 wisla wisla 0

13. Дождаться выполнения команды, должно снова появиться приглашение для ввода.
14. Снова выполнить команду для просмотра состояния узлов PostgreSQL и убедиться в том, что сервер wislaserver01 уже имеет status «2» (активен) и role «primary», а wislaserver04 сохранил status «2» (активен), но изменил role на «standby».

[wisla@wislaserver04 ~]$ psql -p 19999 -c "show pool_nodes"
node_id | hostname | port | status | lb_weight | role
---------+---------------+------+--------+-----------+---------
0 | wislaserver01 | 5432 | 2 | 0.500000 | primary
1 | wislaserver04 | 5432 | 2 | 0.500000 | standby

15. В открытой программе установки остановить Pgpool на сервере wislaserver04. Для этого в разделе «Maintenance» -> «Pgpool management» выполнить:

Stop on wislaserver04

16. В открытой программе установки остановить PostgreSQL на сервере wislaserver04. Для этого в разделе «Maintenance» -> «Postgresql management» выполнить:

Stop on wislaserver04

17. В открытой программе установки запустить Pgpool на сервере wislaserver04. Для этого в разделе «Maintenance» -> «Pgpool management» выполнить:

Start on wislaserver04

18. Убедиться в том, что Pgpool на сервере wislaserver04 активирован. Для этого в разделе «Statuses» выбрать «Pgpool status».
19. На сервере wislaserver04 выполнить команду:

ip a

и убедиться в отсутствии alias «eth0:10» на интерфейсе «eth0».
20. На сервере wislaserver01 выполнить команду:

ip a

и убедиться в наличии alias «eth0:10» на интерфейсе «eth0».
21. На сервере wislaserver01 выполнить команду для просмотра состояния узлов PostgreSQL и убедиться в том, что сервер wislaserver01 имеет status «2» (активен) и role «primary», а wislaserver04 имеет status «3» (неактивен) и role «standby».

[wisla@wislaserver01 ~]$ psql -p 19999 -c "show pool_nodes"
node_id | hostname | port | status | lb_weight | role
---------+---------------+------+--------+-----------+---------
0 | wislaserver01 | 5432 | 2 | 0.500000 | primary
1 | wislaserver04 | 5432 | 3 | 0.500000 | standby

22. На сервере wislaserver01 выполнить команду (обратить внимание на замену числа 0 на 1 в конце команды):

LD_LIBRARY_PATH=/opt/wisla5/pgpool/current/lib/ pcp_recovery_node -d 0 127.0.0.1 9898 wisla wisla 1

23. Дождаться выполнения команды, должно снова появиться приглашение для ввода.
24. На сервере wislaserver01 повторно выполнить команду для просмотра состояния узлов PostgreSQL и убедиться в том, что сервер wislaserver01 сохранил status «2» (активен) и role «primary», а wislaserver04 изменил status на «2» (активен), role осталась «standby».

[wisla@wislaserver01 ~]$ psql -p 19999 -c "show pool_nodes"
node_id | hostname | port | status | lb_weight | role
---------+---------------+------+--------+-----------+---------
0 | wislaserver01 | 5432 | 2 | 0.500000 | primary
1 | wislaserver04 | 5432 | 2 | 0.500000 | standby

25. На сервере wislaserver04 выполнить команду:

tail -n 10 /home/wisla/postgresql/postgres.log

и убедиться в наличии строки:

database system is ready to accept read only connections

26. В отдельной сессии SSH открыть командную строку сервера wislaserver02 под пользователем root.
27. На сервере wislaserver02 выполнить команды:

systemctl start glusterd  #/etc/init.d/glusterd start
mount -t glusterfs wislaserver05:/namenodevol /mnt/glusterVol/

28. На сервере wislaserver02 убедиться в наличии непустого каталога /mnt/glusterVol/current/

ls /mnt/glusterVol/current/

29. В открытой программе установки в разделе «Maintenance» -> «HBase management» выполнить остановку HBase на всех серверах:

Stop_all

30. В открытой программе установки в разделе «Maintenance» -> «Hadoop management» выполнить остановку Hadoop на всех серверах:

Stop_all

31. В открытой программе установки в разделе «Maintenance» -> «Zookeeper management» выполнить остановку Zookeeper на всех серверах:

Stop_all

32. В открытой программе установки в разделе «Maintenance» -> «Zookeeper management» выполнить запуск Zookeeper на всех серверах:

Start_all

33. В открытой программе установки в разделе «Maintenance» -> «Hadoop management» выполнить запуск Hadoop на всех серверах:

Start_all

34. В открытой программе установки в разделе «Maintenance» -> «HBase management» выполнить запуск HBase на всех серверах:

Start_all

35. В открытой программе установки в разделе «Maintenance» -> «wiSLA management» выполнить запуск wiSLA на всех серверах:

Start_all

36. После запуска wiSLA проверить состояние компонентов системы в разделе «Statuses» -> «All statuses» и убедиться в работоспособности портала wiSLA.

Действия по восстановлению работы кластера при выходе из строя одного из узлов ЦОД2

Выход из строя ЦОД2

При выходе из строя ЦОД2 все компоненты остаются в активном режиме работы на ЦОД1. В данном случае требуется восстановить согласованность данных и восстановить работу системы на ЦОД2. Потребуется полная остановка и запуск системы на обоих ЦОД. Для этого нужно выполнить следующие действия:
1. Восстановить связь между узлами кластера.
2. В отдельной сессии SSH на сервере wislaserver07 под пользователем wisla запустить программу установки.
3. В разделе «Maintenance» -> «wiSLA management» остановить wiSLA на всех серверах:

Stop_all

4. В разделе «Maintenance» -> «Pgpool management» запустить Pgpool на сервере wislaserver04:

 Start on wislaserver04

5. Убедиться в том, что Pgpool на сервере wislaserver04 активирован. Для этого в разделе «Statuses» выбрать «Pgpool status».
6. В отдельной сессии SSH открыть командную строку сервера wislaserver01 под пользователем wisla.
7. На сервере wislaserver01 выполнить команду для просмотра состояния узлов PostgreSQL:

psql -p 19999 -c "show pool_nodes"

8. Убедиться в том, что сервер wislaserver01 имеет status «2» (активен) и role «primary», а wislaserver04 имеет status «3» (неактивен) и role «standby»:

node_id | hostname | port | status | lb_weight | role
---------+---------------+------+--------+-----------+---------
0 | wislaserver01 | 5432 | 2 | 0.500000 | primary
1 | wislaserver04 | 5432 | 3 | 0.500000 | standby

9. На сервере wislaserver01 выполнить команду:

ip a

и убедиться в наличии alias «eth0:10» на интерфейсе «eth0» .
10. В отдельной сессии SSH открыть командную строку сервера wislaserver04 под пользователем wisla.
11. На сервере wislaserver04 выполнить команду:

ip a

и убедиться в отсутствии alias «eth0:10» на интерфейсе «eth0».
12. На сервере wislaserver01 выполнить команду:

LD_LIBRARY_PATH=/opt/wisla5/pgpool/current/lib/ pcp_recovery_node -d 0 127.0.0.1 9898 wisla wisla 1

13. Дождаться выполнения команды, должно снова появиться приглашение для ввода.
14. На сервере wislaserver01 снова выполнить команду для просмотра состояния узлов PostgreSQL и убедиться в том, что сервер wislaserver01 сохранил status «2» (активен) и role «primary», а wislaserver04 изменил status на «2» (активен), role осталась «standby».

[wisla@wislaserver01 ~]$ psql -p 19999 -c "show pool_nodes"
node_id | hostname | port | status | lb_weight | role
---------+---------------+------+--------+-----------+---------
0 | wislaserver01 | 5432 | 2 | 0.500000 | primary
1 | wislaserver04 | 5432 | 2 | 0.500000 | standby

15. На сервере wislaserver04 выполнить команду:

ip a

и убедиться в отсутствии alias «eth0:10» на интерфейсе «eth0».
16. На сервере wislaserver01 выполнить команду:

ip a

и убедиться вналичии alias «eth0:10» на интерфейсе «eth0» .
17. На сервере wislaserver04 выполнить команду:

tail -n 10 /home/wisla/postgresql/postgres.log

и убедиться в наличии строки:

database system is ready to accept read only connections

18. В отдельной сессии SSH открыть командную строку сервера wislaserver05 под пользователем root.
19. На сервере wislaserver05 выполнить команды:

systemctl start glusterd #/etc/init.d/glusterd start
mount -t glusterfs wislaserver02:/namenodevol /mnt/glusterVol/

20. На сервере wislaserver05 убедиться в наличии непустого каталога /mnt/glusterVol/current/

ls /mnt/glusterVol/current/

21. В открытой программе установки в разделе «Maintenance» -> «HBase management» выполнить остановку HBase на всех серверах:

Stop_all

22. В открытой программе установки в разделе «Maintenance» -> «Hadoop management» выполнить остановку Hadoop на всех серверах:

Stop_all

23. В открытой программе установки в разделе «Maintenance» -> «Zookeeper management» выполнить остановку Zookeeper на всех серверах:

Stop_all

24. В открытой программе установки в разделе «Maintenance» -> «Zookeeper management» выполнить запуск Zookeeper на всех серверах:

Start_all

25. В открытой программе установки в разделе «Maintenance» -> «Hadoop management» выполнить запуск Hadoop на всех серверах:

Start_all

26. В открытой программе установки в разделе «Maintenance» -> «HBase management» выполнить запуск HBase на всех серверах:

Start_all

27. В открытой программе установки в разделе «Maintenance» -> «wiSLA management» выполнить запуск wiSLA на всех серверах:

Start_all

28. После запуска wiSLA проверить состояние компонентов системы в разделе «Statuses» -> «All statuses» и убедиться в работоспособности портала wiSLA.

Действия по восстановлению работы кластера при выходе из строя третьей точки опоры

Данная ситуация не влияет на работоспособность контура, но грозит отказом системы в случае выхода из строя одного из ЦОД. Для восстановления работы третьей точки опоры требуется выполнить следующие действия:
1. Восстановить связь между узлами кластера.
2. На сервере wislaserver07 запустить программу установки.
3. В разделе «Maintenance» -> «Zookeeper management» запустить Zookeeper на сервере wislaserver07:

Start on wislaserver07

4. Проверить состояние компонентов системы в разделе «Statuses» -> «All statuses» и работоспособность wiSLA.