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

1. WorldView Tunneling (WVDBT) Insights for Unicenter NSM r11.1 Latest Revision September 11, 2006

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

3. 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

4. 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

5. 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

6. 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

7. Agent Technology - Install Since AT Manager Distributed State Machine Component is selected, SQL client is required during NSM Install

8. 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

9. 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

10. Windows Client • Here Linux Ingres CORe is accessed by Windows DSM via WVDBT

11. Linux Server • This shows Windows connection. Windows client address is 141.202.120.80

12. WV Tunnel – Linux Connection • Here Windows aws_dsm connects to Linux Ingres CORe

13. WV Tunnel – Windows Connection • Here aws_wvgate connects to a Windows WVDBT server

14. 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.

15. 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”

16. Wvdbt Install - Windows • This shows wvdbt service added to start automatically. It is dependent on aws_orb

17. 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

18. Execute wvrepsel -t • Here wvrepsel –t has failed because aws_orb was not started

19. Registry Entry

20. Distributed Services Bus (aws_orb) MDB CORE Network State Machine Domain Manager SNMP Gateway WorldView DSM Gateway WVDBT Object Store Wvdbt Connection to CORE Distributed State Machine

21. Gunners1 Distributed Services Bus (aws_orb) Common Object Repository Rocking2 WorldView DSM WVDBT Distributed Services Bus (aws_orb) Distributed State Machine

22. Re-Connection

23. 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

24. Lost Connection • This shows connection wvdbt server lost as the wvdbt is stopped

25. 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)

26. WorldView Update • Here aws_wvgate is unable to update CORe while wvdbt service is down. Requests are cached

27. WorldView Updates Lost Cache • Here you can see how the “Service Critical” status generated by Windows System Agent is cached – WinA3- SrvsInstCritical

28. Reconnection • Aws_wvgate automatically reconnects when wvdbt service is restarted

29. 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

30. Recovering Lost Updates This shows all recovered WorldView cached updates

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

32. 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

33. 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

34. NSM 3.1 -> r11.1 wvdbt NSM 3.1 DSM NSM r11.1 DSM Aws_dsm Aws_wvgate Agents WVDBT

35. 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

36. 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

37. NSM 3.1 connecting to r11.1 CORe

38. Wvdbt r11.1 • This shows NSM 3.1 connection from previous slide is to r11.1 wvdbt

39. NSM 3.1 – DIA Protocol • NSM 3.1 wvdbt connection uses port 7774 (not DIA 11502 since NSM 3.1 does not support DIA)

40. Firewall Considerations

41. 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

42. Port Usage DIA Protocol – 11502 is DNA RMI Port

43. 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?

44. MDB OORe Firewall • Aws_dsm (wvPlugin) and aws_wvgate take about 3 RCB for each remote DSM Connection Windows Windows 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

45. MaxRCBComputations for WVDBT Connection

46. WV RCB Breakdown

47. 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

48. 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

49. MaxRcb • Here MaxRcb is set to 2048. Default is 512

50. Questions and Answers Any questions? Email: Bill Merrow Yatin Dawada