This chapter provides procedures for specific concepts. The steps can get into advanced features. Follow the cross-references to previous chapters for more details.
This chapter covers the following topics:
A cluster is a group of machines or other resources that act as one powerful system. Clustering provides high availability, continuous operations for a long time. There are many varieties of clusters.
This scenario uses openMosix, a Linux kernel extension for clustering. The openMosix cluster is a single-image cluster: multiple copies of a single operating system kernel.
openMosix joins Linux machines to function as one large multiple-processor computer. If you have a 12-node cluster, it is as though you had one computer with the CPU power of 12 computers. One process will not be 12-times faster, but you can run 12 processes simultaneously.
The openMosix package is not available from any one distribution. You can download it from the project site.
Notice that after the profile is set up, cluster creation is automated. You could create an opposite profile that would undo the actions of this scenario, thereby unclustering the machines. You could set both profiles to run on a schedule, which would cluster and uncluster your resources according to your needs.
This procedure to create a cluster with nodes takes about two hours to complete. It might take less time if there are no unexpected problems or a little more time for different environments. Maintenance tasks on the cluster (for example, adding or changing a node) take about five to ten minutes.
Choose the machines that will be nodes of the cluster.
Each machine should have a Linux distribution that is supported by Sun Update Connection – Enterprise and the kernel version supported by openMosix.
Install Sun Update Connection – Enterprise (system dependency server [SDS], dependency manager [DM], the knowledge base, the console, and the agent) on one of the machines.
See the Sun Update Connection - Enterprise 1.0 Administration Guide.
Install the agent on the other machines.
Add the openMosix RPM to the local knowledge base.
The Local Expansion technology creates deployment rules.
In a text editor, create /etc/mosix.map.
This file maps a node number to each IP address.
Add a file declaration called /etc/mosix.map
Add the /etc/mosix.map file to the local knowledge base.
In a text editor, create a version of /etc/hosts which includes the hosts to be in the cluster.
Add a /etc/hosts file declaration and add the version you just made to the local knowledge base.
See Creating File Declarations and Uploading Local Configuration Files.
Write a script that changes the default boot kernel to openMosix in the grub table:
OpenMosixAsDefault.sh |
See Writing Actions.
Add this script to Local/Pre-actions.
See Uploading Actions.
Add this script to Local/Post-actions.
See Uploading Actions.
Create a profile called openMosixNode that defines the following requirements of a node in the cluster:
Required: openMosix kernel and management tools
Required: /etc/mosix.map (specifying local version)
Required: /etc/hosts (specifying local version)
Required: Pre-action OpenMosixAsDefault.sh
See To Create a Profile.
Create a group called Test, which includes two of the machines, and then Create a group called openMosixCluster, which includes all the machines that are to be nodes in the cluster.
See To Create a Group.
Create a job that runs in simulate mode on the Test group, with the following profile tasks:
openMosixNode profile
Perform Restart
Check the estimates and status of the job before continuing. See Creating Complex Jobs.
Rerun the job in deploy mode on the Test group. Check the results and status of the hosts before continuing.
See To Rerun a Job.
Run the job again in deploy mode on the openMosixCluster group.
All selected machines are now nodes of a cluster. See Creating Complex Jobs.
Install the agent on the new machine.
See the Sun Update Connection - Enterprise 1.0 Administration Guide.
Add this managed host to the openMosixCluster group.
See To Edit a Group.
Open the mosix.map knowledge base file and add a new node number and the IP of the new machine.
Open the /etc/hosts knowledge base files and add the new host name.
See Opening Host Files.
Run the job with the openMosixNode profile in deploy mode on the openMosixCluster group.
Legacy data and applications are not touched by the job, but the new map and hosts files are downloaded to each node. See Creating Complex Jobs.
Integrating Sun Update Connection – Enterprise with local environment resource monitoring tools provides Floating Servers and Loads, an implementation of the On-Demand Computing model. In general, the concept of On-Demand Computing enables enterprises to meet fluctuating resource demands efficiently, without adding hardware investments or keeping mostly-idle machines. Resources are made available as needed.
A servicing pool is a group of machines dedicated to a specific type of service: web servers, print servers, mail servers, and so on.
In this procedure, you will use Sun Update Connection – Enterprise to install the needed server profile on the floating server when the load threshold has reached overload, and to uninstall the profile when the load threshold has reached idle.
Using Sun Update Connection – Enterprise, create the profiles of your servers.
Define what is required and what is not allowed to be on each type of server. For this scenario, define a WebServerProfile profile and a TelnetServerProfile profile.
See To Create a Profile.
Create a profile that uninstalls the software of the other two profiles.
No damage is caused by setting Uninstall to components that are not there. So, make an uninstall profile called IdleServerProfile.
If there are various distributions used in the server pools and in the floating servers, align the profiles for all relevant distributions.
Create a policy that automates all actions (Yes to all actions on all Software) and call it YesToAll.
See To Create a Policy.
Create groups for each pool of servers, and a group called Idle.
For this scenario, call the server groups WebServers and TelnetServers.
See To Create a Group.
In the Idle group, assign a spare server that is your floating server and name it floating.
Write a script that takes the output of your local resource monitoring tool when the load threshold has been passed (either on overload or on idle) and runs a script similar to floatingServers.sh.
This script is called by a local script that finds the group with an overload or an idle threshold pass. Its arguments are the group with the needed resources (source) and the group that needs the resource (target).
If there is an overload on WebServers of TelnetServers, the source is Idle.
If the server groups are idle, the source is the one containing the floating server.
Write your local script to call floatingServers.sh.
./floatingServers.sh source target |
For example, the floatingServers script takes those arguments in the findProfile function, which tells which profile to use in the deployServer function. The profile either installs a web server, a telnet server, or uninstalls server software (to return floating server to idle).
# ./floatingServers.sh Idle WebServers |
#! /bin/bash host=floating policy=YesToAll function login { echo -n “Type your user name:” read user echo -n “Type your password:” read password } function deployServer { uce_cli -sj -P “$profile” -C “$policy” -h “$host” -dp -u “$user” -p “$password” } function findProfile { sourceG=$1 targetG=$2 if [ $sourceG = “Idle” -a $targetG = “WebServers” ]; then profile=”WebServerProfile” elif [ $sourceG = “Idle” -a $targetG = “TelnetServers” ]; then profile=”TelnetServerProfile” elif [ $sourceG = “WebServers” -o $sourceG = “TelnetServers” ]; then profile=”IdleServerProfile” else echo “Source is not in automated script.” echo “From the following list of known profiles, select one to deploy on floating server” uce_cli -lp -u “$user” -p “$password” echo -n “Profile to deploy:” read profile fi } login findProfile $1 $2 echo “Deploying $profile on $host to make it part of $2” deployServer |
If the servers in a pool are of one distribution, and the floating server is of another, you can use the BMI Server to recycle the floating server with a new Linux distribution while provisioning it with a profile. Consult with your Sun distributor for details.
Because Sun Update Connection – Enterprise focuses on the component level, Sun Update Connection – Enterprise cloning enables you to maintain legacy data and applications. A management tool that focuses on the image level would simply overwrite the existing image with the source image. The Sun Update Connection – Enterprise feature provides a more discerning functionality.
Through the console, you can clone a single managed host to another host in a simple procedure. The scenario included here includes steps for changing Settings (see Chapter 16, Customizing Preferences) that will ensure success of the cloning.
An additional scenario explains how to clone multiple hosts using the Sun Update Connection – Enterprise CLI.
Run the Check System profile on the host that you are using as the optimal host. This ensures that the comparison does not include conflicts or dependencies.
See Running Predefined Profiles.
Run the Check Withdrawn Patches profile on Solaris machines.
This procedure uses the Inventory Comparison feature.
Make sure that the source managed host is online and as optimal as you think.
Run the predefined system profiles on this host.
Make sure the target managed host is online.
From the Tools menu, choose Preferences.
The Preferences window opens. See Accessing and Editing Preferences.
In the Console preferences, Jobs category, increase the value of Max items in a job from 20 to 500.
Submit and confirm the change.
See Console Preferences.
From the Hosts menu, choose Compare Inventories.
The Inventory Comparison window opens. See Comparing Inventories.
Select the Target host and the Source host.
Select the current inventory for both hosts.
In the Filter field, select the full inventory (Software and Local) or use the Filter Select button to select pieces of the inventory to overwrite.
Click the Compare button and select the Tasks to Make Target like Source option.
Click the Make Target like Source button and send the clone job.
This procedure uses the CLI feature to create a profile from a complete host inventory. After you have the profile, you can delete requirements from it to lock legacy software and files from being overwritten during the clone job. Then the profile is sent to as many servers as you choose.
In a terminal window, type the CLI command to convert an inventory to a profile.
# uce_cli -cip -P new_profileName -h source_host -u user -p password |
View the attributes of the profile (what is required and what is not allowed).
# uce_cli -lpa -P profileName -u user -p password |
To protect legacy components on the target servers, delete the profile attributes that you do not want to clone over.
Export the profile to an XML file name.
# uce_cli -exp -ent "Profile" -f path-and-filename.xml -T "profile" -u user -p password |
Edit the XML file. Delete the lines that mention components you want to protect on targets.
Import the edited XML file as the profile.
# uce_cli -imp -f path-and-filename.xml -u user -p password |
In the console, create a job that deploys the profile on selected hosts.
The Linux operating system is designed to be a network server or workstation. Sharing directories and files between computers, even of differing operating systems, is a relatively simple task. Although useful, it can be a daunting task for large environments. Sun Update Connection – Enterprise provides the tools to automate sharing and mounting, at the same time ensuring that the relevant machines have the necessary software and files to perform the tasks.
This procedure shows how scripts can be used in Sun Update Connection – Enterprise jobs to make every-day administration tasks fast and easy. This scenario uses NFS to mount a Linux directory on a client Linux machine. It assumes an NFS server already exists.
Create a short script called mntnfs.sh that appends the appropriate line the /etc/fstab.
#! /bin/bash nfs=nfs_server_hostname mntPnt=mounted_directory fstab_line=”$nfs: $mntPnt $mntPnt nfs nfsvers=2,rw 0 0” echo $fstab_line >> /etc/fstab /etc/init.d/netfs start mount -a |
Upload the script as a Local -> Pre-Action -> mntnfs.
See Uploading Actions.
Create a profile that requires nfs-utils and mntnfs.
See To Create a Profile.
Make the profile applicable to all active distributions.
Run a job on selected hosts that deploys the profile.
This procedure shows how simple scripts can be used in Sun Update Connection – Enterprise jobs to make everyday administration tasks fast and easy. This scenario uses samba to mount a Microsoft Windows directory (that is previously set to Shared on Windows) from a Linux file system.
Create a short script called mntWinSamba.sh that turns on samba and runs the command to mount the directory.
#! /bin/bash user=linuxuser pass=passwd4user wincp=//win_hostname winpath=/win_directory linuxpath=/linux_mntdir fstab_line=$wincp$winpath /mnt$linuxpath smbfs username=$user,password=$pass 0 0 /etc/init.d/smb start echo $fstab_line >> /etc/fstab mount -a |
Upload the script as a Local -> Post-Action -> mntWin.
See Uploading Actions.
Create a profile that requires samba-client and mntWin.
See To Create a Profile.
Make the profile applicable to all active distributions.
Run a job on selected hosts that deploys the profile.
DB2 is a popular application. It is licensed, not Open Source, and therefore, it is not included in vendor distributions.
If you have the DB2 CD and a valid license, you can use this scenario to make installation faster and to ensure that your servers are completely managed by Sun Update Connection – Enterprise. After you have uploaded DB2 as an NCO to the local knowledge base, the Local Expansion Technology generates rules for it. These rules ensure that DB2 will work as an integral part of your environment.
This procedure uses a script that calls up the DB2 license file during automated installation.
Upload the DB2 RPMs to the local knowledge base.
The RPMs are listed under Local -> Local RPMs. See Adding Undetected Linux Software.
Create a Local File Declaration that is the path where the license file should be installed.
For example, the file might be /tmp/db2pe.lic.
Upload the license file as a Local Configuration File under the File Declaration.
Create a script that does the following:
Installs the license
Creates DB2 users and instances
Starts DB2
#!/bin/sh OUTFILE=”/tmp/db2_uce.out” # Definitions LICENSE_FILE=”/tmp/db2pe.lic” INST_DIR=”/opt/IBM/db2/V8.1” SERVICE_NAME=db2c_db2inst1 SERVICE_PORT=50000 INSTANCE_NAME=db2inst1 INSTANCE_USER=db2inst1 INSTANCE_GROUP=db2grp1 INSTANCE_HOME=”/home/$INSTANCE_USER” FENCED_USER=db2fenc1 FENCED_GROUP=db2fgrp1 FENCED_HOME=”/home/$FENCED_USER” ADMIN_USER=dasusr1 ADMIN_GROUP=dasadm1 ADMIN_HOME=”/home/$ADMIN_USER” # Install the DB2 license $INST_DIR/adm/db2licm -a $LICENSE_FILE >> $OUTFILE 2>&1 # Fenced User Creation groupadd $FENCED_GROUP useradd -g $FENCED_GROUP -m -d $FENCED_HOME $FENCED_USER chmod 755 $FENCED_HOME # Instance User Creation groupadd $INSTANCE_GROUP useradd -g $INSTANCE_GROUP -m -d $INSTANCE_HOME $INSTANCE_USER chmod 755 $INSTANCE_HOME # Admin User Creation groupadd $ADMIN_GROUP useradd -g $ADMIN_GROUP -m -d $ADMIN_HOME $ADMIN_USER chmod 755 $ADMIN_HOME # Edit entry in /etc/services?? etc_serv=\Qgrep $SERVICE_NAME /etc/services | wc -l\Q if [ $etc_serv -eq 0 ] ; then echo “$SERVICE_NAME $SERVICE_PORT/tcp #DB2” >> /etc/services fi # Create db2 instance $INST_DIR/instance/db2icrt -a SERVER -u $FENCED_USER -p $SERVICE_NAME $INSTANCE_NAME >> $OUTFILE 2>&1 # Admin instance creation $INST_DIR/instance/dascrt $ADMIN_USER >> $OUTFILE 2>&1 # Update DB manager configuration $INST_DIR/instance/db2iexec $INSTANCE_NAME “. sqllib/db2profile; db2 update dbm cfg using svcename $SERVICE_NAME; db2set -i $INSTANCE_NAME db2comm=tcpip; db2 terminate” >> $OUTFILE 2>&1 # Set DB2AUTOSTART=YES for $INSTANCE_NAME $INST_DIR/instance/db2iset DB2AUTOSTART=YES -i $INSTANCE_NAME >> $OUTFILE 2>&1 # DB2 Start $INST_DIR/instance/db2iexec $INSTANCE_NAME “. sqllib/db2profile; db2stop; db2start “ >> $OUTFILE 2>&1 # DB2 Admin Start $INST_DIR/instance/db2iexec $ADMIN_USER “. das/dasprofile; db2admin start “ >> $OUTFILE 2>&1 |
Upload the script under Local -> Post-actions -> postDB2.
See Uploading Actions.
Create a profile that requires the following:
All DB2 RPMs
Local -> Configuration files -> license file
Local -> Post-actions -> postDB2
See To Create a Profile.
Run a job on selected hosts that deploys the profile.
WebSphere is another popular licensed application that is not included in vendor distributions.
If you have the WebSphere CD and a valid license, you can use this scenario to make installation faster and to ensure that your servers are completely managed by Sun Update Connection – Enterprise. After you have uploaded WebSphere as an NCO to the local knowledge base, the Local Expansion Technology generates rules for it. These rules ensure that WebSphere will work as an integral part of your environment.
This procedure uses a script that calls up the WebSphere response file during automated installation.
Upload the WebSphere RPM to the local knowledge base.
The RPM will be listed under Local -> Local RPMs. See Adding Undetected Linux Software.
Create a Local File Declaration that is the path where the response file should be installed.
For example, the path is /tmp/WSresponse.txt
Upload the response file as a Local Configuration File under the File Declaration.
Create a script that runs WebSphere integrated installation procedures with the response file and then starts WebSphere.
#!/bin/sh # In this example, the installation directory should be # on a local filesystem. Should be updated for NFS if # moved to a non-standalone demo system SOURCE_DIR=”/root/demoscripts/websphere/WAS5Trial” WS_DIR=”/opt/WebSphere/AppServer/bin” # Ensure that the installation directory is available if [ ! -f $SOURCE_DIR/install ] ; then echo “WebSphere installer not available.” exit 1 fi #Install WebSphere using response file $SOURCE_DIR/install -options /tmp/wsresponse.rsp # Start the WebSphere server $WS_DIR/startServer.sh server1 exit 0 |
Upload the script under Local -> Post-actions -> postinstallWS.
See Uploading Actions.
Create a script that creates WebSphere users and groups.
#!/bin/sh # In this example, the installation directory should be # on a local filesystem. Should be updated for NFS if # moved to a non-standalone demo system SOURCE_DIR=”/root/demoscripts/websphere/WAS5Trial” # Users and groups needed if installing the Messaging Sub-system # (MQ Series) groupadd mqm groupadd mqbrkrs useradd -g mqm -G mqbrkrs mqm # Ensure that the installation directory is available if [ ! -f $SOURCE_DIR/install ] ; then echo “WebSphere installer not available.” exit 1 fi exit 0 |
Upload the script under Local -> Post-actions -> postsetupWS.
See Uploading Actions.
Create a profile that requires the following:
WebSphere RPM
Local -> Configuration files -> response file
Local -> Post-actions -> postinstallWS
See To Create a Profile.
Create a profile that requires Local -> Post-actions -> postsetupWS.
See To Create a Profile.
Create a complex job that deploys the first profile and then the second profile on selected hosts.