Cisco Services Modules

Design Guide

This design guide describes how to deploy the The Cisco® Application Control Engine (Cisco ACE) by Cisco Systems® with the Oracle 10g Application Sever Suite. This guide was created through the collaborative efforts of Cisco and Oracle as a part of a larger effort to provied Cisco and Oracle solutions to the market. Additional design guides for other product combinations, and other related documents are available from Cisco and Oracle.

DOCUMENT PURPOSE

SUMMARY

• The network architecture meets all the functional requirements of the Oracle myPortal deployment architecture.

• The outer-based data center network architecture used in this document does not require source Network Address Translation (NAT) of any load-balanced traffic, resulting in ease of implementation and management.

• Bridge mode (transparent mode) implementation of the Cisco ACE allows ease of application deployment and management.

• Application health checking, persistence, and adjustable connection-timeout capabilities of the Cisco ACE help ensure high availability and optimized use of application resources.

• Although each major application component is presented in a separate tier in this document, multiple tiers can be easily merged into a single tier for a particular deployment, demonstrating the flexibility of the Cisco ACE for application deployments.

TERMS AND DEFINITIONS

Oracle 10g Application Server Suite

Cisco Application Control Engine

APPLICATION AND NETWORK ARCHITECTURE

Architecture Overview

• Desktop tier-This tier represents the clients on the Internet or intranet accessing the portal site. The client interface is provided through a Java-enabled Web browser. The desktop client downloads Java applets as needed. Client1 and Client2 in Figure 1 represent the desktop tier in this architecture.

Figure 1. Overall Application and Network Architecture

• Web tier-This tier represents the front-end (Web) environment that is directly accessed by external (Internet) and internal clients (corporate clients or other Oracle application products). The primary method used to access this tier is plaintext HTTP or SHTTP. In this architecture, the Web tier is represented by two network segments: portal and identity management (login).

The portal site (portal.ccc.com) function is provided by APPHOST1 and APPHOST2 in Figure 1. The traffic to the portal site is load balanced by the Cisco ACE using the virtual IP address 1 (VIP1). Webcache service and the Oracle HTTP Server (OHS) run on APPHOST servers. Portal servers also communicate with database servers.

The identity management (login) function is provided by IDMHOST1 and IDMHOST2 in Figure 1. The traffic to identity management services is load balanced by the Cisco ACE using VIP2. Several application-level services such as OHS, stateful switchover (SSO), etc. are running on IDM host(s). Identity management servers also communicate with Oracle Internet Directory (OID) services and database servers to complete login functions.

Details of the flows to APPHOSTs (portal) and IDMHOSTs (login) are covered in later sections in the document.

Note: Although portal and login functions are deployed in separate network segments in the document, they can be easily merged into a single network segment if needed. In addition, some architecture deployments also isolate Web and application functions in separate segments.

• Application tier-This tier represents OID servers OIDHOST1 and OIDHOST2, which are running Lightweight Directory Access Protocol (LDAP) services in this architecture. Internet clients in the desktop tier do not access OID services directly. Hosts in other tiers such as IDMHOSTs in the Web tier and database servers in the database tier access OID services. The traffic to the OID services is load balanced by the Cisco ACE using VIP3.

• Database tier-This tier contains database servers, which store all the data maintained by the myPortal application. In general, external clients do not communicate with database servers directly, but servers in the application tier and Web tier communicate with database servers in order to process certain client requests. Traffic to database servers is not load balanced by the Cisco ACE in this deployment, so database servers are not shown to be deployed behind the Cisco ACE. High availability and load balancing of the database is provided by the Oracle Resource Availability Confirmation (RAC) implementation. Hosts in this tier include APPDBHOST1 and APPDBHOST2, and INFRADBHost1, and INFRADBHost2.

Application Flows

APPHOST (Portal) Flows

The client on the Internet accesses http://portal.ccc.com (port 80) or https://portal.ccc.com (port 443), which is configured as VIP1: 10.10.164.21 as on the Cisco ACE.

The Cisco ACE load balances the request to one of the available Webcache servers running on APPHOST1 or APPHOST2. When the engine load balances the request, it translates the destination TCP port (from 80 or 443) to port 7777 (Webcache server listening port).

Session persistence (stickiness) based on client source IP address or HTTP cookies are recommended to be configured on the Cisco ACE for this flow.

This flow is marked as "1" in light green in Figure 2.

Figure 2. APPHOST (portal) Flows

For this topology both the Webcache server and OHS are running on the same APPHOST server. The Webcache server connects to the OHS on TCP port 7778.

Normally, the way the Webcache server is configured (loopback address), this flow stays internal to the APPHOST server and does not traverse over the network.

This flow does not get load balanced in this deployment.

This flow is marked as "2" in black in Figure 2.

APPHOST1 and APPHOST2 make database queries to the database server (APPDBHOST1 or APPDBHOST2). For this topology this connection is established on the destination TCP port 1521 (SQL*NET or NET8 as referred to by Oracle) running on the database servers. Some deployments may have this port customized to another TCP port.

