|
|
This appendix describes system capability information such as the maximum number of users, VPI/VCIs, and other Cisco 6100 Series sysstem capabilities that are supported by ViewRunner for HP OpenView for DOH and Direct Connect configurations.
Table A-1 describes the capacities for the Cisco 6100 Series system found in Release 3.0.
| Capability | Capacity |
|---|---|
Subscribers per Cisco 6100 Series system | 400 |
VCs per subscriber | 4 |
Subscriber-side virtual channels per Cisco 6100 Series system (locally attached) | 1600 |
Subtended subscriber VCCs1 (each subtending port) | 4,000 |
Network-side VCs2 per Cisco 6100 Series system | 12,400 |
Network-side VPs3 per Cisco 6100 Series system | 284 |
CAP ATU-C modem ports per Cisco 6100 Series system | 64 |
LIM ports per Cisco 6100 Series system | 400 |
POTS ports per Cisco 6100 Series system | 400 |
Physical pools per Cisco 6100 Series system | 2 |
Logical pools per Cisco 6100 Series system | 6 (3 in each physical pool) |
Subscribers supported per network (WAN) connection | 2800 |
Subtended chassis supported per network | 7 |
VPI/VCI per Cisco 6100 Series system | 3000 |
In-band management channels per Cisco 6100 Series system | 1 |
Table A-2 describes the capacities that ViewRunner supports for a DOH configuration using the Cisco 6100 Series system.
| Capability | Capacity |
|---|---|
Subscribers per Cisco 6100 Series system | 64 subscribers using ATU-C modules |
Virtual circuits per subscriber | 4 |
Subscriber-side virtual circuits per Cisco 6100 Series system | 4 |
ATU-C modem ports per Cisco 6100 Series system (CAP or DMT-2) | 64 |
STU-C modem ports per Cisco 6100 Series system | 128 |
LIM ports per Cisco 6100 Series system | 88 |
POTS ports per Cisco 6100 Series system | 88 |
This section details the recommended hardware configuration for ViewRunner for HP OpenView Release 3.0. As with all hardware, memory, and data recommendations, the customer's actual requirements might vary from the recommendations based on number of users, other processes being executed on the workstation(s), network configurations, and so on. These recommendations should be considered as guidelines rather than as hard and fast rules for configuration.
ViewRunner for HP OpenView 3.0 depends on three specific third-party software packages.
ViewRunner for HP OpenView 3.0 is a scalable, client/server application that can be run on a variety of Sun UltraSPARC hardware. Several variables affect size of the system required, including the number of Cisco 6100 Series systems that are managed (number of objects), the number of simultaneous operator logins and map privileges (read-only and read-write), trap throughput generated by the network, and the throughput of the network between the server and the clients.
For small networks of fewer than 100 Cisco 6100 Series systems with a small number of operators (fewer than five), a single Sun UltraSPARC 1/2/10/30/60 workstation should be sufficient to manage the entire network. For somewhat larger networks of 200 or 250 nodes with up to 15 operators, a multiprocessor Sun UltraSPARC 2/60/250/450 should be used as the server. Ideally, as the number of operators increases, client workstations should be added to offload computing requirements from the server. Each Sun UltraSPARC 1/2/10/30/60/250 client workstation should be able to support up to five operators. Multiprocessor Sun UltraSPARC 2/60/250/450 client workstations should be able to handle up to 10 operators.
The number of operator logins also affects server sizing, because of the additional Oracle connections that are required. Each operator requires one Oracle connection per client session (that is, one for ViewMap and one for each View LoopRunner session that is running). A two-CPU system should be able to handle server-side connections for up to 15 operators, and a four-CPU system should be able to handle up to 30 operators.
Larger networks of more than 250 nodes with more operators require an Enterprise-class Sun UltraSPARC. Sun Ultra Enterprise 450 with 4 processors should be capable of managing 300 nodes with up to 30 operator logins, with the associated external client workstations deployed to handle that number of operators.
Table A-3 shows the physical memory required to run the server applications.
| Process | Number of Instances | Memory Required |
|---|---|---|
View Process Monitor (vrProcessMon) | 1 | 10 MB |
View Alarm Formatter (vrAlarmFormatter) | 1 | 10 MB |
View Data Collector (vrDataCollect) | 1 | 7 MB |
View Network Monitor (vrNetMon) | 1 per 100 Cisco 6100 Series systems | 32 MB |
View Alarm Synchronizer (vrAlarmSync) | varies | 5 MB |
Entry Network Node Manager | 1 | 32 MB |
Full Network Node Manager | 1 | 64 MB |
Therefore, the ViewRunner servers require 64 MB to 128 MB of RAM for networks up to 300 nodes, plus an additional 32 MB to 64 MB of RAM for HP OpenView. The Solaris 2.5.1 operating system is assumed to require an additional 32 MB, depending on the installation.
The Oracle7 system is optimized for 512 MB of RAM per CPU but in general requires that the system global area be entirely contained in physical memory for optimum performance. Where possible, the entire database should fit in memory as well, but this can be cost prohibitive. Therefore, a target of 50% of the database size in physical memory is recommended.
Based on the defaults provided in the ViewRunner 3.0.0 server installation package, a small network would need approximately 400 MB of disk space for the database, including 32 MB of system global area. This translates to a requirement of 32 MB to 400 MB of RAM for Oracle.
A medium network would require 1.2 GB of disk space, including 64 MB of system global area. A large network would require 3.8 GB of disk space and 128 MB of system global area. The target memory size for the medium network for Oracle would be at least 640 MB. Rounding up and accounting for the optimal 512 MB of RAM per CPU, the medium network should have a dual-processor system with 1 GB of RAM. The large network should have at least four processors, and 2 GB of RAM. If more processors are used, 512 MB of RAM should be added per CPU.
Table A-4 shows the physical memory required to run the client applications.
| Process | Number of Instances | Memory Required |
|---|---|---|
ovw | 1 | 10 MB |
xnmevents | 1 | 8 MB |
ipmap | 1 | 7 MB |
ovwnavigator | 1 | 4 MB |
ViewMap | 1 | 16 MB |
View LoopRunner (viewLoopRunner) | varies | 17 MB |
View Admin (viewAdmin) | 0 to 1 | 10 MB |
To start HP OpenView with ViewMap enabled requires approximately 55 MB, not including the operating system or the windowing system requirements. Each View LoopRunner instance requires an additional 17 MB of RAM, and View Admin requires 10 MB. Other HP OpenView utilities use additional resources if they are executed. Assuming that each operator has two concurrent View LoopRunner sessions open at all times, each logged-in operator requires approximately 89 MB of memory. Five operators on a single-CPU UltraSPARC requires 512 MB of memory to keep the majority of the process space in RAM.
Disk space requirements are dependent on four factors.
The ViewRunner server and client packages require approximately 70 MB of disk space each. If both are installed on the same workstation, as in small network configurations, they do not have to be on the same file system. OpenView requires approximately 200 MB of disk space, 150 MB of which is typically in the /opt file system, and 50 MB of which is typically in the /var file system.
 |
