WorldView Tunneling (WVDBT) Insights for Unicenter NSM r11.1

WorldView Tunneling (WVDBT)

Insights for Unicenter NSM r11.1

Latest Revision September 11, 2006

Copyright ©2006 CA. All rights reserved. All trademarks, trade names, services marks and logos referenced herein belong to their respective companies. 2

Disclaimer

- The topics in this presentation apply to Unicenter NSM r11.1

- If you are using Unicenter NSM Release 3.1, please review presentation WorldView Tunnelling (WVDBT) Insights for Unicenter NSM 3.1

http://techweb.ca.com/training/tngimpl/d2u09wvdbt.ppt

http://techweb.ca.com/training/tngimpl/d2u09wvdbt.ppt


What is wvdbt?

-WorldView Database Tunnel (WVDBT)

- Agent Technology service that provides access to MDB (CORe) for remote Distributed State Machines (DSMs)

- CORe proxy for DSMs (aws_dsm and aws_wvgate) running on a “CORe-less” servers

-WVDBT is dependent on aws_orb


Why use it?

- Access remote CORe without direct access to SQL MDB - This eliminates the need to have SQL client active- Assists in minimizing SQL license requirements

- Heterogeneous access to CORe - Linux server can access Windows SQL MDB (CORE) via WVDBT- Windows server can access Linux Ingres MDB (CORE) via wvdbt.- Windows DSM does not require Ingres Client to access Linux MDB via

WVDBT

- Windows server can access remote Windows SQL MDB and, similarly, Linux can access remote Linux Ingres MDB

- Provides access to r11.1 CORE for NSM 3.1 DSMs*- Ideal for firewall deployment (no direct access to SQL required!)- SQL port can be blocked after the install process completes

- * support for this option is currently being clarified


WVDBT and Agent Technology

-WVDBT is designed for use with Agent Technology DSM components

- It cannot be used by non-Agent Technology components such as 2dmap


SQL Client

- Distributed State Machine requires SQL client during install process

- In NSM r11.1 DSM install process will not continue if SQL client is not installed

-Once the install process is completed, however, SQL client can be de-installed


Agent Technology - Install

Since AT Manager Distributed State Machine Component is selected, SQL client is required during NSM Install


Linux wvdbt Service

- Here, Linux wvdbt service is in running state, providing access to Linux Ingres CORe for remote DSM servers including those on Windows


Windows Client

- In this example, wvrepsel was executed to define Linux CORE used by Windows Distributed State Machines services

-On client machine, wvrepsel –t is all that is required to access remote CORe via wvdbt


Windows Client

- Here Linux Ingres CORe is accessed by Windows DSM via WVDBT


Linux Server

- This shows Windows connection. Windows client address is 141.202.120.80


WV Tunnel – Linux Connection

- Here Windows aws_dsm connects to Linux Ingres CORe


WV Tunnel – Windows Connection

- Here aws_wvgate connects to a Windows WVDBT server


WVDBT in NSM 3.1 vs. 11.1

- NSM 3.1 requires rename of ATcatngrep.dll, to access CORe via wvdbt.

- NSM r11.1 wvdbt uses catngrepaw.dll (without rename) instead. ATcatngrep.dll is not available on r11.1 systems

- In r11.1, if WorldView administrative component is installed it can continue to access CORE via SQL while aws_dsm and aws_wvgate access CORE via wvdbt. In NSM 3.1, this requires manipulation of path entries to ensure correct dll is picked up.


Installing wvdbt on Windows

- Add wvdbt service on the Distributed State Machine server on which the CORE resides or which has access to CORE via SQL client

-wvdbt installauto –dependOn=aws_orb

-Wvdbt binary resides in the following directory: C:\Program Files\CA\SharedComponents\CCS\AT\SERVICES\BIN

- Ensure aws_orb is in Running state prior to executing “wvrepsel –t”


Wvdbt Install - Windows

- This shows wvdbt service added to start automatically. It is dependent on aws_orb


Execute wvrepsel -t

- Verify aws_orb is running

- To access remote core via wvdbt, execute “wvrepsel –t”

- Restart awservices

- aws_wvgate and aws_dsm should then access the remote CORE via wvdbt


Execute wvrepsel -t

- Here wvrepsel –t has failed because aws_orb was not started


Registry Entry


Distributed Services Bus (aws_orb)

ObjectStore

DomainManager

NetworkState Machine

SNMPGateway

WorldViewDSM

Gateway

WVDBT

MDBCORE

WvdbtConnection to CORE

Distributed State Machine



WVDBT

CommonObject

Repository


WorldViewDSM

Gunners1

Rocking2

Distributed State Machine

Re-Connection


WVDBT Re-connection

- If the WVDBT service is stopped, then Distributed State Machine will lose its connection to the CORe

- Remote Distributed State Machine will wait for notification from WVDBT Server to reconnect

- aws_wvgate service will cache WV updates while the connection is lost

-When reconnect notification is received from WVDBT server it processes WV updates that were cached while the connection was lost


Lost Connection

- This shows connection wvdbt server lost as the wvdbt is stopped


