Lifekeeper™ for Linux Installation and Administration

LifeKeeper® for Linux Module 3: Configuration Learning Objectives

At the end of this module, you will understand:

. LifeKeeper GUI server and client concepts . LifeKeeper GUI client application and applet . LifeKeeper GUI permissions . LifeKeeper Communication Paths . Miscellaneous LifeKeeper server configuration options

LifeKeeper GUI Overview

. GUI Server Component • Must be running on each server in the cluster • Communicates with the LifeKeeper core via JNI (Java Native Interface) • Communicates with the client via RMI (Remote Method Invocation) . GUI Client Component runs… • As an application on a Linux system • As an applet invoked from a web browser (*Linux, Windows, Unix)

LifeKeeper GUI . QuickStart Configuration Assistant . Menu Bar . Tool Bar . Status Window . Message Display . Popup Menus via right click

LifeKeeper GUI Package (steeleye-lkGUI-..rpm) . Installs LifeKeeper GUI client in Java archive format . Installs LifeKeeper GUI Server . Installs LifeKeeper administration web server for use with web browsers (Java applet) . Installs a .java.policy file in /opt/LifeKeeper/htdoc containing minimum permissions to run LifeKeeper . Prepares LifeKeeper for GUI administration . To verify LifeKeeper GUI package installation rpm –qa | grep steel

LifeKeeper GUI Server:

. Install the Java Components • Must have the Java Runtime Environment on each server in the cluster. (JRE is included on Installation Support CD). • By default, LifeKeeper expects Java to be installed in /usr/java/jre/bin . Start the GUI Server process on all servers • To start the GUI server process on each server the first time: /opt/LifeKeeper/bin/lkGUIserver start • Entries for the two GUI server daemons are are automatically added to /etc/inittab. • Web server and the Java RMI server port entries are automatically added to /etc/default/LifeKeeper.

Configure GUI administrative users . a GUI user login is required to administer LifeKeeper from the GUI . root is automatically added during the installation as a GUI user. Password is the same as the Linux root user. . GUI users should have the same password on all servers – eliminates requirement for user to enter multiple passwords during login /opt/LifeKeeper/bin/lkpasswd /opt/LifeKeeper/bin/lkpasswd -d

Running GUI as a Java application:

. GUI client and GUI server running on same system . To invoke: • /opt/LifeKeeper/bin/lkGUIapp . lkGUIapp script sets appropriate environment variables and starts application . LifeKeeper GUI appears, Cluster Connect dialog displayed Running GUI as a Java applet: . GUI client running on same or different system as GUI server . Requires web browser and Java Runtime Environment • Java 1.5 is fully tested and supported . Default URL is http://:81 . Java security requires that server and client must be able to resolve each other’s host names and IP addresses.

Running GUI as a Java Applet (continued):

. On Linux a symlink must be created in the browser’s plugin directory to the Java plugin library. ln –s /usr/java/jre1.5.0_07/plugins/i386/ns7/libjavaplugin_oji.so \ /usr/lib/firefox/plugins/libjavaplugin_oji.so . Pre-Java 1.4 environments only: • Requires .java.policy file, so client can gain remote access to LifeKeeper servers and load Recovery Kit GUI extensions • Copy from /opt/LifeKeeper/htdoc/java.policy or http://:81/java.policy • Set browser security parameters to low • See documentation for more information

Running the GUI Client: Open the URL: http://:81

Example: http://node1:81

. IP addresses of browser client system and all servers must be resolvable (Java security) . Java Virtual Machine started . applet files downloaded . applet initialized . Login dialog box should appear

LifeKeeper GUI Client:

. Applet vs. Application • Applet allows client independence -- can run from Internet Explorer or Firefox on a Windows, Unix, or Linux client. • Applet does not require installation of any LifeKeeper packages on the client. • Applet supports security roles. • Application depends on the installation of the steeleye-lk and steeleye- lkGUI packages (requires a core product license). • Application can only be run on a Linux system. • Application has full control. • It is convenient to run the GUI as an application on an LifeKeeper server since the steeleye-lk and steeleye-lkGUI packages are already installed.

. Guest Permission . Operator Task Guest Operator Administrato r . Administrator Connect to and disconnect from servers X X X

View servers and resources X X X

View server properties and logs X X X

View resource properties X X X

Put resources into and out of service X X

Modify server properties X

Create and delete comm paths X

Create and delete resource hierarchies X

Extend and unextend resource hierarchies X

Create and delete resource dependencies X

Modify resource properties X

. The GUI server must be invoked as root • During installation of the GUI package, an entry for the root login and password is automatically configured in the GUI password file with Administrator permission, allowing root to perform all LifeKeeper tasks on that server via the GUI application or web client. • If you plan to allow users other than root to use LifeKeeper GUI clients, then you need to configure LifeKeeper GUI users. . Best practice is to always grant permissions on a cluster-wide basis • Grant permissions on a single-server basis is possible, but: – Confusing to users – Makes it impossible to perform administrative tasks

. User administration performed through command line interface: lkpasswd . Most commands require entering the user's password twice (validation)

. Effective on next login or when GUI server is restarted . Single permission per user per server . New permissions override old ones . Commands update GUI password file on the server being administered. Repeat on all servers in the cluster.

