![]() |
|
| F E A T U R E | |
|
|
|
August 9, 1999 |
||||||||||||
|
|
How We Tested... Application Monitoring
Our test site at Syracuse University has a fairly typical, and fairly complex, application server farm. It provides a three-tier native client/server PeopleSoft application and seven-tier, Web-enabled access to the same PeopleSoft application services (see "Testing in Production" on page 42). Along with our WAN-connected labs, it gave us the perfect room to sample each product. Implementing products into this environment meant we had to deal with a firewall and long-distance management. Both stopped us in our tracks at times, as the products' various approaches required different points of access. A firewall protects the server farm, which runs on a Cisco Catalyst 5000 VLAN. The probes from Apptitude, Compuware and Exact Solutions need to permissively sniff traffic, so we had to get on that VLAN. We asked that all the traffic of the full-duplex 100-MB VLAN be mirrored to a port where we placed a 100-MB hub. This gave us access behind the firewall but not through it. Access through the firewall wasn't going to happen, so we needed the probe products to go around it, on a separate out-of-band management channel limited to access-management information. This wasn't much of a problem for Apptitude's Fast Ethernet Probe, which comes with a 10-MB management channel. Compuware's and Exact Solutions' probes by default don't install with a separate management channel, but their permissive drivers are bound within NT networking, so moving to an unaddressed interface and querying over a second NIC driver wasn't difficult. On the WAN we found that Apptitude didn't provide an Ethernet interface for monitoring; it ran over an existing DLCI. This was a pain, as our frame relay had only two 192.168 addresses, one assigned to each end. Point-to-point private circuit makes sense, right? It does, except this meant assigning another address and reconfiguring the routers to manage the probe. Both Compuware and Exact Solutions have Ethernet interfaces so this wasn't an issue. All the other products, whether passive desktop agents or those that actively refer transactions to database and application servers, only needed to be on subnets that were allowed to pass transactions through the firewall. To run transactions across the wide area, we set up NT machines in our San Mateo, Calif., lab, running pcAnywhere remote control. Installing on the desktop required pcAnywhere and a shared drive; INS's VitalSuite has a browser-based download, so it didn't need the shared drive. To get transactions to monitor, the probes just had to report on the live production traffic on the 100-MB hub. For the active agents, we set up predefined TCP/UDP port pings and trace route transactions. On FirstSense and VitalSuite we ran browser-based and native client PeopleSoft transactions.
|
|
|
|||||||||
|
PAGE: 1 I 2 I 3 I 4 I 5 I 6 I 7 I 8 I 9 I NEXT PAGE |
||||||||||||












