[RH7] Konfiguracja fensowania nodów klastra

Red Hat 7.x / CentOS 7.x

Fensowanie jest wymogiem każdego klastra wysokiej dostępności. Zapobiega ono uszkodzeniom struktury danych spowodowanych przez błędnie działający node.
Zależnie od hardware'u na jakim działa klaster procers fensowania może wyłączyć komunikację sieciową uszkodzonego node'a ze współdzielonym zasobem storage'owym, lub zrestartować problematyczny węzeł klastra.

Pierwszym krokiem konfiguracji fensowania jest konfiguracja urządzenia fensującego - może to być np. UPS pod który node jest podłączony,  jego PDU (Power Distribution Unit), urządzenie kontrolujące zasilanie Blade'a.

Listę dostępnych modułów fensowania uzyskamy wydając polecenie:

[root@clusternode1 ~]# pcs stonith list
fence_apc - Fence agent for APC over telnet/ssh
fence_apc_snmp - Fence agent for APC, Tripplite PDU over SNMP
fence_bladecenter - Fence agent for IBM BladeCenter
fence_brocade - Fence agent for HP Brocade over telnet/ssh
fence_cisco_mds - Fence agent for Cisco MDS
fence_cisco_ucs - Fence agent for Cisco UCS
fence_compute - Fence agent for the automatic resurrection of OpenStack compute instances
fence_drac5 - Fence agent for Dell DRAC CMC/5
fence_eaton_snmp - Fence agent for Eaton over SNMP
fence_emerson - Fence agent for Emerson over SNMP
fence_eps - Fence agent for ePowerSwitch
fence_hpblade - Fence agent for HP BladeSystem
fence_ibmblade - Fence agent for IBM BladeCenter over SNMP
fence_idrac - Fence agent for IPMI
fence_ifmib - Fence agent for IF MIB
fence_ilo - Fence agent for HP iLO
fence_ilo2 - Fence agent for HP iLO
fence_ilo3 - Fence agent for IPMI
fence_ilo3_ssh - Fence agent for HP iLO over SSH
fence_ilo4 - Fence agent for IPMI
fence_ilo4_ssh - Fence agent for HP iLO over SSH
fence_ilo_moonshot - Fence agent for HP Moonshot iLO
fence_ilo_mp - Fence agent for HP iLO MP
fence_ilo_ssh - Fence agent for HP iLO over SSH
fence_imm - Fence agent for IPMI
fence_intelmodular - Fence agent for Intel Modular
fence_ipdu - Fence agent for iPDU over SNMP
fence_ipmilan - Fence agent for IPMI
fence_kdump - Fence agent for use with kdump
fence_mpath - Fence agent for multipath persistent reservation
fence_rhevm - Fence agent for RHEV-M REST API
fence_rsa - Fence agent for IBM RSA
fence_rsb - I/O Fencing agent for Fujitsu-Siemens RSB
fence_scsi - Fence agent for SCSI persistentl reservation
fence_virt - Fence agent for virtual machines
fence_vmware_soap - Fence agent for VMWare over SOAP API
fence_wti - Fence agent for WTI
fence_xvm - Fence agent for virtual machines

Każdy z modułów posiada specyficzne opcje, które możemy sprawdzić poprzez:

[root@clusternode1 ~]# pcs stonith describe fence_virt
fence_virt - Fence agent for virtual machines

fence_virt is an I/O Fencing agent which can be used withvirtual machines.

