This content has been marked as final. Show 1 reply
I have this working...its not easy to get it all working properly it took hours on the phone with support; but it works...for the most part like a charm.
Here's the setup that works
One machine call it PRDRP (WC running as a load balancer - standalone webcache with the patch<<very important that allows it to act as a reverse proxy) it sits on the outer dmz with three ip addresses on three hardware interfaces (one for the machine, one for sso, one for portal)
Another machine call it PRDMT_OUTSIDE, its the outside middle tier, sits in the same dmz as PRDRP
Another machine call it PRDMT_INSIDE, it sits on an secondary dmz
Finally PRDINFRA, OID/Metadata infrastructure machine sitting on the secondary dmz
PRDMT_OUTSIDE has a webcache that connects to PRDMT_INSIDE both in the cache cluster; both acting as invalidator caches...basically they tell each other about page changes, but don't share pages
I followed two guides to get this setup...Oracle Application Server Enterprise Deployment - Configuring Reverse Proxy for Oracle AS and OracleAS Single sign-on; I started here with just PRDMT_INSIDE, PRDINFRA AND PRDRP; I then added PRDMT_OUTSIDE using metalink doc 392021.1...alone with a ton of help from support.
The IP address on PRDRP are mapped to our inside domain, sso points to the PRDINFRA box, and portal points to PRDMT_OUTSIDE (for requests that come from the internet) and portal points to PRDMT_INSIDE for requests that come from our inside domain.
So the short answer is if you want to hit the portal from the outside, then YES two middle tiers with invalidation caching and one PRDRP (my example) is the way to go; if you only want to hit it from the inside, then no...you can get away with a (my example) PRDINFRA, PRDMT_INSIDE, PRDRP...one PRDRP webcache running as a reverse proxy, it loadbalances and forwards IP traffic. I'd suggest using separate machines, vs. trying to pack all this on one box...its hard enough to get it to work with separate machines.