[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...