. Grant Administrator permissions: /opt/LifeKeeper/bin/lkpasswd -administrator . Grant Operator permissions: /opt/LifeKeeper/bin/lkpasswd -operator . Grant Guest permissions: /opt/LifeKeeper/bin/lkpasswd -guest . Change password (no change to access): /opt/LifeKeeper/bin/lkpasswd . Remove access: /opt/LifeKeeper/bin/lkpasswd -delete • (no password required)

. Two comm paths are strongly suggested . Comm Path Functions: • Inter-node communication for obtaining status information • Heartbeat signal for verifying the systems are alive . Comm Path Types: • TCP utilizing a LAN connection (multiple TCPs allowed) • TTY utilizing a serial port connection (only 1 TTY allowed) . Comm Path Priorities • TCP - priority from 1-99 (1 is the highest) • TTY - always defaults to the lowest priority (no configurable priority)

Setup:

. Ethernet cards on the systems . IP addresses for each system . Two networks are suggested - one private LAN for LifeKeeper communication and one public LAN for user traffic. The user traffic LAN can be configured as a secondary comm path. . Different comm paths cannot be on the same sub-net. . Verify the network is functional before starting the comm path configuration. Network addresses must be resolvable, through /etc/hosts file and DNS.

Configuration: . Select . Fields to Enter:

• Local System Name • Remote System Name(s) • Type: Select TCP • Local IP Address • Remote IP address(es) • Priority . Select “Create Local” . Select “Create Remote”

Setup: . Requires a null modem cable . Note: Only one TTY comm path is allowed between systems . Test the serial path using the portio command $LKROOT/bin/portio -r -p port -b baud port is the serial port, e.g. /dev/ttyS0 baud is the baud rate – 38400 is recommended Configuration (via GUI) . Local System Name . Remote Server Name(s) . Type: TTY . Serial Port for Local System . Serial Port for Remote System

Comm Paths may be monitored via the GUI:

Select Edit >Server > Properties > CommPaths

. Configurations containing a single Comm Path are subject to split brain. . If a File System resource is on shared storage (SCSI or Fibre Channel), loss of all communications paths will cause recovery by the

standby server forcing the active server to reboot. • SCSI reservations used for disk I/O fencing

. If a File System resource is on NAS, a comm path must be created on the NIC used for NAS interface. Consider using STONITH device to prevent split brain. . If a File System resource is on replicated storage, use a STONITH

device and/or set “Confirm Failover From” node property (manual failover) to avoid split brain.

. Setting Server Shutdown Strategy • Tells LifeKeeper what to do in the case of an orderly shutdown of a server. – Switchover Resources: LifeKeeper will switchover all resource hierarchies during an orderly shutdown. – Do Not Switchover Resources: LifeKeeper will not switchover resource hierarchies during an orderly shutdown. (default) . Increasing the Log File Size • When LifeKeeper starts, it allocates the maximum space required for its log files. The size, or the space allocated for the LifeKeeper log files, is a tunable parameter located in /etc/default/LifeKeeper.

. Configuring the Manual Failover Confirmation Option • Option to require manual confirmation by a system administrator before allowing LifeKeeper to perform a failover. • Used to prevent LifeKeeper from performing failovers in situations where LifeKeeper detects that a remote system has crashed when it actually has not. • Use in WAN configurations or those without redundant heartbeat communications paths. • This topic will be covered in greater depth in Module 6

. Configuring the Block Resource Failover Option • Setting this option tells LifeKeeper to not allow failovers to occur to a specific server if local recovery fails (from the server where the option is set) • This setting will not block a failover if the system completely fails • This setting should be used in situations where automatic resource failover (due to local failure) is not desired

. Adding the LifeKeeper GUI Icon to the Desktop Toolbar • The LifeKeeper GUI icon is automatically added to the desktop menu under the System sub-menu during installation of the LifeKeeper GUI package.

. Tuning the LifeKeeper Heartbeat - /etc/default/LifeKeeper • Signal sent between LifeKeeper servers to ensure each server is “alive”. • Interval: the number of seconds between heartbeats (default 5; LCMHBEATTIME) • Number of Heartbeats: the number of heartbeats that can be missed before LifeKeeper triggers a failover (default 3; LCMNUMHBEATS)

. Forwarding LifeKeeper Events via SNMP traps • Simple Network Management Protocol (SNMP) defines a device- independent framework for managing networks. • Devices on the network are described by MIB (Management Information Base) variables. – LifeKeeper MIB file is /opt/LifeKeeper/include/LifeKeeper-MIB.txt – Compile into Management Console to support trap messages • Certain LifeKeeper events asynchronously generate traps to notify the Management Console. – SNMP trap generation scripts are under /opt/LifeKeeper/events/lifekeeper directories (LKsnmptrap). • To enable trap forwarding run: /opt/LifeKeeper/bin/lk_configsnmp • See /opt/LifeKeeper/man/man8/lk_configsnmp.8 for more information.

. Sending LifeKeeper Event Notification via SMTP • Simple Mail Transfer Protocol (SMTP) defines a framework for sending messages across networks. • An SMTP Mail Transfer Agent agent (MTA) runs somewhere on the network. The node running this agent is typically registered in DNS via the MX record type. Other routing mechanisms are available (smarthost or mail forwarder configuration options in sendmail.cf). • Certain LifeKeeper events can asynchronously generate e-mail messages. – E-mail notification scripts are under /opt/LifeKeeper/events/lifekeeper directories (LKnotifyalias). • To enable e-mail notification run: /opt/LifeKeeper/bin/lk_confignotifyalias • See /opt/LifeKeeper/man/man8/lk_confignotifyalias.8 for more information.