INUVIKA TECHNICAL GUIDE

Transcription

1 Version 1.5 May 22, 2018 Passing on or copying of this document, use and communication of its content not permitted without Inuvika written approval

2 PREFACE The purpose of this document is to provide a failover mechanism for the Inuvika OVD Session Manager role (OSM) and the additional roles that may be hosted on the OSM servers. Page 2

3 HISTORY Version Date Comments Upgrades for 2.5, add better support for sessions sharing and database Reformatting Updated document for CentOS Updated document for CentOS Updated document to new format and added clarifications Published the first version of the document Page 3

4 TABLE OF CONTENTS 1 Introduction Overview Pre-requisites 7 3 Network Configuration DNS Configuration Ubuntu LTS RHEL / CentOS 7.x Checking DNS Hosts File Configuration Configuring the Heartbeat Interface Ubuntu LTS RHEL / CentOS 7.x MySQL installation and configuration Installation and Configuration Cluster node configuration Installing OVD Components Configuring sessions sharing Inotify Installation and Configuration SSH Key Management SSH Key Configuration Verifying the SSH Configuration Inotify Script Installation and Configuration OVD Administration Console Heartbeat/Pacemaker Configuration Package Installation Heartbeat Configuration Configuration files Copy the Heartbeat Configuration Files Pacemaker configuration Apache server status Starting PCS command Corosync configuration Adding resources to monitor Heartbeat/Pacemaker Startup Script Installing the Initialization Script for Heartbeat Installing the Initialization Script for Pacemaker Modifying the osm-failover.sh Script Start the Heartbeat/Pacemaker daemon Heartbeat Pacemaker MySQL External Cluster Integration 26 8 Bibliography 27 Page 4

5 1 INTRODUCTION The purpose of this document is to provide a description of an example failover mechanism that can be deployed for the Inuvika OVD Session Manager role (OSM) and for the additional roles that may be hosted on the OSM servers. The mechanism is based on a master/slave architecture. The example is based on using the Linux Heartbeat daemon and synchronizing the data used in the OVD Session Manager between the master and the slave nodes. Other mechanisms may be employed to achieve a similar result. 1.1 OVERVIEW The example described in this document is based on a simple OVD architecture to explain each step of the failover implementation. The architecture is depicted in the following figure: Figure 1: OVD Architecture The OSM1 server serves all OVD farm requests and tasks from its network interface eth0 which hosts the internal and virtual IP address. In the example architecture, these are and respectively. OSM1 is statically set as the master server in the cluster. For more convenience, the VIP can be registered in the enterprise DNS server. In the example, the VIP is registered as osm-vip.inuvika.demo. The Heartbeat daemon which runs on both OSM servers, broadcasts over a dedicated network accessed using eth1. When the Heartbeat daemon detects that OSM1 has failed, it will switch the virtual IP address to the OSM2 server. The resulting downtime will be no more than a few seconds. When the OSM1 server has been recovered and is available again, the Heartbeat daemon will switch the virtual IP address back to OSM1. Page 5

6 Although not covered in this document, it is possible to use an external MySQL clustered solution instead (See section 7 MySQL External Cluster Integration). The instructions in this document cover Ubuntu LTS (Xenial Xerus), Ubuntu LTS (Trusty Tahr), RHEL 7, and CentOS 7. For other Linux distributions, there may be differences in the actual details of the implementation. However, the architectural approach will remain the same. Page 6

7 2 PRE-REQUISITES In order to implement a failover mechanism, the following pre-requisites should be in place. An Inuvika OVD Enterprise subscription key valid for both session managers in the setup. Please contact your local Inuvika Reseller Partner in order to initiate a replacement key request for both session managers. If you are not currently working with an Inuvika Reseller Partner, please contact your Inuvika representative directly, or submit the request form on getakey. Good Linux administration skills. The solution is not trivial to implement and is best handled by an experienced administrator. Two Linux servers with only the default server installation (plus SSH server). 2 network interfaces on each server: eth0 attached to the enterprise network with a static IP address eth1 on a dedicated Heartbeat network between both the OSM servers NOTE: In Ubuntu 16.04, eth interface names have been deprecated. Please note the naming format your system is using and substitute it in for any references to eth throughout this document. You can use the ifconfig command to find your interface names. They will most likely begin with the en prefix. A network time server to synchronize all servers with it. This is mandatory for the solution to work successfully. A DNS server to register servers and VIP DNS names as FQDNs (fully qualified name) A Directory server (optional) The installation of the required OSM and MySQL components will be described in this document. The Linux servers need have only a default installation to meet the pre-requisites. Resources required in the document are available in failover_scripts.zip Page 7