Stonith options:
  debug: Specify (stdin) or increment (command line) debug level
  serial_device: Serial device (default=/dev/ttyS1)
  serial_params: Serial Parameters (default=115200,8N1)
  channel_address: VM Channel IP address (default=10.0.2.179)
  ipport: TCP, Multicast, or VMChannel IP port (default=1229)
  port: Virtual Machine (domain name) to fence
  action: Fencing action (null, off, on, [reboot], status, list, monitor, metadata)
  timeout: Fencing timeout (in seconds; default=30)
  ipaddr: IP address to connect to in TCP mode (default=127.0.0.1 / ::1)
  auth: Authentication (none, sha1, [sha256], sha512)
  hash: Packet hash strength (none, sha1, [sha256], sha512)
  key_file: Shared key file (default=/etc/cluster/fence_xvm.key)
  delay: Fencing delay (in seconds; default=0)
  domain: Virtual Machine (domain name) to fence (deprecated; use port)
  priority: The priority of the stonith resource. Devices are tried in order of highest priority to lowest.
  pcmk_host_map: A mapping of host names to ports numbers for devices that do not support host names.
  pcmk_host_list: A list of machines controlled by this device (Optional unless pcmk_host_check=static-list).
  pcmk_host_check: How to determine which machines are controlled by the device.
  pcmk_delay_max: Enable random delay for stonith actions and specify the maximum of random delay

W przypadku środowiska wirtualnego opartego o VirtualBox problematyczne (jeśli nie niemożliwe) jest skonfigurowanie fensowania opartego o zasilanie maszyny, dlatego użyjemy zasobu dyskowego, który będzie naszym urządzeniem fensującym. W tym celu utworzyłem na dodatkowej maszynie zasób iSCSI, który podłączyłem do wszystkich nodów klastra. (tutaj znajdziesz jak udostępniać zasób iSCSI oraz jak podłączyć serwer do zasobu).
iSCSI pojawiło się na wszystkich maszynach jako /dev/sdb. Teraz musimy zdefiniować w stonith nasze urządzenie fensujące.

[root@clusternode1 ~]# pcs stonith create iscsi-shooter fence_scsi devices=/dev/sdb meta provides=unfencing

Wpis meta provides=unfencing jest opcją, którą należy dodawać w przypadku korzystania z urządzeń fensujących nie opartych o zasilanie. Dba ona, aby przed restartem fensowanego node'a został on "odfensowany", czyli gwarantuje start usług klastrowych i pełne przyłączneie do klastra.

Po dodaniu urządzenia, sprawdzimy, czy utworzyło się ono poprawnie:

[root@clusternode1 ~]# pcs stonith show
 iscsi-shooter  (stonith:fence_scsi):   Started clusternode1

Jak widać, urządzenie działa, więc teoretycznie powinniśmy być w stanie wymusić fensowanie poszczególnych nodów klastra, sprawdźmy zatem:

[root@clusternode1 ~]# pcs cluster status
Cluster Status:
 Last updated: Tue Mar 15 18:30:03 2016         Last change: Tue Mar 15 18:16:10 2016 by root via cibadmin on clusternode3
 Stack: corosync
 Current DC: clusternode1 (version 1.1.13-10.el7_2.2-44eb2dd) - partition with quorum
 3 nodes and 1 resource configured
 Online: [ clusternode1 clusternode2 clusternode3 ]

PCSD Status:
  clusternode1: Online
  clusternode2: Online
  clusternode3: Online
[root@clusternode1 ~]# pcs stonith fence clusternode2
Node: clusternode2 fenced
[root@clusternode1 ~]# pcs stonith fence clusternode3
Node: clusternode3 fenced
[root@clusternode1 ~]# pcs cluster status
Cluster Status:
 Last updated: Tue Mar 15 18:30:18 2016         Last change: Tue Mar 15 18:16:10 2016 by root via cibadmin on clusternode3
 Stack: corosync
 Current DC: clusternode1 (version 1.1.13-10.el7_2.2-44eb2dd) - partition with quorum
 3 nodes and 1 resource configured
 Node clusternode2: pending
 Node clusternode3: pending
 Online: [ clusternode1 ]

PCSD Status:
  clusternode1: Online
  clusternode2: Online
  clusternode3: Online

Jak widać dwa nody odłączyły się od klastra, czyli fensowanie działa. Na takim zfensowanym węźle, próba wyświetlenia statusu klastra zakończy się tak:

[root@clusternode2 ~]# pcs cluster status
Error: cluster is not currently running on this node