This request traverses the network and is routed through the Cisco ACE and the router on the network.

This flow is marked as "3" in pink in Figure 2.

The Oracle Application Server Portal Repository (database server in this topology) sends invalidation messages to the Webcache server when content that is cached in the Oracle Application Server Webcache becomes stale.

Webcache servers are listening on TCP port 9401 to receive this message.

This request is an HTTP request made over TCP port 9401 to the virtual IP address 10.10.164.21 on the Cisco ACE by the APPDBHosts.

The Cisco ACE load balances the request to one of the available Webcache servers running on APPHOST1 or APPHOST2.

This flow is marked as "4" in red in Figure 2.

This flow is similar to flow 1 except that it is initiated by database hosts APPDBHOST1 and APPDBHOST2. In a multiple middle tier deployment where a load balancer is used, all Java Portal Development Kit (JPDK) applications must be reregistered with the load-balancer router URL.

The database host (APPDBHOST 1 or APPDBHOST2) can access the portal as http://portal.ccc.com/<webApp>/providers/<providername> (port 80), where portal.ccc.com is configured as VIP1: 10.10.164.21on the Cisco ACE.

The Cisco ACE load balances the request to one of the available application hosts-APPHOST1 or APPHOST2. When the Cisco ACE load balances the request, it translates the destination TCP port (from 80 or 443) to port 7777 (APPhost listening port).

Persistence or stickiness based on client source IP address or HTTP cookies is recommended to be configured on the Cisco ACE for this flow.

This flow is marked as "5" in light green in Figure 2.

IDMHOST (Login) Flows

Clients (on the Internet) are redirected to identity management as http://login.ccc.com (port 80) or https://logic.ccc.com (port 443) if they are not already authenticated. This connection is made to VIP2: 10.10.165.167 on the Cisco ACE.

The Cisco ACE load balances the request to one of the available identity management hosts (IDMHOST1 or IDMHOST2). When the Cisco ACE load balances the request, it translates the destination TCP port (from 80 or 443) to port 7777 (IDMHOST listening port).

Persistence (stickiness) based on client source IP address or HTTP cookies are recommended to be configured on the Cisco ACE for this flow.

This flow is marked as "6" in red in Figure 3.

Figure 3. IDMHOST (login) Flows

Identity management hosts (IDMHOST 1 or IDMHOST2) access OID services as oid.ccc.com, which is configured as VIP3: 10.10.165.183 on the Cisco ACE. This request is made as an LDAP request over TCP port 389 (or optionally 636 as secure LDAP).

The Cisco ACE load balances the request to one of the available OID hosts (OIDHOST1 or OIDHOST2).

This flow is marked as "7" in cyan in Figure 3.

IDMHOST1 and IDMHOST2 make database queries to the database server (INFRADBHost1 or INFRADBHost2). For this topology the connection is established on the destination TCP port 1521 (SQL*NET or NET8 as referred to by Oracle) running on the database servers. Some deployment may have this port customized to another TCP port.

This request traverses the network and is routed through the Cisco ACE and router on the network.

This flow is marked as "8" in light green in Figure 3.

OIDhost (LDAP) Flows

Database hosts (INFRADBHost 1 or INFRADBHost2) access OID services as oid.ccc.com, which is configured as VIP3: 10.10.165.183 on the Cisco ACE. This request is made as an LDAP request over TCP port 389 (or optionally 636 as secure LDAP).

The Cisco ACE load balances the request to one of the available OID hosts (OIDHOST1 or OIDHOST2).

This flow is marked as "9" in light green in Figure 4.

Figure 4. OIDHOST (LDAP) Flows

OIDhost1 and OIDhost2 make database queries to the database server (INFRADBHost1 or INFRADBHost2). For this topology this connection is established on the destination TCP port 1521 (SQL*NET or NET8 as referred to by Oracle) running on the database servers. Some deployments may have this port customized to another TCP port.

This request traverses the network and may be routed through the Cisco ACE and router on the network.

This flow is marked as "10" in pink in Figure 4.

NETWORK DESIGN AND CONFIGURATION

Network Topology and Design Features

Figure 5. Detailed Network Topology

• In this network design, the Cisco ACE module is deployed in bridge mode, which is a simple deployment model.

• In this mode the Cisco ACE acts as a bridge between two VLANs and performs load balancing for traffic destined for the VIP address.

• Each VLAN pair is configured on the switch, but only the client-side VLAN has an IP address on the upstream router.

• The server default gateway is configured to point to the upstream router (Hot Standby Router Protocol [HSRP]) IP address for each client-side VLAN.

• Direct server access is possible if security policy allows.

• Each functional group of servers is deployed onto its own IP subnet.

• This segmentation provides logical grouping for similar functions and provides easy future expansion.

• Access lists on the upstream router permit wanted traffic to reach the Cisco ACE and servers directly.

• Access lists are configured on the upstream router to prevent direct access to database servers.

• The Cisco ACE module access lists are configured to allow access to the VIP on application ports.

