| Oracle® Collaboration Suite Deployment Guide 10g Release 1 (10.1.2) Part Number B25492-04 |
|
|
View PDF |
| Oracle® Collaboration Suite Deployment Guide 10g Release 1 (10.1.2) Part Number B25492-04 |
|
|
View PDF |
Once you understand the Oracle Collaboration Suite architecture, the next step is to plan your deployment. This process involves two basic issues, network and architectural configuration. Because network configuration varies according to the unique requirements of each organization, this chapter does not provide specific network setup instructions. Instead, it discusses the basic network issues that organizations must address when deploying Oracle Collaboration Suite. This chapter also provides a comprehensive discussion of the architectural issues and available configurations that organizations must consider when deploying Oracle Collaboration Suite.
This section discusses network planning issues:
The basic goal of network planning is to make optimal use of Oracle Collaboration Suite and your existing network services and components. To accomplish this, you must determine a number of issues including the amount of access permitted for external sources, the capacity needed to meet user requirements, and network availability. You must also consider business issues such as budget constraints and the strategic reasons behind each of your network planning goals. How much flexibility do you have to change your network? Are you able to update business processes if necessary?
In smaller deployments of Oracle Collaboration Suite, 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 severs must be planned accordingly.
When deploying Oracle Collaboration Suite, access and security must be planned simultaneously, since each issue has a direct impact on the other, especially with smaller deployments.
Access is arguably the more complex of these two issues. 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 location from which the user accesses the network, whether the user does so with a thick or thin client, and the component to which the user attempts to gain 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 such network services must interact very closely with the components of Oracle Collaboration Suite. Understanding this interaction is the key to understanding Oracle Collaboration Suite 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 instance, by denying access to Internet Message Access Protocol (IMAP) from the outside world. The other element to consider is how to secure the traffic you do allow to flow, and this is where encryption plays an important role. This is especially true for external traffic.
Another critical, and often overlooked, element of security is the planning and management of administration accounts on your servers. Due to the number of administrative accounts—which provide both management flexibility and manageability—there is also the potential for a large number of passwords, and administrators are tempted to use the same password for all accounts. This is a bad idea for obvious reasons. Planning and managing the use of different passwords for different accounts improves security for your Oracle Collaboration Suite installation.
A typical installation of Oracle Collaboration Suite may separate traffic in two ways.
Internal Traffic
Internally, all protocols are allowed and all clients may be used. This policy can be modified to be more granular, either by configuring access rules in the services themselves, or by separating the networks with firewalls.
Typical clients include Oracle Connector for Outlook, Mozilla Thunderbird, Oracle Real-Time Collaboration, the Oracle Calendar server Web client, Oracle Files, and the Oracle Calendar desktop clients.
External Traffic
Externally, only a few encrypted, hardened and monitored services are exposed. Hyper Text Transfer Protocol Secure (HTTPS) and Simple Mail Transfer Protocol (SMTP) are the only services typically available from the outside world.
HTTPS is the HTTP protocol implemented over Secure Sockets layer (SSL) or Transport Layer Security (TLS). It provides better security than HTTP by providing authentication and data encryption. Users generally access Oracle Collaboration Suite from outside using Web based applications over HTTPS. So you can proxy HTTPS as each user requirements.
SMTP is used for the transmission of e-mails across the Internet. So you can proxy SMTP through a mail relay.
This section summarizes the issues to consider when evaluating an installation site. You should investigate these issues, keeping them in mind when reading through the detailed questions at the end of this chapter.
To meet your organization's required access options, start by asking the following questions.
Which Oracle Collaboration Suite components and network services will be used?
Choose the components of Oracle Collaboration Suite that you need, and consider which network services are necessary. For example, if you install the Mail component, you may want it to be accessible from anywhere in the world through HTTPS. Generally, the three most important Oracle Collaboration Suite network services are routing equipment, DNS, and mail relay:
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 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-mails to their destinations, mostly within local networks.
From where should these be accessible?
For example, if Oracle Calendar is installed, will it be accessible externally as well as internally?
Do your plans fit into your organization's security model?
Before creating an elaborate deployment plan for Oracle Collaboration Suite, 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 you will be relying on?
It may be practical to make use of existing network services.
What is the configurability of these services? Can they be easily changed to suit Oracle Collaboration Suite?
Check how flexible your existing network implementation is.
What is the size of the current network, if there is one?
Find out what sort of upgrades and additions, if any, will have to be made to the network to accommodate Oracle Collaboration Suite.
How many users will there be?
This is a primary concern in determining the type of deployment you need. See Chapter 3, "Deploying Oracle Collaboration Suite" for more information.
What is your budget?
Cost is always an important consideration in any network installation.
Answers to the preceding questions will greatly help you to evaluate:
Which Oracle Collaboration Suite and network components need to be deployed
How many servers they will be deployed across
Where they should be deployed
How they should be configured
This section provides the following detailed questions you should ask about an existing network before deploying Oracle Collaboration Suite.
What kind of network/security policies does your organization have?
Does your organization use (Network Address Translation) NAT to abstract its network?
Has your organization implemented load balancing and reverse proxy?
Does your organization use hardware encryption acceleration?
Does your organization want to expose IMAP to the rest of the world?
Will your organization want Oracle Real-Time Collaboration to be available through the Internet?
What services might your organization want to deploy initially or later?
What kind of network/security policies does your organization have?
Any existing policies must be adhered to when installing Oracle Collaboration Suite, unless your organization is willing to re-create its policies on short notice. This is likely to affect:
What services can be used
Where services can be exposed; that is, internally or externally.
Whether SSL is required to protect services. SSL is a security standard that transmits data in an encrypted and authenticated form over a network. If the services must be protected with SSL, it is a good idea to get SSL certificates early on in the process.
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 reserve server names for separate internal only, 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.
|
Note: For more information, see "What is your organization's existing DNS strategy?" later in this chapter. |
Does your organization use (Network Address Translation) 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 Collaboration Suite.
|
Note: When you install an application tier, it absorbs the name of the server on which it is installed. You must configure external IPs on your DNS server, then configure Oracle Collaboration Suite to use the appropriate virtual addresses instead of the original server name. |
What is your organization's existing DNS strategy?
Your organization's existing DNS strategy is crucial to planning the access options for your Oracle Collaboration Suite installation. Together with NAT, DNS regulates how protocols are routed from users to the Oracle Collaboration Suite installation. There are two basic DNS strategies to consider:
Configuring a single DNS instance is more difficult. Requests for OracleAS Single Sign-On have to resolve both internally and externally.
Although configuring single DNS for a small company is less complex, it is not the most secure configuration, and can expose crucial information about your network if not done properly.
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 Collaboration Suite installation. With load balancing and reverse proxy, you can abstract the routing and addressing of HTTP/HTTPS traffic so that Oracle Collaboration Suite servers are not directly exposed to external users.
If your organization uses existing hardware and a switching strategy, consider whether Oracle Collaboration Suite 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 on.
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 (MX) records early on, to map domain names to mail servers.
Does your organization use hardware encryption acceleration?
If you are planning on using 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 Collaboration Suite.
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 Collaboration Suite 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. Take note of the relay's limitations, 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 start to deploy Oracle Collaboration Suite.
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 Collaboration Suite mail relay, which can reside behind a firewall or in a DMZ.
Does your organization want to expose IMAP to the rest of the world?
IMAP is used to access e-mails from the mail server. By using IMAP, you can not only retrieve e-mails but also manipulate e-mails on the server itself. Many organizations will choose not to provide IMAP access directly over the Internet, as they would feel overly exposed 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.
Will your organization want Oracle Real-Time Collaboration to be available through the Internet?
The best way to make Oracle Real-Time Collaboration available externally is to install it on its own server in a DMZ. This enables direct connections from the outside world for consoles, while reducing the load on small instances by dedicating Oracle Real-Time Collaboration—a relatively high-load service—to its own box.
If Oracle Real-Time Collaboration cannot be installed on its own server, the Oracle Real-Time Collaboration server must still be available directly to clients, and not put behind a proxy server, for example (although NAT is supported). Oracle Real-Time Collaboration clients first attempt to connect directly to the Oracle Real-Time Collaboration servers, and then attempt to connect directly to the Oracle HTTP Server or Web cache.
What services might your organization want to deploy initially or later?
It is possible that in the process of deploying Oracle Collaboration Suite, your organization may want to either implement services for the first time (such as a load balancer, for example), or upgrade existing services (such as a mail relay).
Oracle Collaboration Suite 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 Collaboration Suite for this purpose. Others may not need high availability throughout an architecture, and can save money as a result. For example, implementing high availability for certain components and not for others may save some money.
Access to Oracle Collaboration Suite 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 run multiple application tier servers, depending on where your users are, perhaps with one in a DMZ and one on the internal network, and both requiring access to OracleAS Single Sign-On. More often though, one set of application tiers is deployed, with separation and access provided using NAT and DNS. This is usually due to a limited number of servers or a high availability setup.
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.
Another strategy to consider when planning capacity is the separation of tiers. Each tier uses resources in its own way, so installing them on separate servers can be beneficial. With this strategy, you can tune and grow your tiers granularly.
Finally, make sure you use appropriate hardware platforms. You can choose from several operating systems (such as Solaris, Linux, or Windows), and architectures (two or more CPUs, 32 bit or 64 bit), depending on the requirements of your organization and your existing environment. It is possible to run both heterogeneous and homogeneous platforms.
Application tier systems have a shared nothing architecture, and are therefore more suitable for smaller and cheaper hardware, such as single or dual CPU. Database server systems are typically larger, multiple CPU computers with larger memory requirements.
Properly deployed application tier systems can serve as backups to each other. This style of duplicated application tiers provides flexibility of deployment and enables the load to be spread across all the application tier systems as it swings, for example, from e-mail traffic to Oracle Content Services access over the course of the day.
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 performing basic backups in-house to maintaining high-levels of redundancy for the Oracle Collaboration Suite system components. One example is making sure 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.
When deciding which components are most in need of redundancy, imagine a situation in which the whole network fails, and think about what service or component is most business critical. Make sure you put in place an efficient availability architecture plan for those components that will meet your businesses service levels. The availability strategy of the OCS system components should be driven by the service availability requirements of your business.
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 tier or in a non-high availability environment. This will allow you to abstract services 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" section for more information.
You can deploy components and services of Oracle Collaboration Suite 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 the tiers 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 two Oracle Collaboration Suite tiers handle different types of workloads. The Applications tier is CPU- and memory-intensive with fewer disk I/O operations. The infrastructure and Infrastructure tier is disk I/O intensive.
In Oracle Collaboration Suite, the demand for application tier resources increases at a rate that is different from the rate at which the demand for infrastructure and information storage resources increases. This is another factor that justifies a distributed architecture. With a distributed architecture, you can scale up the information storage and application tiers independently.
If you want to provide access to Oracle Collaboration Suite 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 would prevent, for example, network traffic from passing directly from the Internet to the database. Instead, such traffic would be routed through a DMZ and an Application Server tier.
The DMZ must contain the hardware and software required to relay traffic securely between the public network and private network. Sometimes a network gets flooded with so many requests that the data traffic stops or becomes very slow, denying users access to services or resources. This is known as Denial of Service (DoS). A DMZ must provide protection against security threats such as DoS and viruses.
This section discusses deployment configuration issues that may vary according to the specific requirements of each organization. For this reason, the Oracle Collaboration Suite Deployment Guide does not provide specific guidance for these issues.
How many servers are needed for the number and profile of users?
What type of platform is your organization comfortable with?
How many servers are needed for the number and profile of users?
General guidelines are provided in Chapter 3, "Deploying Oracle Collaboration Suite". These purpose of these guideline is to alert you to different deployment configurations and the advantages and disadvantages of each, but not to provide specific deployment configuration information.
How much hardware can your organization afford?
In an ideal world, you would purchase as many servers as you need to build a solid, highly available Oracle Collaboration Suite installation. However, budget limitations may require you to scale back your investment and make creative use of network services and protocols to run Oracle Collaboration Suite securely and efficiently.
How many servers is your organization willing to manage?
This largely depends the size of your IT staff and availability of system management tools.
What type of platform is your organization comfortable with?
Oracle Collaboration Suite supports several chip architectures and operating systems including heterogeneous and homogeneous platforms.
Is your organization going to grow quickly?
You may want to plan your deployment in three 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 design flaws and test capacity and performance.
Production: Official deployment for use by the organization as a whole.
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" section. With this strategy, you can grow into a duplicated application tier 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. You will need to implement cold failover strategies and should consider becoming familiar with Oracle10g Real Application Clusters.
Storage strategies in a high availability deployment are much different than in a standard deployment. Shared storage is needed; consider external 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 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. As well, organizations may have mandated recovery times and granularity for data recovery. With an Oracle Collaboration Suite installation, consider the amount of data that will be backed up for Oracle Mail, Oracle Calendar, and Oracle Content Services.
Does your organization have archiving needs?
Oracle Mail enables third-tier storage of old or seldom accessed messages in a tertiary tablespace, which can be economically stored on disks. Other archiving strategies for Oracle Collaboration Suite are currently being developed.
The End-User Documentation Portal is a set of customizable HTML pages that provides an overview of Oracle Collaboration Suite clients as well as information for downloading, installing, and configuring each Oracle Collaboration Suite client. The End-User Documentation Portal also includes links to the FAQ & Troubleshooting site on the Oracle Technology Network (OTN), as well as Oracle Collaboration Suite end-user tutorials
Certain components such as Mobile Data Sync or Oracle Mobile Collaboration require frequent device certification updates. In such cases, the End-User Documentation Portal provides getting started information for these components and links to OTN for device certification and configuration information.
Administrators can easily host the End-User Documentation Portal, customize the default content or add more content to the portal, and show or hide content based on the Oracle Collaboration Suite components they are deploying at their site. For example, if your organization is deploying only the Oracle Calendar, Oracle Content Services, and Oracle Mail components, you can configure the End-User Documentation Portal so that it displays client deployment information for those components.
Administrators are encouraged to customize End-User Documentation Portal content. For example, administrators can use the End-User Documentation Portal to specify download locations, mail server names, and voicemail access numbers.
How-to procedures already documented in the component online help will not be duplicated in the End-User Documentation Portal. Where relevant, users are directed to sections of the online help for more information.
The End-User Documentation Portal is included with the installation CD as a ZIP file. Further information is provided in the Instructions for using the End-User Documentation Portal in Oracle Collaboration Suite Administrator's Guide
|
See Also: For information on installing the End-User Documentation Portal, please see the following; |
