DSM Scalability Considerations for Unicenter NSM r11

1
DSM Scalability Considerations for Unicenter NSM
r11

• Last Updated 12/13/2005

2
Objectives

• Understand issues affecting DSM performance
• Understand issues affecting scalability
• Consider architectural options
• Recommendations

3
Issues affecting DSM performance
4
Understand issues affecting DSM performance

• Hardware
• Local vs remote DSM(s)
• Cold start vs. warm start
• Electronic proximity to hosts
• Network configuration and congestion
• Number of hosts
• Number of managed objects
• Polling configuration

5
Hardware

• See Hardware Requirements in NSM r11
  Implementation Guide for latest guidance

6
Hardware

• Does hardware matter?
• 30,000 objects 2 subnets with 50 objects per
  host

7
Local vs remote DSM(s)

• For smaller implementations a local DSM on the
  MDB machine is OK
• For larger implementations, remote DSM(s) should
  be strongly considered

8
Local vs remote DSM(s)
9
Multiple Remote DSMs

• Multiple remote DSMs have a synergistic effect

10
Local vs remote DSM(s)

• Local and remote DSM not as strong

11
Cold start vs. warm start

• Set WarmStartyes option in AGENTWORKS_DIR\ser
  vices\config\atmanager.ini
• Warm start uses previously discovered objects
• Reduces MDB access time
• Reduces discovery process time
• Must still confirm status

12
Cold start vs. warm start

• Startup measured as time to DSM settling

DSM start complete
13
Cold start vs. warm start

• Startup elapsed times

14
Electronic proximity to hosts

• Standard best practice not more than 3 hops
• High performance LAN access to hosts and MDB
• Avoid WAN links

15
LAN Polling
16
Network configuration and congestion

• DSM should usually handle whole subnets
• Fast/stable path to MDB
• Network utilization
• Errors, timeouts, and retries
• Size counts

17
WAN Polling
18
Number of hosts

• Affects startup and first stage discovery
• Affects total DSM object population
• Affects DSM host configuration

19
Number of objects

• Each managed host may spawn dozens of objects
• Agents
• Watchers
• Split DSMs to keep number of objects constrained
• Split DSMs to keep electronically close

20
Polling configuration

• Polling interval
• Polling rate for r11 DSM sustained at up to 1,000
  polls/second (laboratory only)
• Speeds discovery (?)
• Not needed for status polling
• 10 to 20 minutes polling still best practice
• 50,000 poll-able objects at 10 minute polling
  interval is about 80 polls/second
• Timeouts are critical
• Assume timeout 10, retry 2 30 second delay
• DSM thread waits for reply or timeout on SNMPGET.
• IP policy makes extensive use of SNMPGET

21
Polling configuration

• Calculating polling rates
• Target no more than 50 utilization in polling
  interval
• 200/sec five minute interval is 300 seconds so
  do not attempt more than 30k polls in five minute
  interval (300 seconds X .50 X 200 polls per
  second) 60k objects polled every 10 minutes
• Configure aws_snmp MaxPollRate in atservices.ini

22
Issues affecting scalability
23
Issues affecting scalability

• Hardware
• What hardware is available?
• Can it support MDB DSM?
• Network
• How electronically close are managed objects?
• Is there capacity to handle polling and trap
  traffic?
• How reliable is the network?
• Geographic proximity
• Do managed objects exist on other side of WAN?
• Polling
• What are the polling requirements?

24
Issues affecting scalability

• Type of host activity
• Web server
• Application server
• Database server
• Batch server

25
Architectural options
26
Architectural Options

• Local DSM
• Fine for smaller shops
• Add remote DSMs as necessary
• Add remote DSMs to improve performance
• Use several smaller DSMs
• Closer to managed objects
• Faster startup
• More robust (not single point of failure)
• Reduces effect of an outage
• Bridged MDBs
• Distribute MDBs for better DSM access

27
Questions?