8 3 NETWORK CONFIGURATION This section describes the network configuration that 3.1 DNS CONFIGURATION If a DNS server is not available, the HOSTS file must be properly set up for all hosts that participate in the OVD server farm UBUNTU LTS In the example, the network configuration as defined in the /etc/network/interfaces file for each OSM is displayed below: OSM1: i f a c e eth0 inet s t a t i c address netmask gateway dns nameservers dns search inuvika.demo OSM2: i f a c e eth0 inet s t a t i c address netmask gateway dns nameservers dns search inuvika.demo RHEL / CENTOS 7.X In the /etc/resolv.conf file, add for each OSM OSM1: search inuvika.demo nameserver OSM2: search inuvika.demo nameserver Page 8

9 3.2 CHECKING DNS Check that the DNS server is resolved correctly by using the nslookup command. Similar testing should be conducted on each OSM machine. For example the command below entered on OSM1 : nslookup should result in the following: Server : Address : # in addr. arpa name = dc. inuvika.demo. 3.3 HOSTS FILE CONFIGURATION The HOSTS file must be set up correctly on each OSM server, even when a DNS server is available. Edit the /etc/hosts file on OSM1 and OSM2 nano / etc / hosts The contents of the file based on this example should be as follows: OSM1: localhost osm osm1. inuvika.demo osm osm2. inuvika.demo osm osm vip. inuvika.demo osm vip OSM2: localhost osm osm2. inuvika.demo osm osm1. inuvika.demo osm osm vip. inuvika.demo osm vip 3.4 CONFIGURING THE HEARTBEAT INTERFACE UBUNTU LTS To configure the network settings to support the dedicated Heartbeat network, add the settings for eth1 to the /etc/network/interfaces file on each OSM. OSM1: Page 9

10 auto eth1 i f a c e eth1 inet s t a t i c address netmask OSM2: auto eth1 i f a c e eth1 inet s t a t i c address netmask Then restart the system in each case to apply the changes. reboot Upon reboot, running the ifconfig command displays eth0 and eth1. Check that the details are correct before continuing RHEL / CENTOS 7.X To configure the network settings to support the dedicated Heartbeat network, add the settings to the /etc/sysconfig/network scripts/ifcfg eth1 file on each OSM. OSM1: DEVICE=eth1 BOOTPROTO=manual ONBOOT=yes IPADDR= NETWORK= NETMASK= OSM2: DEVICE=eth1 BOOTPROTO=manual ONBOOT=yes IPADDR= NETWORK= NETMASK= Then restart the system in each case to apply the changes. reboot Upon reboot, running the ifconfig command displays eth0 and eth1. Check that the details are correct before continuing. Page 10

