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.
Using the Tivoli Service Automation Manager private cloud
Let’s start with a note about Tivoli Service Automation Manager’s userid management.
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:
- Cloud.ear: https://*hostname*:9443/cloud/rest/templates/
- TSAM REST: https://*hostname*:9443/maxrest/rest/mbo/PO
- IL REST: https://*hostname*:9443/ilrest/rest/os/TPV01IMGLIBENTRYMSTR
- MEAWeb UI: http://*hostname*:80/meaweb/verify
- Web2.0 UI: https://*hostname*:9443/SimpleSRM
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
User Name / Password Details: tioadmin/<your password>
WAS: wasadmin/<your password>
Database (MAXDB71): maximo/<your password>
Verify Tivoli Provisioning Manager status
Location: Management server
Scripts used for TPM start/stop –
Location: Management server
/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
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
Verify Device Manager Trace Servlet
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
Log in to verify admin server
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 188.8.131.52 is recommended
Older versions of Firefox are unable to launch the Tivoli Service Automation Manager installation launchpad. Use version 184.108.40.206 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
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.