| Oracle® Beehive Deployment Guide Release 1 (1.5) Part Number E14834-03 |
|
|
View PDF |
| Oracle® Beehive Deployment Guide Release 1 (1.5) Part Number E14834-03 |
|
|
View PDF |
This module includes information on the following topics, which are related to the architectural considerations when planning for an Oracle Beehive deployment:
Oracle Beehive can work in many different permutations, with exact placement and integration of components and servers varying greatly. Configuration depends on the needs of the organization and the existing architecture that can be leveraged.
The choice of architecture has a definite impact on performance and stability. Some organizations may require high availability, and may have moved to Oracle Beehive for this purpose. Others may not need high availability throughout an architecture, and can save time and resources initially.
Access to Oracle Beehive is determined by your network setup and security strategies. Part of your planning involves determining where components need to be accessed from, whether internally, externally, or both. You can deploy multiple Oracle Beehive server instances in the Application Tier, depending on where your users are, perhaps with one in a DMZ and another on the internal network.
To provide the appropriate capacity for the number of users in your deployment, you must start by evaluating how many servers you will need. Keep in mind not just the number of users, but also the frequency and concurrency of use.
Properly deployed Application Tier components can back up each other in cases of failures among them. This style of duplication and redundancy provides deployment flexibility and enables the load to be spread across all the components of the Application Tier.
Make sure you plan for the ability to restore deleted or corrupt data to its last known good state. This is a part of your backup strategy.
Availability encompasses strategies you put into place to keep things running in case of system failures. Strategies can range from backing up data in-house to maintaining high levels of redundancy for Oracle Beehive system components. One example is to ensure you have network redundancy, so that in the event that one of your network paths fails, network traffic can be routed along a secondary or backup network route.
With any deployment, it is important to plan for growth. You must be prepared to expand your deployment along with the size or needs of your user base. The use of virtual host names is recommended, even if you are installing on a single host or in a non-high availability environment. This will allow you to abstract Oracle Beehive server instances across multiple servers later on, without having to rename servers.
Make sure you have hardware that allows for growth and memory expansion. See the "Capacity Considerations" section for more information.
You can deploy Oracle Beehive on a single computer. However, such a deployment architecture may not be able to meet all the availability, security, and scalability requirements of your organization. Distribution of Oracle Beehive on multiple computers makes it easier to meet these requirements.
To optimize resource utilization on a particular computer, you should not mix different types of workloads on the computer. Typically, architectures for relatively large systems feature the distribution of these tiers on different computers.
The Application Tier, where Oracle Beehive server instances reside, and the Data Tier, where Oracle Database resides, handle different types of workloads. The Application Tier is CPU- and memory-intensive with fewer disk input/output (I/O) operations. Conversely, the Data Tier is I/O intensive.
In Oracle Beehive, the demand for Application Tier resources increases at a rate that is different from the rate at which the demand for Data Tier resources increases. This is another factor that justifies a distributed architecture. With a distributed architecture, you can scale up the Application and Data Tiers independently.
If you want to provide access to Oracle Beehive components from public networks, you must take measures to secure this type of access. You can enhance the security of the system by distributing the tiers and deploying the system behind a DMZ. Standard security practices and Oracle Beehive prevent, for example, network traffic from passing directly from the Internet to the database. Instead, such traffic would be routed through a DMZ and a server in the Application Tier.
If you choose to deploy Oracle Beehive in a DMZ, the DMZ must contain the hardware and software required to relay traffic securely between the public network and private network.
This section discusses deployment configuration considerations that may vary according to the specific requirements of each organization. For this reason, this and other Oracle Beehive deployment modules provide general, and not specific, guidance for these aspects of the system:
What type of platform is your organization comfortable with?
Is your organization prepared to deploy Oracle Beehive in stages?
How many servers is your organization willing to manage?
This largely depends on the size of your IT staff and availability of system management tools.
What type of platform is your organization comfortable with?
Oracle Beehive supports several chip architectures and operating systems including heterogeneous and homogeneous platforms.
Is your organization prepared to deploy Oracle Beehive in stages?
It is strongly recommended that you consider deploying Oracle Beehive in stages, as described in the section "Deploying Oracle Beehive in Stages" from Chapter 1, "Overview of Deploying Oracle Beehive". At minimum, you should plan to deploy the system in the following stages:
Development: Map out host names, servers, components, services, and access on a small scale.
Staging: Expand your initial deployment for use by a test group, to expose configuration issue flaws as well as to test capacity and performance.
Production: Official live deployment for use by the entire organization.
To ease the transition from a development environment to a production environment, it is best to use virtual host names from the start, as described in the "Scalability Considerations" section. With this strategy, you can grow your deployment without having to greatly modify the integration of your services and components.
Does your organization need high availability?
Keep in mind that implementing a high availability deployment generally doubles the need for hardware. As such, you should consider implementing cold failover strategies and becoming familiar with Oracle 10g Real Application Clusters (RAC).
Storage strategies in a high availability deployment are much different than in a standard deployment. If shared storage is needed, consider external Small Computer System Interface (SCSI) storage or a storage area network (SAN), a high-speed specialized network that interconnects different kinds of data storage devices with associated data servers or network attached storage (NAS).
The increased complexity of a high availability environment means that installation and configuration involves significantly more planning and effort than does a non-high availability environment. Management of a high availability environment is also more complex and should be allocated the appropriate amount of time.
What is your organization's existing backup solution?
Recommended backup strategies for most organizations include standing policies for regular, scheduled data backups, file system backups, and tape backups. Also, your organization might have mandated recovery times and granularity for data recovery that you'll need to consider.
|
 Copyright © 2008, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