11 4 MYSQL INSTALLATION AND CONFIGURATION This section covers the MySQL installation on a dedicated server. If you prefer to use an external MySQL clustered solution, refer to Section 7: MySQL External Cluster Integration and then move on to section 5. The MySQL installation is based on the official Inuvika OVD installation instructions. 4.1 INSTALLATION AND CONFIGURATION 1. Install MySQL Ubuntu LTS apt get update apt get i n s t a l l mysql server mysql c l i e n t RHEL / CentOS 7.X yum i n s t a l l mariadb mariadb server chkconfig mariadb on service mariadb s t a r t mysqladmin u root password ' mysql_root_password ' 2. Create the OVD Database with the name ovd mysql u root p e ' create database ovd ' 3. Disable the firewall or add a rule to authorize the communication on the tcp port Open a MySQL session as root : mysql u root p 5. Add the OSM servers to be able to connect remotly on the MySQL server mysql> GRANT ALL PRIVILEGES ON *. * TO ' root '@' osm1 ' IDENTIFIED BY ' root ' ; mysql> GRANT ALL PRIVILEGES ON *. * TO ' root '@' osm2 ' IDENTIFIED BY ' root ' ; mysql> GRANT ALL PRIVILEGES ON *. * TO ' root '@' osm vip ' IDENTIFIED BY ' root \ ' ; mysql> FLUSH PRIVILEGES ; 6. Restart the MySQL service for the changes to become active. Ubuntu LTS service mysql r e s t a r t RHEL / CentOS 7.X systemctl r e s t a r t mariadb Page 11

12 5 CLUSTER NODE CONFIGURATION The next step is to install the OVD components and establish the notification mechanism which is based on INotify. 5.1 INSTALLING OVD COMPONENTS The OVD Session Manager (OSM), OVD Administration Console (OAC) and OVD Web Access (OWA) should be installed on OSM1 and OSM2. For instructions on installing these components, please follow the latest OVD installation instructions available in the Installation and Configuration document at Warning The same Session Manager administration account and password must be created on both OSM1 and OSM CONFIGURING SESSIONS SHARING Using multiple OSM servers require to share sessions information between servers in order to prevent disconnections. An additional module must be installed on each OSM server which will be in charge of sharing those sessions informations. Ubuntu LTS Install the modules apt get i n s t a l l php memcache memcached Edit the configuration file nano / etc /memcached. conf Change the line by replacing with the OSM ip. l Restart the service service memcached r e s t a r t Edit the Apache configuration file nano / etc /php / 7. 0 / apache2 /php. i n i And add the following session. save_handler = memcache session. save_path = ' tcp :// :11211, tcp\ :// :11211 ' Page 12

13 Edit the memcache mode configuration file nano / etc /php5/mods a v a i l a b l e /memcache. i n i Add at the end of the file memcache. a l l o w _ f a i l o v e r =1 memcache. session_redundancy=4 Restart Apache service apache2 reload Centos / RHEL 7 Install the modules yum i n s t a l l php pecl memcache memcached Edit the configuration file v i / etc / sysconfig /memcached Change OPTIONS value with the OSM ip. OPTIONS="X. X. X. X" Change CACHESIZE by CACHESIZE="1GB" Restart the service service memcached r e s t a r t Edit the Apache configuration file v i / etc / httpd / conf. d/php. conf And add the following php_value session. save_handle "memcache" php_value session. save_handler " tcp :// :11211, tcp\ :// :11211" Edit the memcache mode configuration file v i / etc /php. d/memcache. i n i Add at the end of the file memcache. a l l o w _ f a i l o v e r =1 memcache. session_redundancy=4 Page 13

14 Restart Apache service httpd reload 5.3 INOTIFY INSTALLATION AND CONFIGURATION The next step is to install the INotify software package on OSM1 and OMS2: Ubuntu LTS apt get i n s t a l l l i b l i n u x i n o t i f y 2 perl RHEL / CentOS 7.x yum i n s t a l l http : / / download. fedoraproject. org /pub/ epel / epel release l a t e s t \ 7.noarch. rpm yum i n s t a l l perl Linux I n o t i f y SSH KEY MANAGEMENT The SSH Key Management must be setup to allow communication between the two nodes using rsync without the system requesting SSH key validation SSH KEY CONFIGURATION OSM1 server 1. Generate an RSA key pair on OSM1: ssh keygen t rsa Press enter to accept all defaults. 2. Create a.ssh folder on OSM2 remotely: ssh root@ mkdir p. ssh 3. Transfer the OSM1 SSH public key to OSM2: cat / root /. ssh / id_rsa. pub ssh root@ ' cat > >.ssh / authorized_keys ' OSM2 server 1. Generate an RSA key pair on OSM2: ssh keygen t rsa Press enter to accept all defaults. Page 14

