Our Scenario:
Network: Heterogeneous routed, switched, load-balanced network incorporating firewalls, VPNs and more than 10,000 ports, 2,500 devices and 7,500 users; 20 Web servers: Apache, Dual Xeon 2.4 GHz, 2 GB of RAM; four WebSphere servers: Sun Fire 6800s; two Database servers: Sun Fire E4900s running Oracle; SAN storage: Sun Storage Edge 6920; Client-side measurement: Microsoft Windows XP; 100 synthetic agents, each running 10 transactions (if applicable); 1,000 passive clients ( if applicable).
We installed all the management stations in our Syracuse University Real-World Labs® and tested IBM WebSphere applications running in our NWC Inc. business applications lab within our Green Bay, Wis., Real-World Labs®. For this test, we used WebSphere's default Plantstore and Petstore applications running on two F5 load-balanced Window 2000 boxes, each running the IBM version of Apache. We installed monitors in Green Bay on separate machines behind the firewall as well as on the WebSphere servers. These agents monitored our network devices, systems, Web servers and application servers. We also installed agents in our Syracuse lab to run robotic transactions and monitor our network infrastructure, tracking the critical network path leading to the applications in Green Bay. To do this, we ran robotic transactions through the WebSphere applications, and performed pings and SNMP gets on the network devices.
On top of this monitoring, we overlaid groupings that represented our two application services. This required that network devices and systems common to both application services be nested along with the monitors of application-specific WebSphere Beans to identify the availability of the application services.
Then we looked for ways to alert operations that one of the WebSphere application servers had failed. Because the servers were in a load-balanced pool, we didn't want the failure of one server to affect the status of the service reports being delivered to the business owners.