test

Sun Update Connection - Enterprise 1.0 User's Guide

Chapter 15 Sun Update Connection – Enterprise Scenarios

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:

Clusters

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.

Creating an openMosix Cluster with Sun Update Connection – Enterprise

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.

ProcedureTo Create an openMosix Cluster with Sun Update Connection – Enterprise

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

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

  3. Install the agent on the other machines.

  4. Add the openMosix RPM to the local knowledge base.

    The Local Expansion technology creates deployment rules.

    See Adding Undetected Linux Software.

  5. In a text editor, create /etc/mosix.map.

    This file maps a node number to each IP address.

  6. Add a file declaration called /etc/mosix.map

    See Creating File Declarations.

  7. Add the /etc/mosix.map file to the local knowledge base.

    See Uploading Local Configuration Files.

  8. In a text editor, create a version of /etc/hosts which includes the hosts to be in the cluster.

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

  10. Write a script that changes the default boot kernel to openMosix in the grub table:


    OpenMosixAsDefault.sh

    See Writing Actions.

  11. Add this script to Local/Pre-actions.

    See Uploading Actions.

  12. Add this script to Local/Post-actions.

    See Uploading Actions.

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

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

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

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

  17. Run the job again in deploy mode on the openMosixCluster group.

    All selected machines are now nodes of a cluster. See Creating Complex Jobs.

ProcedureTo Add a Node to the Cluster

  1. Install the agent on the new machine.

    See the Sun Update Connection - Enterprise 1.0 Administration Guide.

  2. Add this managed host to the openMosixCluster group.

    See To Edit a Group.

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

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

Floating Servers and Loads

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.

Creating Floating Server Environment

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.

ProcedureTo Create a Floating Server

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

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

  3. If there are various distributions used in the server pools and in the floating servers, align the profiles for all relevant distributions.

    See To Align Component Settings for Multiple Distributions.

  4. Create a policy that automates all actions (Yes to all actions on all Software) and call it YesToAll.

    See To Create a Policy.

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

  6. In the Idle group, assign a spare server that is your floating server and name it floating.

    See To Assign a Host to Groups and To Edit a Managed Host.

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

floatingServers.sh Script

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


#! /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
Note –

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.

Cloning Servers

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.

Before You Begin

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.

ProcedureTo Clone a Single Server

This procedure uses the Inventory Comparison feature.

  1. Make sure that the source managed host is online and as optimal as you think.

    Run the predefined system profiles on this host.

    See Running Predefined Profiles.

  2. Make sure the target managed host is online.

  3. From the Tools menu, choose Preferences.

    The Preferences window opens. See Accessing and Editing Preferences.

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

  5. From the Hosts menu, choose Compare Inventories.

    The Inventory Comparison window opens. See Comparing Inventories.

  6. Select the Target host and the Source host.

  7. Select the current inventory for both hosts.

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

  9. Click the Compare button and select the Tasks to Make Target like Source option.

  10. Click the Make Target like Source button and send the clone job.

ProcedureTo Clone Multiple Servers

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.

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

    See Convert Inventory to Profile (-cip) Command.

  2. View the attributes of the profile (what is required and what is not allowed).


    # uce_cli -lpa -P profileName -u user -p password

    See List Profile Attributes (-lpa) Command.

  3. To protect legacy components on the target servers, delete the profile attributes that you do not want to clone over.

    1. Export the profile to an XML file name.


      # uce_cli -exp -ent "Profile" -f path-and-filename.xml -T "profile" -u user -p password

    2. Edit the XML file. Delete the lines that mention components you want to protect on targets.

    3. Import the edited XML file as the profile.


      # uce_cli -imp -f path-and-filename.xml -u user -p password

    See Export (-exp) Command.

  4. In the console, create a job that deploys the profile on selected hosts.

    See Creating Complex Jobs.

Sharing Directories

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.

Mounting an NFS Directory

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.

ProcedureTo Mount an NFS Directory

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

  2. Upload the script as a Local -> Pre-Action -> mntnfs.

    See Uploading Actions.

  3. Create a profile that requires nfs-utils and mntnfs.

    See To Create a Profile.

  4. Make the profile applicable to all active distributions.

    See To Align Component Settings for Multiple Distributions.

  5. Run a job on selected hosts that deploys the profile.

    See Creating Complex Jobs.

Mounting a Windows File System from Linux

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.

ProcedureTo Mount a Windows Directory from a Linux Filesystem

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

  2. Upload the script as a Local -> Post-Action -> mntWin.

    See Uploading Actions.

  3. Create a profile that requires samba-client and mntWin.

    See To Create a Profile.

  4. Make the profile applicable to all active distributions.

    See To Align Component Settings for Multiple Distributions.

  5. Run a job on selected hosts that deploys the profile.

    See Creating Complex Jobs.

DB2

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.

ProcedureTo Deploy DB2 on Multiple Machines

This procedure uses a script that calls up the DB2 license file during automated installation.

  1. Upload the DB2 RPMs to the local knowledge base.

    The RPMs are listed under Local -> Local RPMs. See Adding Undetected Linux Software.

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

    See Creating File Declarations.

  3. Upload the license file as a Local Configuration File under the File Declaration.

    See Uploading Local Configuration Files.

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

  5. Upload the script under Local -> Post-actions -> postDB2.

    See Uploading Actions.

  6. Create a profile that requires the following:

    • All DB2 RPMs

    • Local -> Configuration files -> license file

    • Local -> Post-actions -> postDB2

    See To Create a Profile.

  7. Run a job on selected hosts that deploys the profile.

    See Creating Complex Jobs.

WebSphere

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.

ProcedureTo Deploy WebSphere on Multiple Machines

This procedure uses a script that calls up the WebSphere response file during automated installation.

  1. Upload the WebSphere RPM to the local knowledge base.

    The RPM will be listed under Local -> Local RPMs. See Adding Undetected Linux Software.

  2. Create a Local File Declaration that is the path where the response file should be installed.

    For example, the path is /tmp/WSresponse.txt

    See Creating File Declarations.

  3. Upload the response file as a Local Configuration File under the File Declaration.

    See Uploading Local Configuration Files.

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

  5. Upload the script under Local -> Post-actions -> postinstallWS.

    See Uploading Actions.

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

  7. Upload the script under Local -> Post-actions -> postsetupWS.

    See Uploading Actions.

  8. Create a profile that requires the following:

    • WebSphere RPM

    • Local -> Configuration files -> response file

    • Local -> Post-actions -> postinstallWS

    See To Create a Profile.

  9. Create a profile that requires Local -> Post-actions -> postsetupWS.

    See To Create a Profile.

  10. Create a complex job that deploys the first profile and then the second profile on selected hosts.

    See Creating Complex Jobs.