Additional actors

An additional actor is the Provisioning Provider. In in our lab environment, we use an existing provisioning infrastructure, which is represented by this system actor. Quantity: one

7.3.2 Node description

In this section, we describe each logical and physical node in the operational model shown in Figure 7-2.

PN1a Gateway 01 and PN1b Gateway 02

The

logical node LN1 Gateway

is placed on two physical nodes for scalability reasons. Table 7-3 on page 87 shows the PN1a Gateway 01 and PN1b Gateway 02 requirements.

Table 7-3 PN1a Gateway 01 and PN1b Gateway 02

PN2a Reporting 01 and PN2b Reporting 02

The

logical node LN2 Reporting

is the centerpiece of the Smart Analytics Cloud; therefore, to show the scalability requirements, this node is placed on two

Hardware Linux guest in a z10 server

򐂰 2 CPU

򐂰 1 GB memory

򐂰 15 GB disk space

Operating System SUSE Enterprise Linux 11 (s390x 64bit)

Software 򐂰 IBM WebSphere HTTP Server V7.0.0.9 (64bit)

򐂰 IBM WebSphere Application Server Network Deployment V7.0.0.9 (64bit)

򐂰 IBM Cognos Gateway V8.4.1 (64bit) Presentation Cognos login

Data None

Network connections 򐂰 http/https from PN9 browser of Cloud Application Manager

򐂰 SOAP/http to PN3, PN3s, PN2a, PN2b Availability As near to 24 x 7 x 52 as possible

Scalability 򐂰 The server can use more capacity by adding either extra capacity to existing engines on the server, by making the engines faster, or both.

򐂰 New server image can be added to the cluster to provide more Gateway server images Security 򐂰 Users’ authentication checking is done through

user registry using LDAP

򐂰 Authorization checking is done through Cognos Access Manager

Systems management 򐂰 IBM Tivoli Monitoring for O/S

򐂰 ITCAM for WebSphere

򐂰 ITCAM for IBM HTTP Server DR requirements Yes

identical physical nodes. This set of physical nodes does the reporting within the cloud environment.

Table 7-4 on page 88 contains PN2a Reporting 01 and PN2b Reporting 02. Table 7-4 PN2a Reporting 01 and PN2b Reporting 02

PN3 Content Manager and PN3s Content Manager Standby

The logical node LN3 Content Manager is placed on two physical nodes: one as the primary node and the other as a standby.

Table 7-5 on page 89 contains PN3 Content Manager and PN3s Content Manager Standby.

Hardware Linux guest in a z10 server

򐂰 2 CPU

򐂰 4 GB memory

򐂰 24 GB disk space

Operating System SUSE Enterprise Linux 11 (s390x 64bit) Software 򐂰 IBM DB2 Client V9.5

򐂰 IBM WebSphere Application Server Network Deployment V7.0.0.9 (64bit)

򐂰 IBM Cognos Dispatcher (64bit)

򐂰 IBM Cognos Reporting V8.4.1 (64bit) Presentation Cognos report view

Data None

Network connections SOAP/http from PN1a, PN1b DB2 to PN4

Availability As near to 24 x 7 x 52 as possible

Scalability 򐂰 The server can utilize more capacity by adding either extra capacity to existing engines on the server, by making the engines faster, or both

򐂰 New server image can be added to the cluster to provide more Report server images

Security 򐂰 Users’ authentication checking is done through the user registry using LDAP

򐂰 Authorization checking is done through Cognos Access Manager

Systems management 򐂰 IBM Tivoli Monitoring for O/S

򐂰 ITCAM for WebSphere DR requirements Yes

Table 7-5 PN3 Content Manager and PN3s Content Manager Standby

PN4 Database Server and PN4s Database Server Standby

In our reference installation, we do not have a number of external source systems; instead, we built a sample database based on all of the external source systems.

The physical node combines the following elements:

򐂰 LN22 Onboarding Data

򐂰 LN4 Metadata

򐂰 System Actor

Data Source

Hardware Linux guest in a z10 server

򐂰 2 CPU

򐂰 4 GB memory

򐂰 24 GB disk space

Operating System SUSE Enterprise Linux 11 (s390x 64bit) Software 򐂰 IBM DB2 Client V9.5

򐂰 IBM WebSphere Application Server Netwrok Deployment V7.0.0.9 (64bit)

򐂰 IBM Cognos Dispatcher (64bit)

򐂰 IBM Cognos Content Manager V8.4.1 (64bit)

Presentation None

Data None

Network connections 򐂰 SOAP/http from PN1a, PN1b

򐂰 JDBC to PN4

Availability As near to 24 x 7 x 52 as possible

Scalability 򐂰 The server can utilize more capacity by adding either extra capacity to existing engines on the server, by making the engines faster, or both.

򐂰 New server image can be added to the cluster, but it can only be running as Standby mode. Security 򐂰 Users’ authentication checking is done through

the user registry using LDAP.

򐂰 Authorization checking is done through Cognos Access Manager.

Systems management 򐂰 IBM Tivoli Monitoring for O/S

򐂰 ITCAM for WebSphere DR requirements Yes

Table 7-6 contains the PN4 Database Server and PN4s Database Server Standby.

