I’ve been on customer site trying to advise about how to properly deploy the WebCenter Suite. A common comment always comes right off the bat: “I’ve seen the WebCenter Enterprise Deployment Guide, but I’m not sure about the VIPs / IPs distribution”.
So, the objective here is only to clarify what the picture below means. As you can see we have a pretty common scenario with a couple of SOA boxes and another set of WebCenter ones. Every single box has its own IP. IP1 for SOAHOST1, IP2 for SOAHOST2, and so on. The IPs position in the picture is a little bit misleading, since in some cases its ellipses touch individual managed servers, making you believe that it should be only associated to that specific managed server. Remember, IPs are for the whole box.
VIPs are commonly used for server migration purposes, and therefore should not be needed for managed servers. If a managed server fails, we should be able to bring another one up. However, there are a couple of exceptions: the AdminServer and SOA.
The SOAHOST1 box mentions 2 VIPs. VIP1 is associated to the AdminServer, which means that if the machine hosting the AdminServer fails, you should be able to bring up the AdminServer on SOAHOST2 with minimum hassle. Maintaining the same address so that the admin address referenced by OHS and by the managed servers does not change.
SOA servers are the other exception. WLS_SOA1 and WLS_SOA2 have independent VIPs. In the case of a SOA server failure, there could be an in-flight transactions that needs recovery. And the cleanest way of accomplishing it is to migrate the Transaction Recovery Service. There are two requirements though:
1. Only the same server can recover its own transactions, therefore VIPs are key here so we need to migrate the service to another machine.
2. And the transaction log records should be on shared file system – another important black spot on the docs - so that the failed-over server can access and recover them.
And finally, since SOA and AdminServer have independent failover requirements, they cannot share the same VIP.

To finalize, I’d like to thank Roy Sandjaja, from Oracle Development, that has helped me understand the whole picture. Cheers, mate!
Hope this helps.
So, the objective here is only to clarify what the picture below means. As you can see we have a pretty common scenario with a couple of SOA boxes and another set of WebCenter ones. Every single box has its own IP. IP1 for SOAHOST1, IP2 for SOAHOST2, and so on. The IPs position in the picture is a little bit misleading, since in some cases its ellipses touch individual managed servers, making you believe that it should be only associated to that specific managed server. Remember, IPs are for the whole box.
VIPs are commonly used for server migration purposes, and therefore should not be needed for managed servers. If a managed server fails, we should be able to bring another one up. However, there are a couple of exceptions: the AdminServer and SOA.
The SOAHOST1 box mentions 2 VIPs. VIP1 is associated to the AdminServer, which means that if the machine hosting the AdminServer fails, you should be able to bring up the AdminServer on SOAHOST2 with minimum hassle. Maintaining the same address so that the admin address referenced by OHS and by the managed servers does not change.
SOA servers are the other exception. WLS_SOA1 and WLS_SOA2 have independent VIPs. In the case of a SOA server failure, there could be an in-flight transactions that needs recovery. And the cleanest way of accomplishing it is to migrate the Transaction Recovery Service. There are two requirements though:
1. Only the same server can recover its own transactions, therefore VIPs are key here so we need to migrate the service to another machine.
2. And the transaction log records should be on shared file system – another important black spot on the docs - so that the failed-over server can access and recover them.
And finally, since SOA and AdminServer have independent failover requirements, they cannot share the same VIP.

To finalize, I’d like to thank Roy Sandjaja, from Oracle Development, that has helped me understand the whole picture. Cheers, mate!
Hope this helps.