Customer X is running z/VM 5.3 on a z9 mainframe with 2 IFL engines. z/VM hosts a few SLES10 guests. One guest is running WAS 6.1. All data source connections are set to use a Hipersocket route to z/OS and z/DB2. At the start of the business day, all connection pool threads move from the internal Hipersockets interface to the external OSA interface. The guest stays pretty busy with a fairly DB heavy workload.
PMI shows that the pools are active and in use. Netstat confirms that all threads are apparently using the external route.
What the heck?
This one is a puzzler. z/VM and mainframe hardware can do some weird things with MAC forwarding and dynamic routing. The Linux network drivers are apparently somewhat aware of z/VM in SLES 10. It gets more odd because z/VM also implements OSPF for network failover. The same component that implements OSPF also has a connection ceiling that is typically set to INFINITE, but was set to 255 by Customer X.
So, two theories:
1) z/VM realizes that the virtual (e.g. Hipervisor) network is not the fastest and tells the Linux network drivers to go in the opposite direction where the OSA card will offload some of the TCP/IP load.
2) z/VM hits the connection cap and tells Linux to go in the opposite direction.
Naturally, none of these behaviors are documented.
Wednesday, February 25, 2009
Subscribe to:
Posts (Atom)