Building your cloud using IBM hardware and software (Part 3 of 3) – Test and Use

Discover how cloud provisioning works with the system

Summary: Part 3 of the three-part blog series defines IBM Tivoli Service Automation Manager and Tivoli Directory Server user roles, provides an example of the cloud provisioning process and a list of sample exercises the user can do to test the implementation, and shows you some general hints and tips we learned in implementing the project.

See also Part 1 and Part 2.

Using the Tivoli Service Automation Manager private cloud

Let’s start with a note about Tivoli Service Automation Manager’s userid management.

User roles

During the installation of Tivoli Service Automation Manager, it also automatically installs an instance of Tivoli Directory Server. The Web 2.0 self-service user interface of Tivoli Service Automation Manager allows cloud administrators to add and remove cloud users. Tivoli Service Automation Manager is built on top of Tivoli’s process automation engine; when a cloud administrator uses the Web 2.0 user interface to add a user, the user’s ID is added into Tivoli Directory Server. In addition, the user’s information is also stored in several process automation engine database tables, including MAXIMO.maxuser, MAXIMO.person, and MAXIMO.email.

In other words, adding a user involves changing data in both Tivoli Directory Server and Tivoli’s process automation engine. When a user logs on, the user is authenticated with Tivoli Directory Server.

Tivoli Service Automation Manager provides four types of user roles; any user has to be mapped into one of these:

  • Cloud admin: Can see and do everything; can create, modify, remove a team; can create, modify, remove a user.
  • Cloud manager: Has read-only abilities of the cloud admin; can see everything but do nothing.
  • Team admin: Can see everything in one’s team area; can do all admin tasks for one’s team area.
  • Team user: Can see everything in one’s team area; can do no admin tasks for one’s team area.

Remember, a user can have only one of these roles, and a user can be in zero or more teams.

Cloud provisioning process

The Tivoli Service Automation Manager Web 2.0 GUI is self-explanatory. The following figure shows the simple provisioning process.

Before you can provision, be sure you have completed a registration process to gain access to the cloud self-service portal. This step means that only authorized users can gain access to the portal and place a request for provisioning.

After the cloud user requests a service, a workflow is triggered whereby email notification is sent to the cloud administrators who can validate the request. If approved, the provisioning takes place automatically.

You will receive two email notifications regarding your provisioning. The first indicates that your service request has been accepted. The second contains your virtual host name and connection information (as in the following sample).

Sample notification of provisioning request details

Dear Joydipto Banerjee
You have started a new Project WAS_L2SOA with the following topology:
The server vioclient26ftp has been added with the following parameters
Hostname of Server: vioclient26ftp
Number of CPU(s): 2
Number of tenths of physical CPUs: 2
Amount of Memory: 4096 MB
Swap Size: 0 MB
Disk Space Size: 20
Admin Password:XXXXXX
Link to the Server: http://vioclient26ftp:80
The user of group GBS USER has been notifed.
Regards,
Your Service Automation Team

Use those details to connect to the new server with SSH.

Further details about how to use the various offerings in the self-service portal are in the Tivoli Service Automation Manager user guide.

Useful hints, tips, and tests

This section has helpful information, caveats, and examples.

Links to help you test your installation setup

It is advisable to test the setup periodically during the installation phase. Depending on which stage of the installation process you are currently on, some of these links might not be activated. However, all these links should work after the entire installation is complete:

Note: Here *hostname* refers to the management server hostname/IP address.

Twelve useful verification tests to check the sanity of the installation

You can execute these at the end of each segment during the installation phase to verify middleware and Tivoli Provisioning Manager status, the WebSphere Application Server Console and Agent Manager URLs, and more.

Verify middleware status

Location: Management server

Script:

/images/install_images/TSAMBASE7200/install/tools/tsam_middleware.sh
status
User Name / Password Details: tioadmin/<your password>
WAS: wasadmin/<your password>
Database (MAXDB71): maximo/<your password>

Verify Tivoli Provisioning Manager status
Location: Management server
Script:

/opt/IBM/tivoli/tpm/tools/tioStatus.sh

Scripts used for TPM start/stop –
Location: Management server
Scripts:

