Implementing a Tivoli Solution for Central Management of Large Distributed Environments

130 Implementing a Tivoli Solution for Central Management of Large Distributed Environments

4.1 The Outlet Systems Management Solution

Based on the overall discussion provided in Chapter 3., “The Outlet Systems

Management Solution Architecture” on page 37, a Proof-of-Concept architecture

for the Outlet Systems Management Solution is presented in Figure 4-1.

Figure 4-1 Outlet Systems Management Solution architecture

Chapter 4. Installing the Tivoli Infrastructure 131

While developing this Proof-of-Concept architecture our target enterprise, Outlet

Inc., was envisioned as a huge, continent or country-wide retailer or financial

institution, with multiple brands and lines of business (LOB). We assumed that

the enterprise has a four-tier geographical structure including the following:

򐂰 Enterprise main office

򐂰 Multiple regional and country offices connected to the head office

򐂰 Multiple local and state-wide offices connected to the regional offices

򐂰 Multiple outlets connected to the local and state-wide offices

As you can see in Figure 4-1 on page 130, the Outlet Systems Management

Solution architecture follows the traditional Hub-Spoke architecture with

distributed managed nodes and gateways to allow for the lowest possible

bandwidth usage. In addition to the Tivoli Management Environment (TME)

management solution, the architecture includes an environment for database

support for all components as well as an environment for transaction monitoring.

It should be noted that the proposed architecture does not include two major

functional components which should be included to make the solution

production-ready. These two components are:

򐂰 Developing the TMR, TEC, and DB environments

򐂰 Staging the TMR, TEC, and DB environments

From a production point of view, these two environments will be required to

develop and test new Tivoli objects such as software packages, resource models

for monitoring, scanning profiles, event rules and so on, and to ensure that they

will operate flawlessly in the production environment. Development and staging

environments are, however, expected to be copies of the production

environment, so the following information about how to establish the productions

environment can easily be applied when implementing the development and

staging environments.

Design and development of procedures for testing, approving, and transferring

objects from the Development and Staging environments into the production

environment are so closely related to the Change Management philosophy of

each organization that they will not be addressed in the following.

4.1.1 Management environments

The TME architecture for the Outlet Systems Management Solution be divided

into four functionally different Tivoli Management Environment (TME) based

types of environments supported by two non-TME based environments.

However, the non-TME based environments will be monitored and managed

from the main Hub TMR environment:

132 Implementing a Tivoli Solution for Central Management of Large Distributed Environments

򐂰 non-TME environments

– ”The database environment”

– ”The transaction performance management environment”

򐂰 TME environments

– The Hub TMR environment

– Multiple Spoke TMR Environments

– Multiple Regional Environments

– Multiple Outlet Environments

For all four environments, the following technical and logistical prerequisites are

assumed to have been implemented prior to establishing the Outlet Systems

Management Solution:

򐂰 The operating platform for all systems is UnitedLinux 1.0 SP3.

򐂰 Every system involved in the systems management solution must satisfy the

Tivoli products hardware and software requirements, as described 3.4.1,

“Suggested Tivoli hardware requirements” on page 62.

򐂰 Every system involved in the systems management solution (TMRs,

managed node, and endpoints) must be connected to the TCP/IP Network.

򐂰 All systems will have domain Name Server (DNS) availability to perform IP

address resolution, including reverse mapping.

򐂰 WAN and LAN connections must be active and tested, and Outlet Inc.’s staff

will have to ensure a permanent effectiveness of the same.

In the following sections, we give brief descriptions of each of the functional

environments, and describe the roles and responsibilities of each systems in the

architecture.

The database environment

The purpose of the database environment is to provide RDBMS support for the

various solution components to store persistent data for specific management

tasks.

The final design of the database environment will be determined by a multitude

of factors that relate directly to client practices and policies as well as the

anticipated load on the systems. In a real implementation, the customer’s

database administrator (DBA) would be consulted for advice on how to configure

and manage the production RDBMS environment.

In the Outlet Systems Management Solution, we have decided to establish

RDBMS support for all systems management components in a single, dedicated

DB2 server named

rdbms and provide access to this server through DB2 Client

code installed where necessary.