W przypadku, kiedy fensowanie nie jest oparte o zasilanie, czyli wadliwa maszyna nie jest restartowana, po usunięciu problemów należy przywrócić działanie takiej maszyny startując usługę klastrową:

[root@clusternode2 ~]# pcs cluster start
Starting Cluster...
[root@clusternode2 ~]# pcs cluster status
Cluster Status:
 Last updated: Tue Mar 15 18:35:12 2016         Last change: Tue Mar 15 18:16:10 2016 by root via cibadmin on clusternode3
 Stack: corosync
 Current DC: clusternode1 (version 1.1.13-10.el7_2.2-44eb2dd) - partition with quorum
 3 nodes and 1 resource configured
 Node clusternode3: pending
 Online: [ clusternode1 clusternode2 ]

PCSD Status:
  clusternode1: Online
  clusternode2: Online
  clusternode3: Online

Testując ten wariant fensowania, zetknąłem się z jednym błędem. Po fensowaniu maszyn clusternode2 i clusternode3 wykonanym z maszyny clusternode1, a następnie ponownym ich przywróceniu do klastra, nie mogłem fensować maszyny clusternode1 z pozostałych maszyn. Problem objawiał się następująco:

[root@clusternode2 ~]# pcs stonith fence clusternode1
Error: unable to fence 'clusternode1'
Command failed: No route to host

Przyczyną okazały się problemy z odświeżaniem informacji o konfiguracji urządzenia fensującego scsi. Rozwiązaniem natomiast okazało się wymuszenie jej odświeżenia:

[root@clusternode2 ~]# pcs stonith cleanup
Waiting for 1 replies from the CRMd. OK

[root@clusternode2 ~]# pcs stonith fence clusternode1
Node: clusternode1 fenced

Okazuje się, że komenda pcs stonith show pokazuje status urządzenia fensującego jako Stopped, gdy którykolwiek z nodów klastra jest niedostępny.
Testowo utworzyłem na każdym z nodów inne urządzenie fensujące, oparte o ten sam dysk - jeden zasób iscsi, i na każdym z nodów wydane polecenie pcs stonith create ze wskazaniem na dysk /dev/sdb, ale różnymi nazwami urządzenia - w rezultacie pcs stonith show pokazywał jako zastopowane jedynie urządzenie na zfensowanym nodzie...

[RH7] Tworzenie klastra wysokiej dostępności

Red Hat 7.x / CentOS 7.x

Na oprogramowanie umożliwiające uruchomienie klastra HA w systemach RHEL/Centos 7.x składają się trzy główne komponenty:

pacemaker - komponent odpowiedzialny za całość aktywności klastrowej, np: monitoring członkostwa w klastrze, zarządzanie serwisami i zasobami klastra czy fensowanie członków klastra. Na pacemaker'a składają się cztery główne funkcjonalności:
- Cluster Information Base (CIB) - zawierający konfigurację i informacje o statusie samego klastra jak i wszystkich jego komponentów, przechowywaną w formie XML
- Policy Engine (PEngine) - określający na podstawie informacji zawartych w CIB najlepszą drogę dostępu i optymalną konfigurację klastra
- Cluster Resource Management Deamon (CRMd) - koordynuje zatrzymanie, uruchamianie i sprawdzanie statusu lokalnych demonów zarządzania klastrem (Local Resource Management Deamon - LRMd)
- Shoot the Other Node in the Head (STONITH) - funkcjonalność odpowiedzialna za fensowanie urządzeń klastra skonfigurowanych w CIB

corosync - to framework używany przez pacemaker'a do obsługi komunikacji pomiędzy nodami klastra. Dostarcza on pacemaker'owi informacji o członkostwie i quorum klastra

pcs (Pacemaker Configuration System) - zawiera dwa narzędzia konfiguracji klastra: 
- komenda pcs dostarcza interfejs do tworzenia, konfiguracji i kontroli wszystkich parametrów klastra
- demon pcsd dba o synchronizację konfiguracji nodów oraz dostarcza interfejs tworzenia i konfiguracji klastra.

