On Thursday, 09/11/2008 at 04:38 EDT, David Kreuter <[EMAIL PROTECTED]> wrote: > Alan and Chuckie won't like it but yes you can share an OSA OSD chpid on two > or more lpars. You can (sorry Chuckie) even use the same device triplet in > multiple LPARs. You can create quite a nice architecture with this.
Chuckie doesn't care if you share an OSA port. But that's because he's a rather quixotic individual, the result of being abducted by aliens at a young age. Alan, however, has only your best interests at heart. :-) I recommend against OSA port sharing (there is no longer a 1:1 relationship between ports and chpids, btw) except when building a clustered environment. In that case you would have VSWITCH1 on SystemA and VSWITCH1 on SystemB that go to the same network, and you administer them as a single entity. In this case it is shared by an expression of network, security, and general systems management *policy* rather than convenience. If the OSA "short circuits" between LPARs, it's ok since all of the sharing systems can be considered a single pseudo-host. In this case there is no desire or intent to filter or otherwise manage the data flow between LPARs. If you are building a multi-tier application environment, however, it is important that you NOT share an OSA when the traffic moves from one security domain (zone) to another and the receiving end is not protected by a firewall or other intrusion prevention/detection system (IPS/IDS). For example, let's say your z/VM system is hosting Websphere app servers and they need to get data from DB2 in another LPAR. Most security organizations define those as being in separate zones. I.e. "application zone" and "data zone". The packets will likely need to exit the box, go through a firewall, and then re-enter the DB2 LPAR. That would apply even if the DB2 server ran in a virtual machine in the same z/VM LPAR. If you have the CPU capacity and the acquiescence of your network security folks, you can use a virtual protection appliance. Every rule (except this one?) has an exception, so you may be able negotiate a shared OSA (or HiperSockets) if the target host has an acceptable IPS. Acceptable to whom, you ask? Your network security folks. In the race to deploy as fast as possible, it's easy to overlook the basics of network security, particularly if your security folks are not, ahem, "fully informed" of the sharing characteristics of z. > You cannot do link aggregation on a shared OSA. True. The LACP protocol requires that the controlling party at each end of the link know about ALL packets flowing on the port group. Where available, the VSWITCH uses hardware enforcement of this rule. Alan Altmark z/VM Development IBM Endicott
