1 Reply Latest reply on Jun 25, 2009 2:20 PM by rmueller

    Web Cache configuration as reverse proxy


      I am trying to configure Web Cache as reverse proxy in front of an OAS farm.
      At some point, the documentation says that for using a single server you need to have 2 IP addresses and 2 hostnames in DNS assigned, which I have.
      Then Web Cache has to be installed (which I did, in standalone mode), and has to listen to both IP addresses - one for Infra requests (SSO) and the other for Portal, reports, etc.

      Question is, do I need 2 Web Cache instances for doing that? Or I just need to have the same instance listening to both ports, one for each IP address?

      If I need 2 Web Cache instances, should I install Web Cache twice, using different ORACLE_HOMEs?
      The Web Cache Manager allows selecting the instance, which means it can handle multiple instances. Will it be able to 'see' an instance from another ORACLE_HOME or the additional instance should be created in the same ORACLE_HOME?
      Subsequently, if the additional Web Cache instance has to /can be created in the same ORACLE_HOME, how do I create it?

      Any feedback is really appreciated,
        • 1. Re: Web Cache configuration as reverse proxy

          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.