Release 2 (9.0.2)
Part Number A95404-02
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle9iAS Web Cache Administration and Deployment Guide Release 2 (9.0.2) Part Number A95404-02 |
|
|
Note: Many of the deployment scenarios described in this chapter can use a cache cluster in place of one Oracle9iAS Web Cache server. |
This chapter presents several high-level scenarios for deploying Oracle9iAS Web Cache.
This chapter contains these topics:
Oracle9iAS Web Cache can be deployed on the same computer as the application Web server or on a separate computer.
Figure 4-1 shows Oracle9iAS Web Cache deployed on the same computer as the application Web server.
For this deployment, configure Oracle9iAS Web Cache with application Web server settings and www.server.com site settings.
For optimal performance, Oracle Corporation recommends deploying Oracle9iAS Web Cache on a dedicated, fast two-CPU computers with lots of memory. Figure 4-2 shows Oracle9iAS Web Cache deployed on a different computer from the application Web server.
To configure this deployment:
www.server.com.
In Figure 4-2, Oracle9iAS Web Cache is named www.server.com, which was the name of the application Web server. The application Web server is renamed to server-host.
server1-host
www.server.com
In configurations with a Load Balancer, register the IP address of the Load Balancer rather than the Oracle9iAS Web Cache server with the Web site's domain name. See "Load Balancing Requests Among Application Web Servers" for more information about deployments with a Load Balancer.
Note:
Many of today's Web sites use a Load Balancer to balance the incoming requests among multiple application Web servers. Instead, as shown in Figure 4-3, you can use Oracle9iAS Web Cache to distribute requests among two or more application Web servers.
To configure this deployment:
www.server.com.
To maintain performance during an application Web server failure, you can configure two Oracle9iAS Web Cache servers as a failover pair. Both Oracle9iAS Web Cache servers are configured to cache the same content. When both Oracle9iAS Web Cache servers are running, a Load Balancer distributes the load among both servers. If one server fails, the other server receives and processes all incoming requests. This deployment is depicted in Figure 4-4.
To configure this deployment:
www.server.com.
webche1-host and webche2-host.
Many Web sites contain cacheable public content and non-cacheable content. For these Web sites, you can use Oracle9iAS Web Cache servers to cache content for just the portions of the Web site with the cacheable content. Figure 4-5 shows a Layer 7 (L7) switch passing catalog requests to Oracle9iAS Web Cache server webche-host and order entry and account requests to application Web servers server1-host, server2-host, and server3-host. An L7 switch operates at Layer 7, the Application Layer layer, of the Open Systems Interconnection (OSI) model. L7 switches determine where to send requests based on URL content.
|
See Also:
|
To configure this deployment:
www.server.com.
webche-host.
webche-host with the following:
In addition to HTTP protocol requests, you can configure Oracle9iAS Web Cache to cache documents for HTTPS protocol requests. HTTPS requests are typically for secure pages. For an environment with cacheable HTTP and HTTPS requests, you can configure Oracle9iAS Web Cache to listen for incoming requests on two ports, one for HTTPS requests and one for HTTP requests. Typically, HTTP uses port 80 and HTTPS uses port 443. A Load Balancer can be configured to pass requests to the appropriate listening port.
You can also configure Oracle9iAS Web Cache to send traffic to the application Web server through an HTTP or HTTPS listening port.
Figure 4-6 shows a Load Balancer passing both HTTP and HTTPS requests to Oracle9iAS Web Cache server webche-host.
To configure this deployment:
www.server.com.
webche-host.
webche-host with the following:
Figure 4-7 shows two Oracle9iAS Web Cache servers receiving requests. HTTP requests are served from server webche1-host and HTTPS requests are served from server webche2-host. Oracle9iAS Web Cache server webche1-host sends HTTP requests to application Web servers server1-host and server2-host. Oracle9iAS Web Cache server webche2-host sends HTTPS requests to application Web servers server2-host and server3-host.
To configure this deployment:
www.server.com.
webche1-host and webche2-host.
webche1-host with the following:
webche2-host with the following:
For many applications, HTTPS is required for secure transactions that should not be cached. For example, purchasing pages on an e-commerce site that require credit card information should not be cached. For this type of Web site, you can use a Load Balancer to pass all HTTP requests to Oracle9iAS Web Cache, and forward HTTPS requests for secure pages to a particular application Web server. Figure 4-8 shows a Load Balancer passing HTTP requests to Oracle9iAS Web Cache server webche-host and HTTPS requests to application Web server server2-host. Note that HTTPS requests could also be passed to server1-host.
To cache content for multiple internal or external Web sites, you can configure Oracle9iAS Web Cache to cache content for a virtual host site, and cache and assemble HTML fragments for Edge Side Includes (ESI) <esi:include> requests from an ESI provider site.
This section depicts the following deployments:
Figure 4-9 shows an internal virtual host deployment. It shows Oracle9iAS Web Cache server webche-host serving content on behalf of internal virtual host sites www.site1.company.com and www.site2.company.com.
To configure this deployment:
www.site1.company.com and www.site2.company.com.
webche-host.
webche-host with the following:
Figure 4-10 shows an internal ESI provider site deployment. It shows Oracle9iAS Web Cache server webche-host assembling ESI content from internal ESI provider sites www.providersite1.com and www.providersite2.com. Application Web server server-host uses a portal application to create a template page and sends it back to webche-host for assembly. webche-host includes ESI fragments for the template page from www.providersite1.com and Oracle9iAS Web Cache server webcache-providerhost, which is caching content for www.providersite2.com.
To configure this deployment:
www.server.com.
webche-host.
webche-host with the following:
webche-providerhost with the following.
provider2-host as the application Web server
www.providersite2.com as an ESI provider site mapped to provider2-host
"Configuring an ESI Cache Hierarchy" for more details about this configuration
See Also:
Many virtual host sites and ESI provider sites are likely to be connected over the Internet protected by a firewall and accessible through a proxy server, as shown in Figure 4-11 and Figure 4-12. For these types of sites, you configure Oracle9iAS Web Cache with proxy server settings rather than application Web server settings.
To increase the availability and capacity of a Web site, you can configure a cache cluster consisting of two or more Oracle9iAS Web Cache servers. Cache clusters support failure detection and failover of Oracle9iAS Web Cache servers. If a Oracle9iAS Web Cache server fails, other members of the cache cluster detect the failure and take over ownership of the cached content of the failed cluster member. Oracle9iAS Web Cache maintains a virtual single cache of content despite a cache failure.
As Figure 4-13 shows, a Load Balancer distributes the requests among the cluster members. The cache cluster members process the incoming requests.
To configure this deployment:
www.server.com.
Note that many of the deployment scenarios described in this chapter can use a cache cluster in place of one Oracle9iAS Web Cache server.
You can deploy Oracle9iAS Web Cache inside or outside a firewall.
Figure 4-14 shows Oracle9iAS Web Cache positioned inside a firewall. Deploying Oracle9iAS Web Cache inside a firewall ensures that HTTP traffic enters the Demilitarized Zone (DMZ), but only authorized traffic from the application Web servers can directly interact with the database.
Figure 4-15 shows Oracle9iAS Web Cache positioned outside a firewall. With this deployment, the throughput burden is placed on Oracle9iAS Web Cache rather than the firewall. The firewall receives only requests that must go to the application Web servers. This deployment requires securing Oracle9iAS Web Cache from intruders.
Security experts disagree about whether caches should be placed outside the DMZ. Oracle Corporation recommends that you check your company's policy before deploying Oracle9iAS Web Cache outside the DMZ.
|
See Also:
"Using Oracle9iAS Web Cache to Support Multiple Sites" for an example of an ESI cache hierarchy |
Many Web sites have several data centers. For networks with a distributed topology, you can deploy Oracle9iAS Web Cache at each of the data centers in a distributed cache hierarchy. Figure 4-16 shows a distributed topology in which Oracle9iAS Web Cache is distributed in offices in the United States and Japan. The application Web server is located in the United States office, centralizing the data source to one geographic location. The central cache in United States caches content for an application Web server, and the remote cache in Japan caches content from the central cache.
Browsers make requests to local DNS servers to resolve www.server.com. The local DNS server is routed to the authoritative DNS server www.server.com. The authoritative DNS server uses the IP address of the browser to pick the closest Oracle9iAS Web Cache server to satisfy the request. It then returns the IP address of the appropriate Oracle9iAS Web Cache server to the browser.
To configure this deployment:
www.server.com.
us.webche-host with the following:
jp.webche-host with the following.
us.webche-host as the application Web server
www.server.com as a virtual host site mapped to us.webche-host
"Configuring a Distributed Cache Hierarchy" for more details about this configuration
See Also:
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|