15 2. Create a.ssh folder on OSM1 remotely: ssh mkdir p. ssh 3. Transfer the OSM2 SSH public key to OSM1: cat / root /. ssh / id_rsa. pub ssh root@ ' cat > >.ssh / authorized_keys ' VERIFYING THE SSH CONFIGURATION Using SSH should not prompt the user to accept a key request if the configuration has been performed successfully. To verify that this is the case, on OSM1 run the following command: ssh root@ No password should be requested. If ok, enter exit to quit. Then on OSM2, run the following command: ssh root@ No password should be requested. If ok, enter exit to quit. If the test passes on both nodes, then the SSH key management is correctly configured. Warning rsync uses the hostname stored within the generated key which in this case is X 5.5 INOTIFY SCRIPT INSTALLATION AND CONFIGURATION The Perl script named osm inotify.pl that is provided with this documentation must be copied into the /sbin directory on both OSM servers. The script will be started by the Heartbeat daemon and will detect if an OSM server has failed. 1. Once the file has been copied, make the file executable as follows: chmod +x / sbin /osm i n o t i f y. pl 2. Edit the script content so that it corresponds to the OSM configuration. On the OSM1 server use the OSM2 Heartbeat IP address: # REMOTE SERVER I P $rip = " " ; On the OSM2 server use the OSM1 Heartbeat address: # REMOTE SERVER I P $rip = " " ; Page 15

16 Warning Do not copy/paste the script content into the Linux server. It is recommended that a dedicated tool, such as WinSCP, is used on Windows to avoid corrupting the file. 5.6 OVD ADMINISTRATION CONSOLE The next step is to edit the MySQL settings on OSM1 and OSM2 in the OVD Administration Console. 1. Connect to the Administration Console on OSM1 using a browser and enter the URL ovd/admin/ 2. Enter the MySQL username and password in the SQL Configuration page. The page should be displayed by default upon first login since the OVD database has not been configured at this stage. Change the Database host address with the one used for the dedicated MySQL server/cluster. 3. Perform the same operation on OSM2. Figure 2: Admin Console DB configuration 4. Both OSM servers must use the same SSL certificate for the failover to be successful. To achieve this, copy the SSL certificate from OSM1 to OSM2. Ubuntu LTS scp / etc / s s l / certs / ssl cert snakeoil.pem : / etc / s s l / certs / scp / etc / s s l / private / ssl cert snakeoil. key : / etc / s s l / private RHEL / CentOS 7.X scp / etc / pki / t l s / certs / localhost. c r t * : / etc / pki / t l s / certs / scp / etc / pki / t l s / private / localhost. key * : / etc / pki / t l s / private\ / The OVD configuration of the cluster is now complete. Page 16