/opt/IBM/tivoli/tpm/tools/tio.sh <start/stop>
/opt/IBM/tivoli/tpm/tools/tio.sh <start/stop> -t - TPM
/opt/IBM/tivoli/tpm/tools/tio.sh <start/stop> -w - WAS

Verify WebSphere Application Server Console URL

https://*hostname*:9043/ibm/console/logon.jsp
Username: wasadmin
Password: <your password>

Verify Agent Manager URL

http://*hostname*:9513/AgentMgr/Info

Verify HMC Console

https://<your HMC server hostname>/hmc/connect
Username: hscroot
Password: <your password>

Verify Maximo URL

https:// *hostname*:9443/maximo/ui/login
Username: maxadmin
Password: <your password>

Verify Maximo Help URL

https:// *hostname*:9443/maximohelp/en/

Verify Device Manager Trace Servlet

http:// *hostname*:9080/dmserver/TraceServlet?trace=set

Verify Dynamic Content delivery URL

http:// *hostname*:9080/admin/
Username: maxadmin
Password: <your password>

Log in to verify management server after starting Tivoli Provisioning Manager

/usr/ibm/tivoli/common/COP/logs/tio_start.log
/usr/ibm/tivoli/common/COP/logs/tio_start_service.log
/opt/IBM/tivoli/tpm/lwi/logs
/usr/IBM/WebSphere/AppServer/profiles/ctgDmgr01/logs/dmgr
/usr/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/logs/nodeagent
/usr/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/logs/MXServer
/usr/IBM/WebSphere/AppServer/profiles/casprofile/logs/server1

Log in to verify admin server

/opt/IBM/SMP/logs

A better way to start the Tivoli Service Automation Manager middleware

Instead of using the supplied middleware start script, tsm_middleware.sh, a better way is to start the middleware and Tivoli Provisioning Manager using the following procedure (the manual way of starting it):

1. Start DB as ctginst1, db2inst1,and idsccmdb:

su - ctginst1 -c "db2start";su - db2inst1 -c "db2start";su -
idsccmdb -c "db2start";

2. Start LDAP as idsccmdb:

/opt/IBM/ldap/V6.2/bin/idsdirctl -D cn=root -w <your password> start

3. Start WebSphere Application Server and Tivoli Provisioning Manager as tioadmin:

su - tioadmin
cd $TIO_HOME/tools
./tio.sh start

Minimum Firefox 3.0.7.0 is recommended

Older versions of Firefox are unable to launch the Tivoli Service Automation Manager installation launchpad. Use version 3.0.7.0 for best results.

An issue with sendmail

If you find that the mail functionality is not working on the management server, be sure to check whether the sendmail daemon is running; if not, manually start sendmail.

Several sample cloud test cases

Finally, I offer a checklist of sample use cases that can be executed through the self-service GUI after the private cloud setup is complete. The list covers most areas in which you’ll want to test functionality. Again, the instructions for how to execute these tasks are provided in the Tivoli Service Automation Manager user guide.

1. Managing users

a. Creating new teams

b. Modifying team information

c. Removing a team

d. Modifying user information

e. Removing a user

2. Creating a project and adding virtual servers

3. Requesting approval process

4. Adding virtual servers to an existing project

5. Modifying reservation dates

6. Canceling a project

7. Modifying server

a. Resetting a server password

b. Restarting a server

c. Removing a virtual server

d. Starting a server

e. Stopping a server

8. Backing up and restoring server images

a. Creating server image

b. Removing a virtual server image

c. Restoring a server from image

9. Managing Image Library

a. Registering an image in the Image Library

b. Unregistering an image in the Image Library

In conclusion

With this final piece, I conclude the three-part blog series providing the background planning concepts for a real-world project implementation to build an on-premise private cloud. I hope this gives you a good start to planning and implementing your own IaaS or PaaS cloud. If you liked the content series, please do leave a comment here. Thank you.

Share
Comments: 23
Joydipto Banerjee

About Joydipto Banerjee

Joydipto is an IBM Certified Consulting IT Specialist(Master Certified IT Specialist from The Open Group). His areas of interests are application modernization and Cloud computing. Joydipto has published several papers, got certified in Cloud solutions and achieved a number of awards within IBM. He is based in Kolkata, India but currently works out from the Mumbai coast.
This entry was posted in All Posts and tagged , , , , , , , . Bookmark the permalink.