Dodatkowym oprogramowaniem wymaganym do działania jest pakiet umożliwiający fensowanie urządzeń środowiska klastra. Pakiet ten występuje w wielu wersjach dedykowanych do różnego rodzaju sprzętu. Liczba dedykowanych agentów waha się w okolicach 30, i należałoby dobrać odpowiedni dla swojego środowiska - lub skorzystać z paczki zbiorczej fence-agents-all. Pełna lista dostępna jest w yum:

[root@clusternode1 ~]# yum search fence-agents

Z zagadnień teoretycznych należałoby wspomnieć o portach, któymi klaster komunikuje się sieciowo, gdyż porty te muszą zostać otwarte na lokalnym oraz zewnętrznych firewall'ach. Będą to:
- 5404(UDP), 5405(UDP) - corosync
- 2224(TCP) - pcsd
- 3121(TCP) - pacemaker
- 21064(TCP) - dlm - używany przez GFS2

Selinux w trybie enforcing jest w pełni wspierany, jeśli korzystamy z polityki targeted.

Tyle teorii, zabieramy się więc do tworzenia klastra.

Jak pisałem wcześniej do działania klastra będziemy potrzebować kilku paczek. Część z nich jest zależna od innych i zostanie doinstalowana automatycznie przez yum, dlatego wystarczy, że zainstalujemy tylko dwie z nich:

[root@clusternode1 ~]# yum install pcs fence-agents-all

Na środowiskach produkcyjnych nie jest konieczna instalacja wszystkich agentów i wystarczy dobrać odpowiedni do naszych potrzeb...

Kolejnym etapem będzie umożliwienie komunikacji, poprzez otwarcie lokalnego firewall'a. W wersji 7 nie ma konieczności wprowadzania poszczególnych reguł ruchu, a całość konfiguracji możemy udrożnić dodając odpowiedni serwis do demona firewalld:

[root@clusternode1 ~]# firewall-cmd --permanent --add-service=high-availability
success
[root@clusternode1 ~]# firewall-cmd --reload
success

Oczywiście włączamy demona pcs w systemctl, aby startował wraz z systemem, oraz uruchamiamy go, wykonując na wszystkich node'ach polecenia:

[root@clusternode1 ~]# systemctl enable pcsd
Created symlink from /etc/systemd/system/multi-user.target.wants/pcsd.service to /usr/lib/systemd/system/pcsd.service.
[root@clusternode1 ~]# systemctl start pcsd

Szybka weryfikacja, czy wszystko przebiegło po naszej myśli:

[root@clusternode1 ~]# systemctl is-enabled pcsd
enabled
[root@clusternode1 ~]# systemctl status pcsd
● pcsd.service - PCS GUI and remote configuration interface
   Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2016-03-03 20:47:01 CET; 34s ago
 Main PID: 10424 (pcsd)
   CGroup: /system.slice/pcsd.service
           ├─10424 /bin/sh /usr/lib/pcsd/pcsd start
           ├─10428 /bin/bash -c ulimit -S -c 0 >/dev/null 2>&1 ; /usr/bin/ruby -I/usr/lib/pcsd /usr/lib/pcsd/ssl.rb
           └─10429 /usr/bin/ruby -I/usr/lib/pcsd /usr/lib/pcsd/ssl.rb

Mar 03 20:47:00 clusternode1 systemd[1]: Starting PCS GUI and remote configuration interface...
Mar 03 20:47:01 clusternode1 systemd[1]: Started PCS GUI and remote configuration interface.

Operacje powtarzamy na wszystkich node'ach przyszłego klastra.

Po instalacji w systemie zaistniał nowy użytkownik systemowy, który używany będzie do komunikacji w klastrze - Red Hat zaleca konfigurację jednakowych haseł dla tego użytkownika na wszystkich node'ach, choć z punktu widzenia bezpieczeństwa zalecenie to może budzić pewne wątpliwości... Skonfigurujmy więc hasło:

