These are critical key areas for preparing for your TBSM v4.2 deployment. I’d strongly recommend that you think through the bigger picture here as you begin your TBSM v4.2 journey, especially if you’re investing in many other Tivoli products. The desired end state for most clients investing in TBSM v4.2 is to have the consolidated operations management platform with end-to-end visibility realized. You can’t get there if you’re not thinking about how the sum of all the decisions and parts will come together in the end.
Part 1: Architecture
There are many significant changes to the fundamental software architecture require you to evaluate (re-evaluate) your architecture in four core areas.
Software Architecture (Failover, Load Balancing, Standalone, Split Server)
Considerations for how you will deploy the software should be discussed as early as possible. How you decide to move forward probably has a lot to do with how you will position TBSM v4.2 as a critical business and IT application or not. Many clients choose not to implement a highly available architecture initially. There are certainly economic and total costs of ownership considerations for not implementing this in the near term. The architecture for failover requires more hardware investment up front. Fancy ‘warm or cold’ standby systems approaches for failover can’t be used here, you’ve got to deploy and configure the systems day one or go through the potential headaches of re-configuration at a later date.
TBSM v4.2 introduces a new architecture model part in support of the new Tivoli Integrated Portal (TIP) platform but also in part for supporting a front end GUI and back end processing server split for increased scalability and performance. The dashboard server and data server concept basically enables scaling out the front end now offloading presentation layer processing from the backend data (events, datasources). TIP incorporates many components such as the application server (eWAS), portal server framework (ISC), Tivoli Common Reporting (TCR), AAA, and associated data access/API layers. When other TIP enabled products are installed such as Netcool/WebTop in TBSM v4.2, this is installed into the TIP server (dashboard server).
When to add more dashboard servers (TIP servers) is definitely a bit fuzzy at this time. There are certainly front end user load dynamics that come into play here where a firm understanding of the types of user volume and what those users will be doing should be understood. I’m thinking about how to classify types of users versus how TBSM v4.2 will be used to gauge these decisions along lines similar to these:
- Passive or Read Only Users
- Light TBSM/Event Management (both servers, OMNIbus server)
- Active TBSM/Event Management (both servers, OMNIbus server)
- Light Charting/Reporting (dashboard server)
- Heavy Charting/Reporting (dashboard server)
- Light TIP Customization (dashboard server)
- Heavy TIP customization (dashboard server)
- Multiple TIP enabled applications installed (TBSM, WebTop, ITNM, etc) (dashboard servers)
- etc.
When adding multiple front end dashboard servers one should always think about the end user and how they’ll be directed into the application. Most clients will front end multiple servers with a hardware server load balancer. TBSM v4.2 *may* include a piece of software called the IBM HTTP Server (from Websphere) that is basically a software based server load balancer. If you choose neither approach and you have multiple front end dashboard servers you will need to educate your end users how to move from one IP address to another should a server failure occur. Also note that TBSM v4.2 dashboard servers in a load balanced configuration (there’s really not a failover configuration here) require that an instance of DB2 v9 is available to support this load balanced architecture. This DB2 v9 instance is not managed by TBSM v4.2 in any way so be sure to invite your DB group to the planning meetings or be prepared to manage this DB2 v9 instance. (The DB2 v9 license entitlement has been verified, but AFAIK it’s not in the installation media. At this time, I do not have firm information that the IBM HTTP Server is being provided.)
My personal choice for future architectural improvements would be addressing TBSM v4.2 back end scalability improvements needed (supporting multiple Netcool/OMNIbus ObjectServers) or a hierarchical based model where multiple TBSM implementations could be aggregated to a master TBSM server (model aggregation, state and status across multiple TBSM servers and associated Netcool/OMNIbus ObjectServers). I think these are the last core architectural improvements needed apart from the much needed broad based expansion of ILOG use for all visualization and GUI components instead of Dojo Widgets and BIRT charts. A premium architecture upgrade would include some of the Cognos dashboard and GUI components like Decision Dashboard or Cognos Now operational BI platform. Hopefully these will come next year and not take three years to get done!
I think it’s probably a good starting point to assume a three server architecture as a minimum and doubling that when failover resiliency is required.
Operating Systems Architecture (OS, 32b v 64b, IPv4 v IPv6)
There are certainly more choices now in the area of how you choose to deploy the TBSM v4.2 software on an operating system platform. Formal support for more OS’s such as Red Hat 5, Suse 10, Windows 2008 and z/Linux are now available. I’m not very fresh on the internals of operating system mechanics but the 32b vrs. 64b decision is certainly growing more important. I know that TBSM v4.2’s optimization for 64b platforms is in its early stages still with plenty of room for optimization ahead. IPv4 and IPv6 decisions may be relevant in your environments though I have yet to work with a client who’s concerned here yet.
I can’t say one OS platform is better than another; IBM will support you within any supported platform for TBSM v4.2. Review the operating system patch level, driver and library requirements. There are some minimum update levels required in certain instances. I do EVERYTHING with Red Hat 4 or 5.
Systems Provisioning (CPU, Memory, Disk)
You will want to carefully review the system sizing recommendations. With the addition of the TIP component (based on eWAS + ISC) there has been an uptick in system resource requirements. Basically, throw as much CPU and Memory as you can at TBSM v4.2. Core Netcool/OMNIbus has always been pretty efficient so I don’t expect much change there. You can’t go wrong starting with 4CPU/8Gb RAM per dashboard and data server as a minimum. Disk requirements should not have changed much in terms of space. I continue to recommend as fast a disk as possible.
TBSM v4.2 should work within a virtual machine environment without any problems. The same CPU, memory and disk requirements hold true here. Some client systems administrator groups like to throttle the recommended requirements down and make application owners justify the CPU/Mem/Disk provisioning recommendations. If you’re in this boat, set application and user experience SLAs with your end users and use these as justification should TBSM v4.2 not perform in accordance to your end user’s requirements.
Integrations, Scenarios and Use Cases
Integrations should always be included in the high level architectural decisions and designs. TBSM v4.2’s many integration touch points include the event management integration layer into Netcool/OMNIbus utilizing the vast library of Netcool/OMNIbus probes and gateways.
Database integration for use within core TBSM v4.2 service models, charting and reporting should not be overlooked. How will you design access, authorization and authentication integration with a corporate LDAP, AD or other source? Are you using TADDM or other CMDB repositories? How will you integrate with them for building core TBSM v4.2 service models?
Integration with trouble ticketing systems using the Netcool/OMNIbus gateways or TBSM v4.2 Request Processor is a very common requirement. Event enrichment and advanced correlation performed by Netcool/Impact requires some thought and planning to ensure desired functions are provided and event processing in TBSM v4.2 occurs as expected. Lots of things to think of here as expected with Tivoli’s focus on integrations.
Where will event management be done? Is TBSM v4.2’s included Netcool/WebTop the best place to do this? Will you try to use TBSM v4.2 as an SLA platform? Do you really understand what SLA’s are (are not) in terms of TBSM? How about reporting? Do you envision hundreds of custom reports from across the enterprise served up by the TBSM v4.2 platform? Do you see console integration and consolidation as the main driver for your adoption of TBSM v4.2 and TIP? Do you have an environment with other non-Tivoli products?
The point here is that you’ve got to think through all of the intended operating scenarios here and plan out the architectural needs and decisions that must be made to support the desired operating models, scenarios and use cases. TBSM v4.2 is the start of a new platform for business service management for Tivoli. It probably should’ve been a dot zero release because of these significant changes introduced with the TIP architecture. We’ll certainly know more as time moves on and we get more clients on the platform and more experience under our belt, but there’s been a learning curve even for me here!
Next up, I’ll talk about the importance of the design phase.
Comments on this entry are closed.