• The Cisco ACE translates traffic that hits VIP1 and VIP2 on port 80 or 443 to the application port (7777).

• SSL traffic (port 443) is terminated on the Cisco ACE module, which sends cleartext traffic to application servers on the Webcache services port (7777).

• The client's source IP address is preserved in this transaction.

• By default, the Cisco ACE can handle up to 1000 SSL transactions per second (tps). For additional performance requirements, additional licenses need to be installed on the Cisco ACE.

Server Configuration

Table 1. Server Information

Note: The external listening ports listed in Table 1 are summarized for only the flows included in this document. In addition, each application server may have other ports used for administrative access. Those ports also need to be allowed appropriately in the access-list configuration. Refer to Oracle documentation for further details.

Oracle 10g Application Server Configuration

Router Configuration

Upstream Router (MSFC) Configuration Steps

Step 1. Add Cisco ACE VLANs and database server VLAN.

For this topology six Cisco ACE VLANs and one database server VLAN (total 7) need to be added to the MSFC as follows:

Note: Name definition is for description purposes only and can be configured based on an organization's naming convention.

Step 2. Permit VLAN traffic to Cisco ACE

The ACE will not accept VLAN traffic unless Cisco Catalyst 6509E switch is specifically configured to allow VLANs to access the ACE module. By not allowing all VLANs to access ACE, broadcast storms on non-ACE VLANs have no effect to the ACE. For this deployment, the Cisco ACE is installed in slot 4 in the Cisco Catalyst 6509E chassis. The following configuration needs to be added to allow Cisco ACE-specific VLAN traffic to be directed toward the Cisco ACE:

Step 3. Configure the switched virtual interface (SVI) (interface VLAN).

The SVI (interface VLAN) configuration defines the Layer 3 instance on the router (MSFC). For this deployment, four SVIs need to be configured: three Cisco ACE client-side VLAN SVIs and one database server-side VLAN.

The Cisco ACE client-side VLAN SVI configuration follows:

Note: This IP address serves as the default gateway for APPHOST servers and for the Cisco ACE. In a redundant design, this IP address is configured as an HSRP address. Refer to the Cisco HSRP configuration guide for an example: http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094afd.shtml#topic1

Note: This IP address serves as the default gateway for IDMHOST servers and for the Cisco ACE. In a redundant design, this IP address is configured as an HSRP address. Refer to the Cisco HSRP configuration guide for an example: http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094afd.shtml#topic1

Note: This IP address serves as the default gateway for OIDHOST servers and for the Cisco ACE. In a redundant design, this IP address is configured as an HSRP address. Refer to the Cisco HSRP configuration guide for an example: http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094afd.shtml#topic1

The database server VLAN SVI configuration follows:

Note: This IP address serves as the default gateway for database servers. In a redundant design, this IP address is configured as an HSRP address. Refer to the Cisco HSRP configuration guide for an example: http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094afd.shtml#topic1

Cisco Application Control Engine Configuration

Table 2. Cisco ACE

Cisco ACE Configuration Step

Step 1. Management access configuration

Step 2: Probe configuration

Step 3: Rserver configuration

Step 4: Server farm configuration

Step 5: SSL termination configuration

The syntax to generate the key on the Cisco ACE follows:

The syntax to import the key to the Cisco ACE follows:

The CSR can either be generated externally or on the Cisco ACE. The following are sample steps that show how to generate CSR on the Cisco ACE:

Configure CSR parameters on the Cisco ACE:

Generate CSR using key and CSR parameters:

The syntax to import the certificate to the Cisco ACE follows:

The chain consists of the certificates in the chain group, plus the configured certificate.

Step 6: Session persistence (sticky) configuration

Step 7: Server Load-Balancing Configuration

Step 8: Bridge mode configuration

An access control list (ACL) must be configured on every interface in order to permit connections. Otherwise, the Cisco ACE denies all traffic on the interface. For this deployment, two access lists named PERMIT_ALL are configured to permit IP and ICMP traffic on interface VLANs. The access list named PERMIT_ALL is assigned for security policies on interface VLAN 25, VLAN 29, and VLAN 31 to allow direct access to real servers; the same access list is also assigned for security policies on interface VLAN 26, VLAN 30, and VLAN 32 in order to permit traffic between real servers and also to access other networks from the real servers. The following configuration permits all IP and ICMP traffic on desired interface VLANs, but Cisco ACE can be easily configured to filter incoming/outgoing traffic on the interface VLANs based on criteria such as source address, destination address, protocol, protocol specific parameters, and so on if required by the Customers.

For bridge mode configuration, both client- and server-side VLANs need to be configured. Both VLAN interfaces share a common bridge group. In addition, access lists and a load-balancing service policy are also applied at the interface VLANs.

The following configuration shows the interface VLAN configurations for this deployment, shown in Figure 5:

BVI configuration defines the Layer 3 instance of the bridge group. Its configuration allows the bridging of traffic between the two VLANs. The interface number is the same as bridge group defined in step 2. The following configuration shows the BVI configuration for this deployment:

Step 9: Default gateway configuration