Note Installation of the required patches results in the copying of approximately 90 MB of data to the /system directory. Make sure there is sufficient space in the /file system to handle this. |
The Oracle7 installation requires 30 MB or more of disk space. The small database configuration requires an additional 400 MB. A medium configuration requires 1.2 GB, and a large configuration requires 3.8 GB. For best performance and reliability, the database, indices, redo logs, control files, and so on, should be distributed (and stripped) across multiple disk drives. Oracle disk requirements are very complex and are beyond the scope of what Cisco can recommend. An experienced database administrator is the best source for recommendations as to the distribution of the database across available disks.
ViewRunner maintains log files for each server process. Each process has an associated trace level that dictates how much information is written to these logs. At the highest trace level, file sizes can reach into the hundreds of megabytes within just a few minutes. Normally, the servers are executed at the lowest trace level. Because files growing without bound could cause space problems, you can specify a threshold size in the vrTrace utility to truncate the log file size when it reaches that threshold. In addition, the root cron tab contains a script that, when used, automatically purges old log files (those not currently in use) weekly.
Finally, swap space should be configured to three times the physical memory size.
Table A-5 gives guidelines for selecting a system for your network size and number of operators. However, no two networks perform identically, and user's tolerance to performance degradation is not something Cisco can predict. Therefore, these are general guidelines.
| Network Size | Network Nodes | Local Client Sessions | Total Client Sessions | Server Platform | CPUs | RAM | Disk |
|---|---|---|---|---|---|---|---|
Small | < 100 | Up to 5 | Up to 10 | Ultra 1/10/30 | 1 | 256 MB to 512 MB | 2.1 GB to 4.3 GB |
Medium | < 500 | Up to 5 | 10 to 30 | Ultra 2/60/250/450 | 2 to 4 | 512 MB to 1 GB | 4.3 GB + optional |
Large | < 1000 | Up to 5 | < 30 | Ultra 450/3000/+ | < 4 | 2 GB+ (512 MB per CPU) | 4.3 GB + optional |
|
Note ViewRunner installation scripts allow the selection of small, medium, and large installation configurations. |
For additional information, there are a number of Oracle performance tuning guides available. Hewlett Packard also includes a scalability guide in the documentation set for the HP OpenView Network Node Manager.
Posted: Thu Mar 2 10:24:05 PST 2000
Copyright 1989 - 2000©Cisco Systems Inc.