Table 7-6 PN4 Database Server and PN4s Database Server Standby

PN9 Modeling Client

This node hosts the logical node LN9 Modeling Client. Table 7-7 contains the requirements for the PN9 Modeling Client.

Table 7-7 PN9 Modeling Client

Hardware Linux guest in a z10 server

򐂰 2 CPU

򐂰 4 GB memory

򐂰 30 GB disk space

Operating System SUSE Enterprise Linux 11 (s390x 64bit) Software IBM DB2 V9.5 (64bit)

Presentation None

Data 򐂰 Onboarding application data

򐂰 Cognos Server Content Store

򐂰 Sample source data

Network Connections 򐂰 JDBC to PN3, PN3s, PN21a, PN22b

򐂰 DB2 to PN2a, PN2b

Availability As near to 24 x 7 x 52 as possible

Scalability The server can utilize more capacity by adding either extra capacity to existing engines on the server, by making the engines faster, or both. Security Users’ authentication checking is done through the

native O/S.

Systems management 򐂰 IBM Tivoli Monitoring for O/S

򐂰 IBM Tivoli Monitoring for DB2 DR requirements Yes

Hardware WINDOWS compatible PC Operating System WINDOWS

PN11 Deployment Manager

The

logical node L11 Deployment Manager

becomes one physical node.

It can put it on one of the other nodes that host a WebSphere Application Server, but every instance must be treated equally. Table 7-8 contains the requirements for the PN11 Deployment Manager.

Table 7-8 PN11 Deployment Manager

Software 򐂰 IBM Cognos Framework Manager V8.4.1

򐂰 Microsoft® Data Access Component (MDAC) V2.6 or higher

򐂰 DB2 Connect™ V9.5 Presentation To actor

Cloud Power User

Data None

Network connections http/https to PN1a, PN1b

Availability N/A

Scalability N/A

Security Users’ authentication checking is done through native OS

Systems management N/A DR requirements N/A

Hardware Linux guest in a z10 server

򐂰 2 CPU

򐂰 2 GB memory

򐂰 16 GB disk space

Operating System SUSE Enterprise Linux 11 (s390x 64bit) Software IBM WebSphere Application Server Network

Deployment V7.0.0.9 (64 bit)

Presentation WebSphere Application Server Admin Console

Data None

Network connections SOAP/RMI to PN1a, PN1b, PN2a, PN2b, PN3, PN3s, PN21a, PN22b

PN12 SM Portal Server

The

logical node LN12 SM Presentation

becomes one physical node. Table 7-9 contains the requirements for the PN12 SM Portal Server.

Table 7-9 PN12 SM Portal Server

Scalability The server can utilize more capacity by adding either extra capacity to existing engines on the server, by making the engines faster, or both. Security Users’ authentication checking is done through user

registry using LDAP

Systems management IBM Tivoli Monitoring for O/S DR requirements Yes

Hardware Linux guest in a z10 server

򐂰 2 CPU

򐂰 1 GB memory

򐂰 16 GB disk space

Operating System SUSE Enterprise Linux 11 (s390x 64bit) Software 򐂰 IBM DB2 V9.5 (64bit)

򐂰 Tivoli Enterprise Portal Server

Presentation http/https from browser of Cloud Administrator

Data None

Network connections IP.PIPE to PN10

Availability As near to 24 x 7 x 52 as possible

Scalability The server can utilize more capacity by adding either extra capacity to existing engines on the server, by making the engines faster, or both Security Users’ authentication checking is done through user

registry using LDAP Systems Management N/A

PN13 SM Monitoring

The

logical node LN13 Systems Management Monitoring

becomes on physical node. Table 7-10 contains the requirements for PN13 SM Monitoring.

Table 7-10 PN13 SM Monitoring

PN21a Onboarding 01 and PN21b Onboarding 02

The

logical node LN21 Onboarding

is placed on two physical nodes in a cluster to show how to cope with high-availability requirements for this node. Normally, that is not necessary because the non-functional requirements are not that high for this kind of operation. Table 7-11 on page 94 contains the PN21a Onboarding and PN21b Onboarding Standby.

Hardware Linux guest in a z10 server

򐂰 2 CPU

򐂰 1 GB memory

򐂰 9 GB disk space

Operating System SUSE Enterprise Linux 11 (s390x 64bit) Software 򐂰 IBM DB2 V9.5 (64bit)

򐂰 Tivoli Enterprise Monitoring Server

򐂰 Tivoli Monitoring Datawarehouse

򐂰 Tivoli Directory Server

Presentation Interface to the Provisioning Provider

Data None

Network connections IP.PIPE from PN1a, PN1b, PN2a, PN2b, PN3, PN3s, PN4, PN4s, PN11, PN21a, PN21b Availability As near to 24 x 7 x 52 as possible

Scalability The server can utilize more capacity by adding either extra capacity to existing engines on the server, by making the engines faster, or both Security Users’ authentication checking is done through user

registry using LDAP Systems management N/A

Table 7-11 PN21a Onboarding and PN21b Onboarding Standby

In document The Smart Analytics Cloud Network Infrastructure Model (Page 106-114)