17 6 HEARTBEAT/PACEMAKER CONFIGURATION The remaining step is to install and configure a cluster infrastructure (communication and membership) service. This allows clients to know about the presence and disappearance of peer processes (in the case of OVD the OVD Session Manager) on other machines. Several options are available for Linux distributions but this document only covers one option per system: Hearbeat for Ubuntu Trusty and Pacemaker / Corosync for EL7 (Red Hat 7.x, CentOS 7.x). Please follow section 6.1 and afterwards choose either 6.2 (heartbeat) or 6.2 (pacemaker) depending on your distribution. 6.1 PACKAGE INSTALLATION The Heartbeat package must be installed on OSM1 and OSM2: Ubuntu LTS apt get update apt get i n s t a l l heartbeat RHEL / CentOS 7.X yum y i n s t a l l corosync pacemaker pcs 6.2 HEARTBEAT CONFIGURATION This section covers Ubuntu LTS (Xenial Xerus) and Ubuntu LTS (Trusty Tahr). Warning This section is not for RHEL 7.x and CentOS 7.x. Please follow [ Pacemaker configuration ] ( # pacemaker configuration ) for RHEL 7. x and CentOS 7. x. There are 3 files to configure for the Heartbeat package. These files will be created in the /etc/heartbeat directory. This directory is a symlink to /etc/ha.d CONFIGURATION FILES The files are created on OSM1 ONLY (the master node) and are: authkeys haresources ha.cf Page 17

18 Configuration File 1. Edit the Heartbeat configuration file: nano / etc / heartbeat / ha. c f 2. Add the following content: autojoin none l o g f i l e / var / log / heartbeat. log l o g f a c i l i t y daemon node osm1 osm2 keepalive 2 warntime 5 deadtime 15 bcast eth1 ping auto_failback yes node osm1 osm2: the order is important as it is used to set the master node. In this case OSM1 will always be the master server ping : the address of a ping gateway. This test pings the network gateway to check network availability. In this example the network gateway is bcast eth1: the Heartbeat daemon will broadcast through the dedicated interface which in this example is eth1 auto_failback yes: When the master node (OSM1 in this example) has been recovered after a failure, the Heartbeat daemon will revert the virtual IP address back to the master authkeys Configuration File The authkeys file contains pre-shared secrets used for mutual cluster node authentication. It should only be readable by root and follows this format: auth num num algorithm secret num is a simple index, starting at 1. Usually, there will only be one key in the authkeys file. algorithm is the name of signature algorithm used. The options are either md5 or sha1. It is recommended to not use a crc (a simple cyclic redundancy check) which is not secure. secret is the actual authentication key. The authkeys file can be created using a randomly generated secret. The following commands will achieve this task: 1. Generate SHA1 key: dd i f =/dev /urandom bs=512 count=1 2>/dev / n u l l openssl md5 The output should be similar to: Page 18

19 ( stdin ) = 1ff0cde062fc435a4b2f039c71e Create the authkeys file by editing the file: nano / etc / heartbeat / authkeys and paste in the output from the SHA1 key generation: auth 1 1 sha1 1ff0cde062fc435a4b2f039c71e Configure the access permissions for root only: chmod 0600 / etc / ha. d/ authkeys Or, combining all the above, the commands can be concatenated as follows: echo e " auth 1\n1 sha1 $ ( dd i f =/dev /urandom bs=512 count=1 2> / dev / n u l l \ openssl md5 ) " > / etc / ha. d/ authkeys && chmod 600 / etc / ha. d/ authkeys haresources Configuration File Once the ha.cf and authkeys files are set up, the next step is to configure the haresources file. This file specifies the services for the cluster and who the default owner is. The haresources file is read when the server state changes from passive to active mode. In the example, we want the server node to handle the virtual IP address when it is active. 1. Create the haresources file by editing the file nano / etc / heartbeat / haresources 2. Enter the content below and save the file. The configuration of this file will be completed later. osm cron osm f a i l o v e r. sh where: OSM1: the cluster master node name : the virtual IP address cron/crond: this service is started only when the server becomes active osm-failover.sh: the script that runs when the server becomes active COPY THE HEARTBEAT CONFIGURATION FILES The configuration on OSM2 must be the same as OSM1, so the files created on OSM1 can be copied to OSM2 as follows: cd / etc / heartbeat scp authkeys ha. c f haresources : / etc / heartbeat / Page 19

20 6.3 PACEMAKER CONFIGURATION This section covers only Red Hat 7.x/CentOS 7.x. Warning This section is not for Ubuntu LTS. Please follow [ Heartbeat Configuration ] ( # heartbeat configuration ) for Ubuntu LTS. As Heartbeat is deprecated, the configuration steps for Pacemaker are not the same. All the following commands must be run as the root user APACHE SERVER STATUS This location needs to be defined for monitoring the apache service. Create the /etc/httpd/conf.d/status.conf nano / etc / httpd / conf. d/ status. conf Add the following content: <Location / server status > SetHandler server status Order Deny, Allow Deny from a l l Allow from </ Location > Stop Apache and the running service: chkconfig httpd o f f systemctl stop httpd. service STARTING PCS COMMAND The pcs command line interface controls and configures Corosync and Pacemaker. Start the pcs command on the OSM01 and OSM02 servers systemctl enable pcsd. service systemctl s t a r t pcsd. service COROSYNC CONFIGURATION The default installation has created a user account named hacluster. The password must be defined Page 20

21 passwd hacluster Authorize the OSM servers o the cluster pcs c l u s t e r auth osm01 osm02 Create the cluster and the OSM servers as nodes pcs c l u s t e r setup name osmha osm01 osm02 osmha: name of the cluster Pacemaker and Corosync services must be started systemctl systemctl enable corosync. service enable pacemaker. service Disable some settings not useful in this case pcs f configuration property set stonith enabled= f a l s e pcs f configuration property set no quorum p o l i c y =ignore ADDING RESOURCES TO MONITOR The VIP, Apache, and a sync script must be added as resources to monitor Add the VIP as a resource in the cluster: pcs f configuration resource create v i r t u a l _ i p ocf : heartbeat : IPaddr2 ip\ = cidr_netmask=24 op monitor i n t e r v a l =20s Add the Apache service as a resource in the cluster pcs f configuration resource create WebServer ocf : heartbeat : apache c o n f i g f i l e \ =/ etc / httpd / conf / httpd. conf s t a t u s u r l =" http : / / / server status " op \ monitor i n t e r v a l =20s Now, a constraint must be defined between these two resources to be sure that the same node will be assigned to these resources. pcs f configuration constraint colocation add WebServer v i r t u a l _ i p INFINITY 6.4 HEARTBEAT/PACEMAKER STARTUP SCRIPT INSTALLING THE INITIALIZATION SCRIPT FOR HEARTBEAT The Heartbeat startup script will be started by the Heartbeat daemon on the active OSM server only. Copy the provided osm-failover.sh file to the directory /etc/init.d on both nodes. Page 21

22 These steps cover only Ubuntu LTS. Please follow Installing the Initialization Script for Pacemaker for Red Hat 7.x/CentOS 7.x. On OSM1 and OSM2: chmod 755 / etc / i n i t. d/osm f a i l o v e r. sh Then update the startup conditions as follows: 1. Ubuntu and update rc. d osm f a i l o v e r. sh defaults update rc. d osm f a i l o v e r. sh disable INSTALLING THE INITIALIZATION SCRIPT FOR PACEMAKER These steps cover only RHEL 7.x / CentOS 7.x. Please follow Installing the Initialization Script for Heartbeat for Ubuntu LTS. The startup script will be started by Pacemaker on the active OSM only Copy the provided osm-failover.sh file to /usr/sbin on both nodes. Create a system service by creating the file. nano / etc / systemd / system /osm f a i l o v e r. service Add the following content: [ Unit ] Description=OSM F a i l o v e r [ Service ] Type= forking ExecStart =/ usr / sbin /osm f a i l o v e r. sh s t a r t ExecStop =/ usr / sbin /osm f a i l o v e r. sh stop [ I n s t a l l ] WantedBy=multi user. target Start the osm-failover service and enable it at startup systemctl systemctl s t a r t osm f a i l o v e r. service enable osm f a i l o v e r. service Add the script as a resource in the cluster and add a constraint: sudo pcs f configuration resource create OSM systemd : osm f a i l o v e r op \ monitor i n t e r v a l =20s force sudo pcs f configuration constraint colocation add v i r t u a l _ i p OSM \ INFINITY Page 22

23 6.4.3 MODIFYING THE OSM-FAILOVER.SH SCRIPT The osm-failover.sh script must be modified to incorporate the settings of the installed environment. IP source address rewrite The OSM communicates on TCP port 1112 with the OAS and OFS servers. By default it uses the network interface that is started first. In our example it must be the VIP, which is eth0:0 instead of eth0. The required behavior can be enforced by using an Iptables rule. The rule to use is: i p t a b l e s t nat I POSTROUTING d dest. Network j SNAT to V i r t u a l IP When the Heartbeat daemon starts, it will execute the osm-failover.sh script which in turn implements the iptables rule and removes it when the daemon stops. On OSM1 and OSM2: 1. Edit the /etc/init.d/osm-failover.sh file or /usr/sbin/osm-failover.sh file. 2. In the d_start() section, add/modify the line as below: d_start ( ) { log_daemon_msg " S t a r t i n g system $DEAMON_NAME Daemon" start stop daemon background name $DEAMON_NAME s t a r t quiet \ chuid $DAEMONUSER exec $DAEMON $DEAMON_OPT log_end_msg $? i p t a b l e s t nat I POSTROUTING d /24 j SNAT to \ } All packets routed to the network /24 are rewritten with the source IP (the cluster VIP) 3. In the d_stop() section, add/modify the line shown below: _stop ( ) { log_daemon_msg " Stopping system $DEAMON_NAME Daemon" start stop daemon name $DEAMON_NAME stop r e t r y 5 quiet name \ $DEAMON_NAME log_end_msg $? i p t a b l e s t nat F } When the Heartbeat daemon is stopped, the Iptables rule will be removed. 4. When the Heartbeat daemon is running, check the IP tables rule is properly set: i p t a b l e s nl v line numbers t nat 6.5 START THE HEARTBEAT/PACEMAKER DAEMON HEARTBEAT These steps cover only Ubuntu LTS. Please follow Pacemaker for Red Hat 7.x/CentOS 7.x. Page 23

24 On OSM1 and OSM2: service heartbeat s t a r t The log file may help with troubleshooting any Heartbeat issues: / var / log / heartbeat. log The server hosting the virtual IP address, which in normal operation mode is OSM1, should list the VIP address: root@osm1:~# i f c o n f i g eth0 Link encap : Ethernet HWaddr 08:00:27:4 a : b3 : c7 inet addr : Bcast : Mask: inet6 addr : fe80 : : a00:27 f f : fe4a : b3c7/64 Scope : Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric : 1 RX packets :92348 errors : 0 dropped: 81 overruns : 0 frame : 0 TX packets :10856 errors :0 dropped :0 overruns :0 c a r r i e r :0 c o l l i s i o n s :0 txqueuelen :1000 RX bytes : ( MB) TX bytes : ( 2. 9 MB) eth0 :0 Link encap : Ethernet HWaddr 08:00:27:4 a : b3 : c7 inet addr : Bcast : Mask: UP BROADCAST RUNNING MULTICAST MTU:1500 Metric : PACEMAKER These steps cover only Red Hat 7.x/CentOS 7.x. Please follow Heartbeat for Ubuntu LTS. Start the cluster: sudo pcs c l u s t e r s t a r t a l l Then push the configuration to the active cluster sudo pcs c l u s t e r cib push configuration You can verify the status of your cluster by using the following command sudo pcs status The result should look like this: Cluster name: osmha Last updated : Tue Nov 22 18: 02: Last change : Tue Nov 22 17: 57: \ by root v i a cibadmin on osm01 Stack : corosync Current DC: osm02 ( version el7_2.4 44eb2dd ) p a r t i t i o n WITHOUT \ quorum 2 nodes and 3 resources configured Online : [ osm02 ] Page 24

25 OFFLINE : [ osm01 ] F u l l l i s t of resources : v i r t u a l _ i p ( ocf : : heartbeat : IPaddr2 ) : Started osm02 WebServer ( ocf : : heartbeat : apache ) : Started osm02 OSM ( systemd : osmfailover ) : Started osm02 PCSD Status : osm01 : Online osm02 : Online Daemon Status : corosync : a c t i v e / enabled pacemaker : a c t i v e / enabled pcsd : a c t i v e / enabled Page 25

26 7 MYSQL EXTERNAL CLUSTER INTEGRATION This section explains how to integrate an OSM server farm with an enterprise MySQL clustered solution (third party solution). It is possible though to use a free/open source MySQL cluster by implementing the solution from this excellent guide: MySQL HA (High Availability) Cluster Cookbook. Page 26

27 8 BIBLIOGRAPHY Linux HA. (2015, 09 09). Retrieved from Linux HA: Linux HA. (2015, 09 09). Retrieved from Linux HA: Page 27