Oracle® Beehive Deployment Guide Release 1 (1.4) Part Number E13795-02 |
|
|
View PDF |
Oracle Beehive provides a flexible system deployment model that supports a variety of configurations. This section provides high-level details on the following main deployment configurations:
Oracle Beehive can be deployed on a single computer. In this case, the system can leverage a single Oracle Database instance located on the same computer, as illustrated by Figure 7-1, "Oracle Beehive and Oracle Database Deployed on a Single Computer", or it may leverage an Oracle Database instance that resides on another computer, as illustrated by Figure 7-2, "Oracle Beehive and Oracle Database Deployed on Different Computers". However, the latter case is more likely and, in fact, strongly recommended. The system can also leverage a database cluster, residing among several other computers, using Oracle Real Application Clusters (Oracle RAC).
Figure 7-1 Oracle Beehive and Oracle Database Deployed on a Single Computer
Additionally, Oracle Beehive provides all required user directory components so it can function as an independent system. It can also integrate with one or more external LDAP- based corporate directories such as Oracle Internet Directory or Microsoft Active Directory Server.
Figure 7-2 Oracle Beehive and Oracle Database Deployed on Different Computers
Deploying Oracle Beehive on a single computer is suitable for test environments, development environments, and small production environments. Due to the lack of its failover capabilities, this deployment scenario is unsuitable in cases where high levels of guaranteed services are required.
Oracle Beehive supports deployments where multiple Oracle Beehive server instances are distributed across multiple computers. In this scenario, each computer hosts one Oracle Beehive instance, which can be accessed through load balancing routers (LBRs).
Each instance runs all available services provided with Oracle Beehive. For example, if you have five computers, each with an Oracle Beehive server instance, you will five instances each of the User Directory Service, the E-mail Service, the Workflow Service, and so forth. However, each service is instantiated as a single deployment of the service, or as a single collection of all of the available instances.
This deployment scenario requires either a single database instance or an Oracle RAC cluster. From the user directory standpoint, you can integrate Oracle Beehive with a supported external corporate directory, or you can deploy it as a standalone system that leverages its own user directory capabilities and features.
Typically, a deployment with multiple Oracle Beehive instances across multiple computers is used in test environments, large production environments, or where a higher level of service (high availability) is required. Test environments in this scenario can either be replicas of their associated production environments (recommended) or they may be scaled-down versions that mimic production environment topologies but with less hardware. Cloning of Oracle Beehive instances is supported to facilitate this process.
Figure 7-3 Multiple Oracle Beehive Instances on Multiple Computers
During the Oracle Beehive installation process, you provide the names for your Enterprise, Organization, Site, and Instance. To successfully deploy multiple Oracle Beehive instances, you must provide the same names for Enterprise, Organization, and Site for all instances. You must also specify the same Oracle Database instance for all Oracle Beehive server instances.
Oracle Beehive supports deployments across networks zones, which are used to logically split the different layers of Oracle Beehive into the following areas:
Firewalls and multiple network zones are supported in this deployment scenario, providing increased security measures where user access to the system is required from corporate networks and the Internet. Network zones such as a corporate intranet or a demilitarized zone (DMZ) are also supported. Oracle Beehive services may have a dedicated system on which they run so that only the required services are exposed in the DMZ.
In this scenario, the Client Access Zone is separated from the other zones and their services, and resides in a separate network layer such as a DMZ. Firewalls may exist between the different zones, and a reverse proxy may also be present in the Client Access Zone. To provide higher levels of service (high availability), this deployment scenario may also consist of multiple computers each running an Oracle Beehive server instance. For more information, refer to "Deploying Oracle Beehive on Multiple Computers".
Typically, organizations deploy Oracle Beehive in this scenario for the increased security that it provides. This scenario protects core data (in the Data Zone) behind several layers (zones) and barriers. Similarly, this scenarios also protects application logic while seamlessly providing users needed access and functionality. Network connectivity layers are thin but, upon successful authentication, allow full access to available services.
Figure 7-4 Oracle Beehive Deployed Across Multiple Network Zones
Deployments that leverage segregated network zones with limited connectivity between these zones is common. These requirements are an evolution of continually improving security policies and best practices. The BTI provides the flexibility to integrate well with this configuration scenario and almost any other topology requirements.
The BTI enables Oracle Beehive to accommodate any number of network buffer zones while still providing client access. This maintains open access to the system but limits the possibility of system compromise.
The BTI provides a plug-in (mod_bti
) to Oracle HTTP Server, which allows enterprises to expose only one or two standard open ports to the Internet without limiting client access. The mod_bti
does so by recognizing Oracle Beehive MX protocol traffic and transparently redirecting those requests to the appropriate Oracle Beehive services.
The BTI allows enterprises to place very thin network services in the DMZ and minimize exposure of the Application and Data Tiers, while providing secure client access to Oracle Beehive services.