This article details an actual pilot implementation project of a private cloud deployment model recently completed by the IBM® Global Delivery team. The initiative was accomplished by leveraging an IBM hardware and software stack, the software in this case is Tivoli®, as part of the strategic roadmap. The goal of this article (designed for IT specialists, architects, and technical team leaders) is to provide a reference guide for any cloud-related engagement. I think you'll find information in this article that is useful to all levels of experience — from beginners to advanced professionals.
This article assumes you have knowledge of basic cloud computing concepts and operations; you should also be familiar with AIX®, Power®VM, and virtualization concepts. You do not need extensive knowledge of WebSphere®, DB2®, or Tivoli products, but the use of those products is mentioned in this article.
The following topics are covered:
- The five phases in the roadmap: From concept to deployment.
- Some details on the unique solutions designed for this project.
- The typical cloud structure.
- The software/hardware requirements list for this project.
The five phases of this solution roadmap
The entire implementation of this project is a complex and lengthy process involving not only multiple technologies but also stakeholders, so it is imperative to carefully plan the schedule with a clear direction. Figure 1 captures the overall journey from the initial thought process to the final deployment, broken into five phases.
Figure 1. The project implementation in five phases
We'll come back to each of the phases and the activities in more detail.
Foreshadowing: Some solution details
The team first developed a service view to conceptualize the separation of the consumer and the service.
Figure 2. The cloud service view
Cloud end users should be able to put a service request through a user interface (UI) for nonfunctional requirements of resource workload; for example, a server resource for a pre-configured system such as but not limited to WebSphere Application Server (WAS) on the AIX OS or WebSphere Portal on AIX with specified computing power, memory, and storage as part of platform as a service, PaaS.
The cloud operations team would manage the cloud management platform, support infrastructure and operation such as defining the service, publishing the service visible to the consumer, analyzing the reports, generating bills based on the usage, usage pattern study, capacity planning, etc.
An assessment study was performed by conducting various interview sessions, as well as questionnaire distribution to multiple stakeholders and primary user groups, to define the service definition needed. As an example, the following service definition was reached, based on the nonfunctional requirements:
- Service 1: Web Stack i.e. AIX 6.1 with WebSphere Application Server 7.x, IBM HTTP Server (IHS) 7.x, DB2 Client 9.7.x, MQ Client 7.0.x.
- Service 2: Portal Stack i.e. AIX 6.1 with WebSphere Portal Server 6.1, IBM HTTP Server (IHS) 6.1, DB2 Client 9.5.x.
- Service 3: Database Stack i.e. AIX 6.1 with DB2 Enterprise Server 9.5.
- Service 4: Vanilla AIX 6.1 or 5.3.
After defining the cloud audience and services the audience requires, it was important to define the technology because the operation model would vary depending on the technology identified. The team decided to use IBM Tivoli Service Automation Manager (TSAM) product suite, considering such other alternatives as Citrix Smart Cloud and Open Source Clouds software.
Tivoli Service Automation Manager was chosen for the following reasons:
- Tivoli Service Automation Manager is an IBM strategic implementation product for service automation.
- It is suitable for cloud implementation especially when large number of IBM software stacks were being used.
- Citrix Smart Cloud using XenServer was more applicable for x/86 hardware; it was a good fit for a Wintel implementation.
- Open Source Clouds was more suitable for a Linux® distribution whereas the project requirement was to develop the solution, supporting AIX resource provisioning and further scalable to Linux and Windows resource type.
After defining the technology and service offering, the team finalizes the virtualization tools, the hypervisor, required for a cloud-managed environment. The following table looks at the data the team used to make its hypervisor tools assessment:
Table 1. Data used to assess hypervisor tools
|Name||Company||Host CPU||Guest CPU||Host OS||Guest OS||License|
|Microsoft Hyper-V Server||Microsoft||Intel VT or AMD-V||x64,x86||Windows 2008 w/Hyper-V Role, Windows Hyper-V Server||Windows 2x, XP, Vista, Linux (SUSE 10 or more)||Proprietary|
|OpenVZ||Community project, supported by SWsoft||Intel x86, AMD64, IA-64, PowerPC64, SPARC/64||Same as host||Linux||Various Linux distributions||GPL|
|PowerVM||IBM||POWER4, 5, 6, PowerPC 970||POWER4, 5, 6, PowerPC 970, X86||no host OS||Linux-PPC, Linux-X86, AIX, i5/OS, IBM i||Proprietary|
|VMware ESX Server||VMware||x86, x86-64||x86, x86-64||no host OS||Windows, Linux, Solaris, FreeBSD, Netware, OS/2, SCO, BeOS||Proprietary|
|Xen||Citrix Systems||x86, x86-64, and IA-64||Same as host||NetBSD, Linux, Solaris||FreeBSD, NetBSD, Linux, Solaris, Windows XP, and 2003 Server||GPL|
|z/VM||IBM||z/Architecture||z/Arch (z/VM does not run on predecessor mainframes)||no host OS||Linux on zSeries, z/OS, z/VSE, z/TPF, z/VM, VM/CMS, MUSIC/SP, OpenSolaris for System z, and predecessors||Proprietary|
From studying the various pros and cons in the tool assessment data, the team chose IBM PowerVM for cloud image provisioning to leverage the existing Power hardware infrastructure in this environment and to better match the requirements of Tivoli Service Automation Manager. Once the team identified the technology roadmap and hypervisor model, it built a target architecture solution.
Before diving further into the implementation, let's look at a typical cloud structure for reference.
The typical private cloud structure
In its simplest form, Tivoli Service Automation Manager topology consists of one management system server (could be System P, System X, or System Z), one administrative server (System X), and one managed server (could be System P, System X, or System Z). The management and administrative servers are required exclusively by Tivoli Service Automation Manager for the installation of cloud software; the managed environment involves provisioning and management of the virtual servers by Tivoli Service Automation Manager, based on customer requests.
Figure 3 shows the architecture of what the team had in its environment:
Figure 3. The typical cloud architecture
One System P server is being virtualized into multiple logical partitions (LPARS) with one LPAR being utilized for the Tivoli Service Automation Manager management server and possessing Tivoli Provisioning Manager (TPM) and various middleware products such as DB2, WAS, HTTP Server, LDAP (these middleware products are actually part of the Tivoli Provisioning Manager suite).
The other LPARs of this server are designated for associated but optional components such as IBM Tivoli Usage and Accounting Manager (ITUAM) for metering and IBM Tivoli Monitory (ITM) for infrastructure monitoring. Two other LPARs are meant for Network Installation Manager (NIM) server (image storage) and VIOS for AIX partitioning.
The other System P server is utilized for cloud managed environment where all virtualized images or resources would be provisioned automatically by the service requester, the consumer. (You may use System X for similar provisioning of Windows and Linux resources using VMware hypervisor.)
Another System X server is used for a Tivoli Service Automation Manager administration component with Tivoli Provisioning Manager web, image library, and for Service Request Manager (SRM).
System P hardware is being managed by Hardware Management Console (HMC) hardware as a standard Power system management tool.
All the System P LPARS ran AIX 6.1 while the System X ran SuSE Linux 10.2 (both 64 bits). Tivoli Storage Manager (TSM) was employed to make a backup of the AIX environments while G4L was used for the Linux.
The major hardware and software players for the project
Here's the list of the final hardware and software requirements:
- IBM System P/570 for Cloud Management Environment
- IBM System P/570 for Cloud Managed Environment ( for users )
- IBM System x/3850 for Cloud Administration Environment
- Tivoli Service Automation Manager (TSAM)
- Tivoli Provisioning Manager (TPM)
- Tivoli Service Request manager (TSRM)
- Tivoli Monitoring (ITM)
- Tivoli Usage and Accounting Manager (TUAM)
- Hypervisor - Power VM
- For taking image backups: Tivoli Storage Manager (TSM), G4L (Open Source)
Please note that ITM and TUAM are optional software components; they are not part of the standard Tivoli Service Automation Manager product suite.
In this article, I've provided the background planning concepts for a real-world project implementation to build an on-premise IaaS/PaaS cloud, including:
- The five development phases: Requirements ID, infrastructure setup, architecture/deployment models, the infrastructure build, and deployment.
- Some details on the unique solutions designed for this project: A service view to separate consumer and provider, how to assess and build the service definition, and how components were chosen.
- The typical cloud structure and how components interact.
- The software/hardware requirements list for this project.
Part 2 of this series covers installing and configuring the components, and some of the special features of the components.
I would like to express my gratitude to the following members of my team who were involved in this engagement and directly or indirectly provided inputs to this article: Biswajit Mohapatra, Debasis R. Choudhuri, Santhosh Vandyil, Birla P. Raj.
I would also like to thank the India Cloud Lab team and the IBM Software Group, Poland and Germany, for their valuable guidance during this engagement.
- For Tivoli Service Automation Manager, product manuals, installation guides, and other documentation are available in the IBM Tivoli Service Automation Manager Documentation Center.
- In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
- The next steps: Find out how to access IBM SmartCloud Enterprise.
- For technical developer content and resources for cloud computing, see Cloud computing: Fundamentals.
- Follow developerWorks on Twitter.
Get products and technologies
- See the product images available for IBM SmartCloud Enterprise.
- Join a cloud computing group on developerWorks.
- Read all the great cloud blogs on developerWorks.
- Join the developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.