Oracle9iAS Web Cache Administration and Deployment Guide Release 2.0.0 Part Number A90372-04 |
|
This chapter presents several scenarios for deploying Oracle Web Cache.
This chapter contains these topics:
Oracle Web Cache can be deployed on the same computer as the application Web server or on a separate computer.
Figure 3-1 shows Oracle Web Cache deployed on the same computer as the application Web server.
For this deployment, configure Oracle Web Cache with the host name of the application Web server.
Figure 3-2 shows Oracle Web Cache deployed on a different computer from the application Web server.
To configure this deployment:
In Figure 3-2, Oracle Web Cache is named www.server.com
, which was the name of the application Web server. The application Web server is renamed to www-internal.server.com
.
In addition to HTTP protocol requests, you can configure Oracle 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 Oracle Web Cache to listen for incoming requests on two ports, one for Secure Sockets Layer (SSL) requests and one for non-SSL requests. In addition, you can use a Layer 4 (L4) switch to pass requests to the appropriate listening port. An L4 switch operates at Layer 4, the Transport (or protocol) layer, of the Open Systems Interconnection (OSI) model. L4 switches determine where to send requests based on the protocol and port number.
Figure 3-3 shows an L4 switch passing both HTTP and HTTPS requests to Oracle Web Cache server www-internal.server1.com
.
To configure this deployment:
Figure 3-4 shows two Oracle Web Cache servers receiving requests. HTTP requests are served from server www-internal.server1.com
and HTTPS requests are served from server www-internal.server2.com
.
To configure this deployment:
For many applications, HTTPS is required for secure transactions that should 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 an L4 switch to pass all HTTP requests, typically port 80 traffic, to Oracle Web Cache, and forward HTTPS requests for secure pages to a particular application Web server. Figure 3-5 shows an L4 switch passing HTTP requests to Oracle Web Cache server www-internal.server1.com
and HTTPS requests to application Web server www-internal.server3.com
. Note that HTTPS requests could also be passed to www-internal.server2.com
.
Many of today's Web sites use a Load Balancer to balance the incoming requests among multiple Web servers. Instead, as shown in Figure 3-6, you can use Oracle Web Cache to distribute HTTP and HTTPS requests among two or more application Web servers.
To configure this deployment:
Many Web sites contain cacheable catalog content and non noncacheable secure and search content. For these Web sites, you can use Oracle Web Cache servers to cache content for just the portions of the Web site with the cacheable content. Figure 3-7 shows a Layer 7 (L7) switch passing catalog requests to Oracle Web Cache server www-internal.server1.com
and order entry and account requests to application Web servers www-internal.server2.com
and www-internal.server4.com
.
An L7 switch operates at Layer 7, the Application Layer layer, of the OSI model. L7 switches determine where to send requests based on URL content.
To configure this deployment:
In Figure 3-7, Oracle Web Cache server www-internal.server1.com
is configured to cache for application Web server www-internal.server3.com
.
To maintain performance during an application Web server failure, you can configure two Oracle Web Cache servers as a failover pair. Both Oracle Web Cache servers are configured to cache the same content. When both Oracle 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 3-8.
To configure this deployment:
You can deploy Oracle Web Cache inside or outside a firewall.
Figure 3-9 shows Oracle Web Cache positioned inside a firewall. Deploying Oracle 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 3-10 shows Oracle Web Cache positioned outside a firewall. With this deployment, the throughput burden is placed on Oracle Web Cache rather than the firewall. The firewall receives only requests that must go to the application Web servers. This deployment requires securing Oracle 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 Oracle Web Cache outside the DMZ.
Many Web sites have several data centers. For networks with a distributed topology, you can deploy Oracle Web Cache at each of the data centers.
Figure 3-11 shows a distributed topology in which Oracle Web Cache is distributed in offices in the United Kingdom, Japan, and the United States. Browsers make a request 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, the topology model, and the current load to pick an Oracle Web Cache server to satisfy the request. It then returns the IP address of the appropriate Oracle Web Cache server to the browser.
To configure this deployment:
Another distributed deployment solution is depicted in Figure 3-12. In this deployment, an Oracle Web Cache server is located in the United States office and another server is located in the Japan office. The application Web servers for both offices are located in the United States office, centralizing the data source to one geographic location.
To configure this deployment, configure each Oracle Web Cache server with the host names of the application Web servers for which it is caching documents. In Figure 3-12:
|
Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|