| Oracle® Beehive Deployment Guide Release 1 (1.4) Part Number E13795-02 |
|
|
View PDF |
| Oracle® Beehive Deployment Guide Release 1 (1.4) Part Number E13795-02 |
|
|
View PDF |
This module discusses the following network considerations when planning for an Oracle Beehive deployment:
Note:
Because network configuration varies according to the unique requirements of each organization, this module does not provide specific network setup instructions. Rather, it discusses the general network considerations that organizations must address when deploying Oracle Beehive.The basic goal of network planning is to make optimal use of Oracle Beehive and your existing network services and components. To accomplish this, you must determine a number of factors including the amount of access permitted to external sources, the capacity needed to meet user requirements, and network availability. You must also consider business factors such as budget constraints and the strategic reasons behind each of your network planning goals.
In small deployments of Oracle Beehive, network and architectural planning are intertwined since smaller pools of available servers result in fewer deployment options. When planning an architecture with only one or two servers, you will often have to choose between component accessibility and server location. The location of servers is often based on security requirements and, as a result, access to the servers must be planned accordingly.
When deploying Oracle Beehive, access and security must be planned simultaneously since each aspect has a direct impact on the other, especially with smaller deployments.
Access is arguably the more complex of these two considerations. In virtually any deployment, you must account for a number of access methods (or levels) within a single environment. These depend on factors such as the locations from which users will access the network, the types of clients users will leverage, and the components to which users will need access.
Because access is a network-dependent element, much of its setup depends on the surrounding network environment. Therefore, Domain Name Services (DNS), mail relays, reverse proxies, firewalls, network routing, and other network services must interact very closely with the components of Oracle Beehive. Understanding this interaction is the key to understanding Oracle Beehive network access in a production environment.
Security is a subset of access in many ways, as many security issues are solved simply by denying access to certain services or networks. For example, an organization might choose to deny access from outside its network across all protocols except for HyperText Transfer Protocol (HTTP) and Secure HyperText Transfer Protocol (HTTPS). HTTPS is the HTTP protocol implemented over Secure Sockets Layer (SSL) or Transport Layer Security (TLS). It is more secure than HTTP because it provides authentication and data encryption. Users typically access Oracle Beehive from outside the network with supported clients over HTTPS. So, you can proxy HTTPS as each user requires.
The other element to consider is how to secure the traffic that you allow to flow, and this is where encryption plays an important role. This is especially true for external traffic.
A typical Oracle Beehive deployment may separate traffic in the following ways:
Internally, all protocols are allowed and all clients may be used. In this case, a typical deployment could leverage the BTI for all client connections. This policy can be modified to be more granular, either by configuring access rules or by separating the networks with firewalls.
Externally, only a few encrypted, hardened, and monitored services are exposed. For example, some organizations choose to make external client access available only over HTTP and HTTPS. In this case, a typical deployment could leverage Oracle HTTP Server (installed with Oracle Beehive) deployed in a DMZ.
This section provides a list of questions that you should ask before deploying Oracle Beehive. The answers to these questions will help you to evaluate which Oracle Beehive and network components need to be deployed, where they need to be deployed, and how they need to be configured:
What kind of network and security policies does your organization have?
Has your organization implemented load balancing and reverse proxy?
Does your organization use hardware encryption acceleration?
What components might your organization want to deploy initially or later?
Which Oracle Beehive services and network services will be used?
What are the existing network services on which you will rely?
What kind of network and security policies does your organization have?
Unless your organization is willing to revise its policies, you'll need to adhere to existing network and security policies when deploying Oracle Beehive. This is likely to affect where you deploy Oracle Beehive, such as in or behind a DMZ, and what components you'll use to enable client connections, such as Oracle HTTP Server or the BTI.
Does your organization have a DMZ and if so, what kind?
This is crucial to the design and planning of your architecture, as it determines where components need to be placed, depending on how they are to be accessed. DMZ is a part of the network, which is in between an intranet and the Internet, and is often referred as the neutral zone. It enables only certain services of the hosts in an intranet to be accessible to the hosts on the Internet. This sub-network is especially used for public access servers such as Web servers.
If there is a DMZ:
How is it used for external access?
How is it used for internal access?
Are DNS servers used? If so, consider the following issues.
Sometimes, two DNS servers (split DNS) are used to help separate deployments by reserving server names for separate internal and external computers.
DNS servers can be separated onto separate networks; for example, one in the DMZ and one in the internal network.
You can configure any DNS server, such as Berkeley Internet Name Domain (BIND), to respond to DNS requests differently, depending on where the request originates.
DNS services can be further fortified when combined with Network Address Translation (NAT).
Using two DNS servers provides more flexibility than using just one. In either case, clients connect to either an external or internal IP address for the same host name, depending on where the connection originates, and client access is properly routed by DNS connectivity.
Does your organization use NAT to abstract its network?
NAT is the process of translating an IP address used within one network to a different IP address of another network. Generally, organizations set up NAT to translate internal addresses into public routable addresses. The translation takes place at the firewall and protects internal addresses from external tracing or routing.
NAT has a large and beneficial impact on naming services. External IP addresses in DNS can be mapped to virtual addresses as configured in Oracle Beehive.
Note:
When you install Oracle Beehive, each Oracle Beehive server instance assumes the name of the server on which it is installed. You must configure external IPs on your DNS server, then configure Oracle Beehive to use the appropriate virtual addresses instead of the original server name.Has your organization implemented load balancing and reverse proxy?
Load balancing is the process of managing the distribution of inbound traffic among multiple servers. The use of load balancers and reverse proxy is an important strategy in securing your Oracle Beehive deployment. With load balancing and reverse proxy, you can abstract the routing and addressing of HTTP/HTTPS traffic so that Oracle Beehive servers are not directly exposed to external users.
If your organization uses existing hardware and a switching strategy, consider whether Oracle Beehive can be integrated into it.
Using content switches as load balancers is recommended. Content switches can host virtual IP addresses and spread the load over multiple servers, particularly for Application Tier services. Traffic can be redirected based on protocols such as HTTP, HTTPS, SMTP, and so forth.
If your organization has host names for its current services running on virtual devices, migration will be much easier. In fact, it is always a good idea to identify virtual services names early in the process. Embed them in documentation and get SSL certificates early if they are needed. It is also a good idea to start setting up DNS and Mail Exchange records early on, to map domain names to mail servers.
Does your organization use hardware encryption acceleration?
If you plan to use the SSL protocol to encrypt communications, it is a good idea to make use of SSL accelerators to optimize performance. SSL processing is a CPU-intensive task that can reduce performance. This is best off-loaded to hardware devices designed for this purpose.
Consider using SSL to encrypt external access to Oracle Beehive.
Does your organization have an SMTP mail relay?
Relay services are important for filtering, limiting, and routing SMTP traffic. They can be used to protect Oracle Beehive instances from external abuse and unnecessary load.
Most organizations have an existing SMTP mail relay (or Mail Transport Agent), ideally with spam services implemented on it. However, note the limitations of mail relays, such as:
Attachment size
Throughput throttling
Retry count
Evaluate whether or not these limitations are realistic for your organization, and keep them in mind as you deploy Oracle Beehive.
It is a good strategy for many deployments to use programs such as these to handle and filter e-mail before forwarding it to the Oracle Beehive mail relay, which can reside behind a firewall or in a DMZ.
Does your organization want to expose IMAP externally?
IMAP is used to access e-mail messages from the mail server. Using IMAP, you can retrieve e-mail messages and manipulate them on the server itself. Many organizations choose not to provide IMAP access directly over the Internet, as they feel it overly exposes them from a security standpoint. If you decide to provide IMAP access across the Internet (without the additional security of a VPN infrastructure, for instance), Oracle Corporation strongly recommends implementing SSL for those IMAP services.
Is filtering installed for spam and viruses?
For the judicious use of valuable database storage, avoid saving unnecessary information such as e-mail spam. To protect the integrity of the network, viruses (often linked directly to spam) must also be blocked. There are a number of methods of filtering out these unwanted communications.
What components might your organization want to deploy initially or later?
It is possible that in the process of deploying Oracle Beehive, your organization may want to either implement components for the first time (such as a load balancer, for example) or upgrade existing ones (such as a mail relay).
Which Oracle Beehive services and network services will be used?
Determine which Oracle Beehive services your organization will use and consider which network services are necessary to support them. For example, if your organization plans to leverage the E-mail Service, you may want it to be accessible from anywhere in the world through HTTPS. Generally, the most important Oracle Beehive network components are as follows:
Routing Equipment: Routing equipment can include routers, load balancers, and firewalls.
Domain Name System (DNS): This network service resolves domain names or host names into Internet Protocol (IP) addresses. DNS maintains a database of all the host names and their respective IP address information.
Mail relay: This network service is a server that routes e-mail messages to their destinations, mostly within local networks.
From where should Oracle Beehive be accessible?
For example, will it be accessible to users externally, internally, or both?
Do your plans fit into your organization's security model?
Before creating an elaborate deployment plan for Oracle Beehive, make sure you know your organization's security model, if there is one. For instance, some organizations may not allow DMZs or external access to e-mail.
What are the existing network services on which you will rely?
It may be practical to make use of existing network services.
What is the configurability of your network services? Can they be easily changed to suit Oracle Beehive?
Check how flexible your existing network implementation is.
What is the size of the current network?
Find out what sort of upgrades and additions, if any, will have to be made to the network to accommodate Oracle Beehive.
How many users will there be?
This is a primary concern in determining the type of deployment you need but it also affects (or may be affected by) the capacity of your network. If supporting a specified number of users is the highest priority, you'll need to determine whether or not your network has the speed, bandwidth, and latency to support those users, and what network improvements might be needed to support them. Or, if your network is a fixed and known quantity that cannot be changed, you'll need to determine how many users it can realistically support and then plan accordingly.
What is your budget?
Cost is always an important consideration in any network installation.
|
 Copyright © 2008, Oracle. All rights reserved. Legal Notices |
|