WorldView Updates

-Windows System Agent Service Instance Monitoring reports “Service Critical”

- This triggers aws_wvgate to update the status

- Aws_wvgate is not able to connect to the CORE via wvdbt as wvdbt is service is down

- “Service Critical” update request is cached until connection is restored (at which point the WV CORE will be updated)


WorldView Update

- Here aws_wvgate is unable to update CORe while wvdbt service is down. Requests are cached


WorldView Updates Lost Cache

- Here you can see how the “Service Critical” status generated by Windows System Agent is cached – WinA3- SrvsInstCritical


Reconnection

- Aws_wvgate automatically reconnects when wvdbt service is restarted


WV Cache Updates

- Here you can see that the updates cached while WVDBT was down are re-applied when the WVDBT service is restarted

- The following picture shows the Windows System Agent changed to WinA3_SrvcInstCritical


Recovering Lost Updates

This shows all recovered WorldView cached updates

Connecting NSM r3.1 DSMs to an r11.1 MDB


Objectives

- In this section, we review how a Windows NSM 3.1 Distributed State Machine can connect to an r11.1 CORe (MDB) via wvdbt

- If you plan to use this concept as part of r11.1 Migration strategy, there are special consideration that should be taken into account.

- Support for this configuration is currently being clarified


Important Considerations

- NSM r3.1 agents can be managed by r11.1 Distributed State Machine- In r11.1 , policies such as caiW2kOs , caiLogA2, etc have

been updated to atp format. As a result of this, the wvc files have been changed.- For these agents, NSM 3.1 DSM will not create WorldView

objects unless the agent class is deleted and recreated from NSM 3.1 wvc files.- If this is done, then any 3.1 agents managed by an r11.1

DSM may have problems because policy files for these agents will not create WorldView objects- If r11.1 DSM does not share the same MDB, then this will

not be an issue


NSM 3.1 -> r11.1 wvdbt

NSM 3.1 DSM NSM r11.1 DSM

WVDBT

MDBCORe

Aws_dsm

Aws_wvgate

Agents


NSM 3.1 – atcatngrep.dll

- Steps to connect to WVDBT server from a remote Windows DSM are provided in NSM 3.1 document

- atcatngrep.dll must be renamed to catngrep.dll prior to executing wvrepsel –t option and starting awservices


NSM 3.1 Connecting to R11.1 CORe

- The following slide shows a NSM 3.1 DSM connecting to an r11.1 CORe (MDB)

-wvrepsel specifies wvdbt server as LOD1060 (an r11.1 server running wvdbt service)

-wvgethosts shows it can connect via tunnel


NSM 3.1 connecting to r11.1 CORe


Wvdbt r11.1

- This shows NSM 3.1 connection from previous slide is to r11.1 wvdbt


NSM 3.1 – DIA Protocol

- NSM 3.1 wvdbt connection uses port 7774 (not DIA 11502 since NSM 3.1 does not support DIA)

Firewall Considerations


Port Configuration

- If Agent Technology is configured to use DIA protocol, it will use DNA port 11502 to talk to WVDBT server

- DNA port can configured by updating dna.cfg file


Port Usage

DIA Protocol – 11502 is DNA RMI Port


Firewall Deployment

Client has a requirement to deploy Windows Distributed State Machine outside the firewall but wants to use a Central MDB which resides inside the firewall.

Firewall administration has concerns about SQL intrusion and will not open up SQL port. How can Distributed State Machine be configured to use a Central CORE without opening a SQL port?


Firewall

- Aws_dsm (wvPlugin) and aws_wvgate take about 3 RCB for each remote DSM Connection

Windows

Windows

MDBOORe

Aws_orb

aws_store

aws_snmp

aws_dsm

Aws_wvgate

Aws_orb

wvdbt

This may vary if non r11.1 agents are running as well

MaxRCBComputations for WVDBT

Connection


WV RCB Breakdown

WV RCB Breakdown

Process Name Count

aws_wvgate 2

aws_dsm 2

wvdbt 4 3 For each Remote Connection

startbpv 2

wvobjectcell 2

sevpropcom 5

cauwvdmn 2


MaxRcb

- Default MaxRcb value for r11.1 is 512- If you expect a large number DSMs to connect, change this default setting by updating the registry entry - If registry is defined, this value should not less than 512. There is no ceiling on the upper limit.- In NSM 3.1, the MaxRcb value cannot exceed 1024 but this restriction has been removed for r11.1


MaxRcb

- Each remote DSM, aws_wvgate and wvplugin use approx, 3 Rcb connections (based on out of the box policy loaded with r11.1 agents)

- If you are using additional policy (e.g., advanced IP policy, eHealth, etc.) this number will change

- In NSM 3.1 , each DSM took approx 8 Rcb connections. This was due to the fact a lot of DSM policy connected directly to the CORe


MaxRcb- Here MaxRcb is set to 2048. Default is 512


Questions and Answers

Any questions?Any questions?Email:

Bill Merrow

Yatin Dawada

Documents

WorldView Tunneling (WVDBT) Insights for Unicenter NSM r11.1