[root@clusternode1 ~]#  echo naszklaster | passwd --stdin hacluster
Changing password for user hacluster.
passwd: all authentication tokens updated successfully.

Jeśli nasze maszyny nie posiadają wpisów w dns, najwygodniej będzie je dodać do /etc/hosts

Jako, że nody klastra wymagają autoryzacji użytkownika hacluster, wykonujemy takową na jednym z node'ów przyszłego klastra:

[root@clusternode1 ~]# pcs cluster auth clusternode1 clusternode2 clusternode3
Username: hacluster
Password:
clusternode2: Authorized
clusternode3: Authorized
clusternode1: Authorized

Do celów automatyzacyjnych/skryptowych przydatne mogą okazać się przełączniki do pcs -u hacluster -p naszklaster.

Zasadniczo podstawowa konfiguracja jest już wykonana, więc możemy spróbować uruchomić nasz klaster:

[root@clusternode1 ~]# pcs cluster setup --start --name PierwszyKlaster clusternode1 clusternode2 clusternode3
Shutting down pacemaker/corosync services...
Redirecting to /bin/systemctl stop  pacemaker.service
Redirecting to /bin/systemctl stop  corosync.service
Killing any remaining services...
Removing all cluster configuration files...
clusternode1: Succeeded
clusternode2: Succeeded
clusternode3: Succeeded
Starting cluster on nodes: clusternode1, clusternode2, clusternode3...
clusternode3: Starting Cluster...
clusternode1: Starting Cluster...
clusternode2: Starting Cluster...
Synchronizing pcsd certificates on nodes clusternode1, clusternode2, clusternode3...
clusternode2: Success
clusternode3: Success
clusternode1: Success

Restaring pcsd on the nodes in order to reload the certificates...
clusternode2: Success
clusternode3: Success
clusternode1: Success

Możemy zweryfikować status naszego klastra:

[root@clusternode1 ~]# pcs cluster status
Cluster Status:
 Last updated: Thu Mar  3 21:24:51 2016         Last change: Thu Mar  3 21:15:09 2016 by hacluster via crmd on clusternode1
 Stack: corosync
 Current DC: clusternode1 (version 1.1.13-10.el7_2.2-44eb2dd) - partition with quorum
 3 nodes and 0 resources configured
 Online: [ clusternode1 clusternode2 clusternode3 ]

PCSD Status:
  clusternode1: Online
  clusternode2: Online
  clusternode3: Online

Musimy pamiętać tu o jednym fakcie. Domyślna konfiguracja powoduje, że w przypadku restartu node'a nie podłącza on się automatycznie do klastra. W takiej sytuacji na działającym node uzyskamy komunikat:

[root@clusternode1 ~]# pcs cluster status
Cluster Status:
 Last updated: Thu Mar  3 21:28:02 2016         Last change: Thu Mar  3 21:15:09 2016 by hacluster via crmd on clusternode1
 Stack: corosync
 Current DC: clusternode1 (version 1.1.13-10.el7_2.2-44eb2dd) - partition with quorum
 3 nodes and 0 resources configured
 Online: [ clusternode1 clusternode2 ]
 OFFLINE: [ clusternode3 ]

PCSD Status:
  clusternode1: Online
  clusternode2: Online
  clusternode3: Online

A na maszynie, która była zrestartowana:

[root@clusternode3 ~]# pcs cluster status
Error: cluster is not currently running on this node

Sytuacja ta jest prosta do naprawienia, wystarczy włączyć automatyczne dołączanie node'a do klastra, poprzez:

[root@clusternode1 ~]# pcs cluster enable --all
clusternode1: Cluster Enabled
clusternode2: Cluster Enabled
clusternode3: Cluster Enabled

Teraz, po restarcie node'a wszystkie znajdować się będą w statusie online.

[TIP] Uruchomienie node'a, który nie dołącza się automatycznie do klastra po restarcie wykonujemy poprzez egzekucję na nim komendy pcs cluster start