| Oracle® Collaboration Suite Deployment Release 2 (9.0.4) Part Number B15606-01 |
|
|
View PDF |
| Oracle® Collaboration Suite Deployment Release 2 (9.0.4) Part Number B15606-01 |
|
|
View PDF |
This chapter provides an overview of Oracle Collaboration Suite architectures, and describes strategies and questions to consider when planning your architecture. This chapter contains the following topics:
Introduction to Oracle Collaboration Suite Architecture Planning
Questions to Ask about Existing or Planned Oracle Collaboration Suite Architectures
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 because of it. For example, implementing high availability just for Email, and not for Calendar, Files and other components, can save an organization a lot of time and money.
You can deploy all three tiers of Oracle Collaboration Suite on a single node. 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 nodes makes it easier to meet these requirements.
To optimize resource utilization on a particular node, you should not mix different types of workloads on the node. Typically, architectures for relatively large systems feature the distribution of these tiers on different nodes.
The three Oracle Collaboration Suite tiers handle different types of workloads. The middle tier is CPU-intensive and memory-intensive with few disk I/O operations. The infrastructure and information storage tiers are disk I/O intensive. The information storage tier disk I/O consists of comparable numbers of read and write operations, and the infrastructure tier disk I/O consists of more read operations than write operations.
In Oracle Collaboration Suite, the demand for middle 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 the need for a distributed architecture. With a distributed architecture, you can scale up the information storage tier and middle tier independently. The following figure displays the information storage tier and middle tier on different nodes.
If you want to provide access to Oracle Collaboration Suite components from public networks, then 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 demilitarized zone (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. It must also provide protection against known security threats, such as Denial of Service (DoS) attacks and viruses.
To provide the appropriate capacity for the number of users in your deployment, you must start by evaluating how many servers you will need. You should keep in mind not just the sheer number of users, but also the frequency and concurrency of use.
Consult the document Oracle Collaboration Suite Sizing and Performance Tuning Release 2 (9.0.4) for information on memory and server needs, and see the section in this document, "Planning for Oracle Collaboration Suite Scalability", for information on planning for future expansion of your network architecture.
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.
Middle tier systems have a "shared nothing" architecture, and therefore are more suitable for smaller and cheaper hardware, such as single or dual CPU. Database server systems are typically larger, multiple CPU nodes with larger memory requirements.
Properly deployed middle tier systems can serve as backups to each other. This style of "duplicated" middle tiers provides flexibility of deployment and allows the load to be spread across all the middle tier systems as the load swings from, for example, e-mail to Oracle Files access through the day.
As described in Chapter 2, "Oracle Collaboration Suite Network Planning", 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, be it internally, externally or both.
You can run multiple middle 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 Single Sign-On. More often though, one set of middle 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.
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 "Planning for Oracle Collaboration Suite Capacity" for more information.
The term "high availability" refers to the capability of a network to keep running should a component or application fail. This is especially important for a core communication tool such as e-mail, or a real-time communication tool such as Web Conferencing.
Distribution of middle tiers over multiple nodes does not ensure high availability. All the tiers of the system must be available in order to provide continuous access to services such as e-mail and voice mail. To provide continuous access to services, you must replicate components of the system and implement failover mechanisms for redirecting users from failed components to working components.
In the following figure, the three tiers of Oracle Collaboration Suite are distributed and replicated.
Figure 3-2 Distributed and Replicated Tiers in Oracle Collaboration Suite
Availability is maximized when you duplicate and replicate all the tiers of Oracle Collaboration Suite. Load balancing is used to handle failure in the middle tier. Oracle9i Real Application Clusters is used to handle failure in the information storage tier. A cold standby server is used as a failover measure for the infrastructure 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.
Network redundancy encompasses strategies you put into place to keep things running in the case of network failure. Strategies can range from performing basic backups in-house to maintaining high-level site mirroring. The latter is not possible yet with Oracle Collaboration Suite, so it is best to implement a thorough backup strategy.
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 you would like to restore first. Make sure you put in place an efficient failover plan for those components, using duplicated tiers or other backup strategies. If you feel that all components are essential, then you need a high level of redundancy.
This section provides the following detailed questions you should ask about an existing or planned architecture in which you want to deploy Oracle Collaboration Suite.
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?
Use the document "Oracle Collaboration Suite Sizing and Performance Tuning Release 2 (9.0.4)" to determine how many servers you will need for your deployment.
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.
What type of platform is your organization comfortable with?
Oracle Collaboration Suite supports AIX, Solaris, HP-Unix, Linux, Tru64 and Windows. The platform you choose can influence the hardware you can use. 64-bit servers are often used for databases, while 32-bit servers are often used for middle tiers. See "Planning for Oracle Collaboration Suite Capacity" for more details.
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 "Planning for Oracle Collaboration Suite Scalability". With this strategy, you can "grow" into a duplicated middle 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 high availability generally doubles the need for hardware. You will need to implement cold failover strategies and should consider using Oracle9i Real Application Clusters.
Storage strategies in a high availability deployment are much different than in a standard deployment. Shared storage is needed; you should 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.
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 high availability 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 Email, Calendar and Files.
Does your organization have archiving needs?
Oracle Email allows 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.
This section, and the rest of this chapter, describes and illustrates the various architecture types used with Oracle Collaboration Suite. You can refer to these illustrations when planning your own deployment, and should definitely also consult Chapter 4, "Oracle Collaboration Suite Deployment Examples" for "real-world" examples of working deployments.
This section contains the following topics:
About Oracle Collaboration Suite Dedicated and Duplicated Middle Tiers
Illustration of Oracle Collaboration Suite Dedicated Middle Tiers
Illustration of Oracle Collaboration Suite Duplicated Middle Tiers
Comparison between Oracle Collaboration Suite Architecture Types
Comprehensive Oracle Collaboration Suite Duplicated Middle Tier Deployment
In Oracle Collaboration Suite, you can deploy dedicated middle tier nodes to handle specific applications, such as Oracle Email and Oracle Files. Alternatively, you can duplicate the middle tier nodes that run these applications. This form of duplication offers the following benefits:
Simplification of middle tier management: This is because the requirements and processes for managing each duplicated node are the same.
Better use of middle tier resources: This is because the demand for various applications varies with the time of day. For example, if peak e-mail usage is at the start of the day and peak file usage at all other times, then all the middle tier nodes can respond to this change in service requirements.
The following figure illustrates the difference between the dedicated tiers and duplicated tiers options.
Figure 3-3 Dedicated Tiers and Duplicated Tiers in Oracle Collaboration Suite
If you were using dedicated middle tier nodes, then at the start of the business day, Oracle Files nodes would be underused and Oracle Email nodes would struggle to cope with peak load.
However, if the system is evolving, then you may want to phase in components. For example, you can implement Oracle Email first, then implement Oracle Files, and later the Oracle Calendar server. In such cases, to reduce the impact on the earlier phases of implementation, it may be more appropriate to dedicate hardware to specific middle tier components.
This section describes the services and components of each of the three tiers of Oracle Collaboration Suite. This section contains the following topics:
The middle tier provides the following services:
E-mail protocols
Simple Mail Transfer Protocol (SMTP)
Post Office Protocol, version 3 (POP3)
Internet Message Access Protocol, version 4 (IMAP4)
File protocols
File Transfer Protocol (FTP)
Server Message Block (SMB)
Network File System (NFS)
AppleTalk Filing Protocol (AFP)
Web-based Distributed Authoring and Versioning (WebDAV)
Web protocols
Hypertext Transfer Protocol (HTTP)
HTTP-Secure (HTTPS)
E-mail services, including Webmail/HTTP
File services, including Oracle Files/HTTP
Calendar services
Webcal/HTTP
SyncML/HTTP
Oracle Calendar server
Wireless services, including Wireless/HTTP
Portal services, including Oracle9i Application Server Portal/HTTP
Oracle UltraSearch services, including Oracle UltraSearch/HTTP
Web Cache
The infrastructure tier consists of the following components:
Directory services
Lightweight Directory Access Protocol (LDAP)
Oracle Delegated Administration Services/HTTP
Oracle9i Application Server Single Sign-On server, which provides single sign-on and HTTP services
Infrastructure database, which contains Oracle Internet Directory, Oracle9iAS Single Sign-On, and Oracle9i Application Server Portal data
Figure 3-4 illustrates an implementation of dedicated middle tiers.
Figure 3-4 Oracle Collaboration Suite dedicated middle tiers
Details on this illustration are provided in the following topics:
Physical Location of Oracle Collaboration Suite Dedicated Tier Components
Oracle Collaboration Suite Dedicated Tier Installation and Management
In the Dedicated Tiers option, the middle tier, infrastructure tier, and information storage tier are installed on individual, dedicated nodes. On the middle tier, dedicated nodes handle requests for Oracle Email, Oracle Files, and the Oracle Calendar server services. On the database tier, dedicated nodes handle requests to access the Oracle Email, Oracle Files, and infrastructure databases.
Information storage is installed on each of two or more clustered nodes. It consists of both Oracle Files and Oracle Email instances, and databases that are configured to use Oracle9i Real Application Clusters that are placed on a shared disk.
In relatively large deployments, you can use individual instances of Oracle9i Real Application Clusters for the Oracle Files and Oracle Email databases. This feature helps separate the two databases in the event that one of them fails. The infrastructure is installed on a separate node. The infrastructure database is placed on a shared disk and accessed from a dedicated instance on this node. The middle tier is installed on several nodes, but only specific processes are started according to the role of each node.
If you replicate dedicated nodes to ensure availability, then you must implement hardware load balancing to distribute e-mail requests over multiple e-mail nodes, file access requests over multiple file nodes, and so on. The exceptions to this are Oracle Calendar server nodes, for which the load must be statically partitioned over multiple calendars.
One of the advantages of the Dedicated Tiers option is that all the workload types are separated and you can configure and tune the nodes according to the role they play in the system. This improves the performance of each node. However, a solution that is based on this deployment architecture option requires the use of an accurate sizing methodology and an in-depth understanding of the usage profile of each Oracle Collaboration Suite component.
There are only four types of installations involved in implementing the Dedicated Tiers option: Storage, infrastructure, middle tier, and Computer Telephony Server. However, because nodes are dedicated to performing specific roles, you need to set up as many as six different configurations and process combinations in the middle tier. In addition, there are two setup procedures on the database tier. A node dedicated to a particular role will have different setup and administration tasks as compared to a node dedicated to another role.
In theory, patches need to be applied only to the nodes they affect. For example, an Oracle Files middle tier patch need not be applied to the Oracle Email middle tier nodes. This feature helps reduce the overall work involved in maintaining the system.
From the scalability perspective, the Dedicated Tiers option offers the flexibility of independently scaling up different elements of the system to accommodate of shifts in the workload. For example, if there is an increase in file usage over a period of time, then you can add more nodes to the system to handle the Oracle Files services with little impact on the rest of the system. This holds true as long as the increased load on the database tier is accommodated.
If SSL is implemented on the system, then you can add more nodes to handle HTTPS requests. These extra nodes are required to manage the increased workload of encryption. In addition, the increments in which you are allowed to scale up the system can be fine-grained.
To improve the availability of the infrastructure, you can use duplicated nodes, with each running an instance of Oracle Internet Directory. These instances of Oracle Internet Directory are synchronized by using Oracle Internet Directory Replication. For standard operation, you can statically partition Oracle Internet Directory workload across these servers.
For the Oracle Calendar server, you must provide a failover node that can access the calendar on a shared disk. For other middle tier dedicated servers and servers in the DMZ, you can replicate and use load balancing. For the database tier, you can use clustered database servers running Oracle9i Real Application Clusters for the Oracle Files and Oracle Email databases.
You can implement the Dedicated Tiers option by using small, inexpensive hardware devices that run either Linux or Windows. However, due to the complexity of the system, the management costs may be higher than that of other deployment options.
To ensure high availability, you will need to use a large number of nodes if the nodes are individually dedicated to a variety of different roles. This factor would increase the hardware costs associated with this option.
The Duplicated Tiers option must be used if the solution is to be outsourced or based on Collaboration Certified Configuration.
|
Note: Collaboration Suite Certified Configuration is a well-defined configuration of an Oracle Collaboration Suite installation. This configuration is used by Oracle Outsourcing to standardize the administration and maintenance activities for an Outsourced Oracle Collaboration Suite service. It features Oracle Collaboration Suite deployed in a standard file layout and is supported with management scripts and procedures. |
Figure 3-5 illustrates an implementation of Duplicated Tiers.
Figure 3-5 Oracle Collaboration Suite duplicated middle tiers
Details on this illustration are provided in the following topics:
Physical Location of Oracle Collaboration Suite Duplicated Tier Components
Oracle Collaboration Suite Duplicated Tier Installation and Management
By implementing the Duplicated Tiers option, you can simplify the system, reduce the number of nodes needed for a small system, and obtain the flexibility of distributing components. In this deployment architecture, there are at most four types of nodes: middle tier, information storage, infrastructure and the Oracle Calendar server, and Computer Telephony.
The middle tier nodes handle requests for all components: Oracle Email, Oracle Files, the Oracle Calendar server, and Oracle UltraSearch. These nodes can also handle requests from both Web and wireless clients. These nodes must all have the same installation, setup, and process profile.
information storage is installed on each of two or more clustered nodes. It consists of both Oracle Files and Oracle Email instances with databases configured to use Oracle9i Real Application Clusters placed on a shared disk. In larger deployments, you can use an Oracle9i Real Application Clusters for each of the Oracle Files and Oracle Email databases, which would help separate them in the event of a failure.
The infrastructure is installed on a separate node. Its database, which is not certified for use with Oracle9i Real Application Clusters, is placed on the shared disk and accessed from a dedicated instance on the node.
The Oracle Calendar server processes are either installed on the same node as the infrastructure or on a dedicated node, and the Oracle Calendar server file system is placed on a shared disk. An Oracle Calendar server proxy is placed on each middle tier node to pass on requests for the Oracle Calendar server to the combined infrastructure and the Oracle Calendar server node. As a variation of this option, you can run the Oracle Internet Directory processes on the middle tier nodes, instead of the combined or dedicated infrastructure node. In this case, the installation becomes compliant with the Advanced Configuration: Multi Oracle Collaboration Suite mid-tier option of Collaboration Suite Certified Configuration. This option offers good separation of the application tier and database tier.
The Duplicated Tiers option allows for some separation of workload types. This separation is not as comprehensive as the separation allowed by the Dedicated Tiers option. By using the Duplicated Tiers option, you can optimize the performance of the information storage nodes and the middle tier nodes.
One of the advantages of this deployment architecture option is that when the workload shifts between components during the business day, the capacity of the entire middle tier is available to respond to all types of requests. This is in contrast to the Dedicated Tiers scenario described earlier, in which the Oracle Email nodes would be underused and the Oracle Files nodes would have to cope with the peak load.
In the Duplicated Tiers option, there are only four types of installation, configuration, and combination of processes involved, even when the system grows very large. The fact that all middle tier nodes handle all types of requests means that you can automate the management of these nodes, which are likely to be duplicated multiple times in large systems, by using appropriate tools or shared installation images. By using Blade Servers and shared installation images, you can easily add new middle tier processing capability by mounting the appropriate disk and starting the middle tier processes. Any middle tier patch must be applied to all the middle tier nodes. However, if you use shared images, then you need to apply the patch only once.
From the scalability perspective, this deployment architecture option provides a lot of flexibility for scaling up in small increments. However, you cannot scale up specific components. Because all middle tier nodes handle all types of requests, all the components will have access to any new resource that is added. If the size of a particular workload grows, then the proportion of all middle tier nodes that are used to handle this workload will increase.
With the Duplicated Tiers option, the alternatives for improving availability are the same as those for the Dedicated Tiers option. To improve the availability of the infrastructure, you can provide duplicated nodes with instances of Oracle Internet Directory synchronized by using Oracle Internet Directory Replication.
You can statically partition the Oracle Internet Directory service workload across these nodes for normal operation. For the Oracle Calendar server, you must provide a failover node that can access the Oracle Calendar server on a shared disk. You can replicate and use load balancing for the other middle tier dedicated servers and servers in the DMZ. For the database tier, you can use clustered database servers that run Oracle9i Real Application Clusters for the Oracle Files and Oracle Email databases.
You can implement the Duplicated Tiers option by using small, inexpensive hardware devices that run Linux or Windows. In addition, management costs may be lower than that for other deployment architecture options due to the simplicity of the system. It is possible to start with a lower number of nodes for a small system as compared to the number of nodes required when implementing the Dedicated Tiers option.
Each deployment architecture option offers advantages. The Duplicated Tiers option allows for a certain degree of workload separation and the ability to start relatively small and maximize resource use as the workload for particular services increases. In addition, this deployment architecture option is relatively cheap to manage and is consistent with Collaboration Suite Certified Configuration.
The Dedicated Tiers option offers the greatest flexibility to tune servers for specific uses and to scale up by component. However, this architecture is more expensive to manage. It is preferred for systems in which the implementation of components is being phased in, and for large systems in which the resource demands can be estimated.
This section describes an Oracle Collaboration Suite deployment in which every client and every service is deployed across an architecture that allows intranet and internet access while optimizing security, availability, scalability and fault coupling. This is a duplicated middle tier deployment. Figure 3-6 shows a fully fault-tolerant network, and multiples of each and every component to provide a full, high-availability, multiple network zone deployment.
|
Note: Figure 3-6 is for illustrative purposes only. It is intended to show a sample deployment that might be appropriate for the needs of a large organization. For smaller organizations, Oracle Collaboration Suite can be deployed with a much simpler architecture and lesser hardware requirements. See Chapter 4, "Oracle Collaboration Suite Deployment Examples" for examples of typical Oracle Collaboration Suite deployments appropriate for the needs of small, medium, and large organizations, with differing levels of requirements for security, performance, and availability. |
Figure 3-6 Comprehensive Oracle Collaboration Suite Duplicated Middle Tier Deployment
This deployment is described in the following topics:
This section describes the following elements of the network infrastructure:
The security of an Oracle Collaboration Suite network architecture is based on a three-zone setup. This setup consists of the intranet, a DMZ, and external networks such as the Internet.
The network is configured to be redundant, with dual network paths to each Oracle Collaboration Suite component. To reduce the switch count, you can use virtual LANs. The entire Oracle Collaboration Suite network infrastructure must be at least 100 MBps. If you want to use network-attached storage, then the leftmost network segment next to the database servers in the diagram must be at least 1000 MBps, with redundancy. Remember that to ensure redundancy, you must use multiple network adapter cards (two or four) for each server host.
Firewalls demarcate the intranet from the DMZ and the DMZ from the Internet. These firewalls are configured to monitor each other using a heartbeat mechanism so that if one fails, then the other continues to provide service.
For security, the DMZ firewall is configured to allow only HTTPS access over the Web or wireless media and SMTP services. In addition, it is configured to allow connections to ports required by Oracle Web Conferencing for enabling Web seminars and meetings.
The intranet firewall is configured to allow only HTTP and SMTP service to pass from the DMZ to the intranet. In addition, if Web seminars or meetings enabled by Oracle Web Conferencing need to be conducted over the Internet, then Oracle Network and LDAP access must be provided by the firewall exclusively to the Web Conferencing application servers in the DMZ.
Load balancers play a key role in the Oracle Collaboration Suite deployment architecture. They are configured in heartbeat-failover pairs in the DMZ as the front end for services such as e-mail relay and Web access to the Internet. They also form the front end of the Oracle Collaboration Suite service complex in the intranet. Load balancers route requests to pools of active servers that provide application services, to distribute the load dynamically across available resources. If a node fails, then the content switches route service requests to the surviving servers. For both pairs of load balancers, the "sticky for session" attribute must be set for all services.
The load balancer pair in the DMZ is configured with virtual hosts. These virtual hosts are mapped to the HTTPS service through the Web Cache servers and the Web Conferencing application servers, and to the SMTP service through the SMTP relay server pool.
In addition, a common feature of some load balancers is the ability to provide SSL acceleration. If this feature is available, then you should use it to offload the work of encryption from the DMZ servers and reduce the requirement for resources.
The load balancer pair in the intranet is configured with virtual hosts and services mapped to two partitioned server pools.
This section describes the following end-user devices supported by Oracle Collaboration Suite:
The term "native client" refers to client devices such as PCs, Netscape Messenger, Oracle Corporate Time, and PDAs running client-side applications such as Microsoft Outlook.
Because native clients must communicate using application protocols (such as POP and IMAP) or proprietary protocols, typically, they are used only within the intranet, or outside the intranet through virtual private network (VPN) or intranet dial-up access.
Oracle Collaboration Suite applications are served as markup-based applications to Web clients on PCs, PDAs, and mobile phones. For security, all Web clients should access only those published services that are provided over SSL.
These servers provide the connections by which Oracle Collaboration Suite exchanges e-mail with other sites.
External WAP gateways enable access to Oracle Collaboration Suite services through mobile phones and certain types of PDAs. These gateways are often deployed at mobile service provider sites. The type of access can be one of the following:
Pull-type service, like a PC browser application
Push-type service, like a WAP push operation
|
Note: A WAP push operation can send an out-of-band message to a mobile device and present the user with an alert and the opportunity to log in to the application. |
The Oracle Wireless and Voice application communicates principally with WAP gateways for mobile data access.
When configured for Voice mail and Fax, fax machines can send pages to the Oracle Voicemail and Fax server. These pages are delivered as faxes to users' unified inboxes. When configured for wireless and voice services, the speech server can perform outbound operations such as sending e-mail or files to a fax machine.
When configured for voice mail and fax, telephones (mobile or landline) can be used to send and receive voice mail. When configured for wireless and voice services, you can use both speech recognition and speech synthesis to access a number of Oracle Collaboration Suite services. In addition, you can make outbound calls by using the Oracle Wireless and Voice component to deliver alerts to users.
The DMZ tier is exposed to allow services to be presented over the Internet. You must configure the DMZ firewall to allow SMTP, Web HTTP, and Web conferencing traffic.
This section describes the following elements of the DMZ tier:
The DMZ firewall permits only published services on the Internet to access the DMZ. This firewall must be configured to allow SMTP, Web over HTTP, and Web conferencing traffic. Two separate firewalls are used with a heartbeat mechanism running between them to ensure that failover takes place in the event of a firewall failure.
Figure 3-6 shows two LBRs, one connected to the firewall and the other to the Oracle Collaboration Suite components in the DMZ. Like the firewalls, the LBRs are configured to monitor a heartbeat between them to ensure that failover takes place in the event of an LBR failure. The DMZ LBRs also provide service-level failover in the DMZ. The LBR must be configured for "sticky" sessions to the DMZ hosts.
The SMTP gateways relay e-mail into and out of the Oracle Collaboration Suite system. The SMTP gateways are hosts that run standard sendmail. These hosts are configured to relay e-mail addressed to users and domains served by Oracle Collaboration Suite and to the SMTP mail transfer agent located on the intranet. They can also be configured to relay e-mail from allowed hosts on the Internet. If you do not configure the SMTP relay to relay mail only from known allowed hosts, then your infrastructure may be compromised for use by spammers. You can also configure the SMTP relays to require authentication and to provide secure SMTP connections over SSL.
There are at least two SMTP relays in the DMZ, and the DMZ LBR balances the load across both SMTP mail relays. If one SMTP relay fails, then the surviving SMTP relay will continue to provide service. If the e-mail volume is very high, then you can incorporate additional SMTP relay servers into the DMZ tier to provide additional capacity.
The SMTP gateway relays incoming e-mail to the Anti Spam component. This component relays e-mail that is not identified as spam back to the SMTP gateway for delivery to the users and domains on the intranet. By deploying the Anti Spam server in the DMZ with (or on the same server as) the SMTP gateway, spam can be blocked at the earliest opportunity. You can also have an antispam solution in which a service entity on the Internet filters inbound e-mail for spam before relaying the e-mail to the SMTP gateway in the DMZ. In this case, spam never reaches the DMZ. If required, you can configure the Anti Spam server for redundancy or to scale up throughput.
In the DMZ, the Web service is routed through the Web Cache instances. These Web Cache instances act as reverse proxies and caching servers for the Web servers that generate application content on the intranet. There are at least two Web Cache instances in the DMZ. These Web Cache instances provide load balancing and failover features.
If Oracle Web Conferencing is configured, then you must place a subset of the components, specifically the Web Conferencing application servers, within the DMZ. This would allow Internet attendees to participate in Web conferences and Web seminars.
Both Web over HTTP (to locate, join, or start meetings and seminars) and two ports for Web conferencing-specific protocols must be allowed to pass through the DMZ firewall. The protocols specific to Web Conferencing need not be routed through the DMZ LBR, because Web Conferencing has its own internal failover mechanism.
In addition, because Web Conferencing application servers require Oracle Internet Directory and Oracle Network Services, you must configure the intranet firewall to allow these protocols to be accessed only from the Web Conferencing application servers. There are at least two Web Conferencing application servers to provide for availability and capacity.
The Intranet tier hosts the core Oracle Collaboration Suite components. It is also assumed that the intranet is a secure and trusted network and that most users of Oracle Collaboration Suite are within the bounds of the intranet. The intranet is demarcated by the intranet firewall between the intranet and the DMZ. The users within the bounds of the intranet can be on the intranet, tunneled through by VPN servers, or connected through modem banks.
This section describes the following elements of the DMZ tier:
The intranet LBRs are configured as a failover pair with heartbeat monitoring. They are also configured to distribute HTTP requests to one pool of application servers, and to distribute LDAP protocol requests to another pool that contains the core Oracle Collaboration Suite infrastructure components. The "sticky" session attribute must be set for Oracle Collaboration Suite services routed by the LBRs.
Configuring Oracle Internet Directory for serving the LDAP directory protocol involves a more detailed setup. As a preview, the Oracle service will be provided by at least two servers in an active-active configuration.
It is recommended that you partition Oracle Collaboration Suite services according to the specific LDAP Oracle Internet Directory server they access. To achieve this, you must configure three virtual hosts for LDAP service on the intranet LBRs. You must configure the first virtual host as a host/LDAP port that maps to the first LDAP server and fails over to the second LDAP server. The second virtual host must be configured as a host/LDAP port that maps to the second LDAP server and fails over to the first LDAP server. Note that these two virtual hosts are not configured to implement load balancing. The third virtual host must be configured to map to both LDAP servers and must provide load balancing between both servers.
Oracle Internet Directory is the core of the Oracle Collaboration Suite infrastructure, and is used by all the other Oracle Collaboration Suite components. It is accessed through the LDAP protocol. Because it performs a critical role, it must be configured for high availability. You can achieve this by first setting up IP/storage failover between a pair of servers in active/active configuration and then setting up replication between them. Each pair of servers manipulates its own infrastructure database replica, and each pair replicates to the other pair, bidirectionally, by using Oracle Advanced Replication.
A native client must be assigned an LDAP server host name and port. By using the LBR configuration discussed earlier in this document, you can assign native clients the host name and port of the virtual host on the LBR that is configured to provide load balancing across both LDAP servers.
Each replica can be configured to use Oracle9i Real Application Clusters. This is not shown in Figure 3-6.
Enterprise directory information can be provided by a source other than the directory infrastructure of Oracle Collaboration Suite. In such cases, you can bidirectionally populate and update the key directory elements of Oracle Collaboration Suite by using the Directory Integration Platform (DIP).
The Oracle Calendar server maintains its own data store for calendar information. To maintain availability, the core Oracle Calendar server components are configured to run on an IP/file system active/standby failover pair of physical servers. HTTP-based calendar services, such as the Web-based calendar application and SyncML services, run on different hosts. Native clients such as Outlook Connector and Corporate Time connect directly to the primary Oracle Calendar server.
You must configure the Oracle Voicemail and Fax servers on the intranet and connect them to a PBX. Typically, the connection to the PBX is in the form of a T1/E1 or telephone line. To receive voice mail and faxes, you must configure the PBX to transfer busy or no-answer calls along with recipient information to the Oracle Voicemail and Fax servers. To achieve high availability, there is a pair of Oracle Voicemail and Fax servers. Each server is configured on the PBX so that if one fails, then calls are rerouted to the surviving server. You must configure the PBX to provide a dial-in number for telephone-based voice mail retrieval.
The voice servers must reside on the intranet. You must connect these servers to the PBX (typically through a T1/E1 or telephone line) in distinct "hunt groups". To provide speech recognition and speech synthesis interfaces over the telephone to e-mail, calendar, files, and directory services, you must configure the PBX to provide a dial-in access number that is distinct from the voice mail access number. The PBX must allow the voice server to make outbound calls for telephone-delivered alerts.
The Oracle Web Conferencing voice and conversion servers provide voice digitalization and presentation document conversion services. These servers are deployed in a failover pair and are located on the intranet. You must configure the Web Conferencing application servers in the DMZ so that they can communicate with all voice and conversion servers on the intranet. As mentioned earlier in this document, the Web Conferencing application servers communicate from the DMZ to the voice and conversion servers by using the port passed by the intranet firewall.
If configured, you must deploy the Oracle UltraSearch crawler servers as a failover (IP/file system) pair. These servers must be made to share active/standby access to a database for Oracle UltraSearch. The crawler will access specified sites to build an intranet (and in some cases, Internet) search index.
The mainstay of the intranet deployment is the pool of two or more servers, each of which runs all of the Oracle Collaboration Suite application protocols. The intranet LBR distributes requests to the servers in this pool according to protocol. The services provided include the following:
SMTP for e-mail that is sent and received on the intranet
POP3 and IMAP for native e-mail clients
WebDAV, FTP, SMB, AFP, and NFS file access protocols
The Web and Mobile XML user interfaces for Oracle9iAS Portal, Webmail, Web Calendar, SyncML, Oracle Files Web application, Oracle Wireless and Voice, and Oracle UltraSearch
Oracle9iAS Single Sign-On services and self-service Oracle Delegated Administration Services
By configuring at least two hosts in the pool, you can ensure high availability for all application protocols. For scalability and enhanced throughput, you can add additional servers to this pool and update the LBR configuration. This configuration also ensures maximum use of resources in this pool across all application services.
You must follow the recommended method for configuring the application services to access directory services on each server in the pool. You must configure the SMTP MTA, Oracle Files, Oracle9iAS Portal, Oracle Wireless and Voice, Webmail, and Oracle Web Conferencing to access one of the virtual hosts on the LBR that routes requests to only one of the LDAP servers. IMAP, POP, Oracle Delegated Administration Services, Oracle9iAS Single Sign-On, the Oracle Calendar server, and Oracle Voicemail and Fax must be configured to access the other virtual host on the LBR that maps to the second LDAP server. This form of partitioning offers the following benefits:
Directory updates are grouped: Directory updates that might affect users, such as password updates, are grouped together. Therefore, users need not wait for directory replica propagation to complete before the update takes effect.
Requests for directory services are evenly distributed: Typically, the SMTP MTA, Oracle9iAS Single Sign-On, IMAP, POP, and Oracle Calendar place a high load on directory services. The user interfaces for Oracle Files, Oracle9iAS Portal, Oracle Wireless and Voice, Webmail, and Oracle Web Conferencing do not. By partitioning, the traffic for directory services is evenly balanced across competing application services.
The AntiVirus server receives e-mail from all the SMTP MTAs and returns uninfected or cleaned e-mail. The AntiVirus server is placed in the intranet and not in the DMZ. This way, it can be used by the e-mail administrative components to scan e-mail in the mail store, which was not scanned by the AntiVirus server at the time it was delivered. You must ensure that the AntiVirus server has a steady connection to the Internet for receiving virus signature updates.
Although somewhat of a misnomer (since we have already discussed data stores for the directory, its replica, the Oracle Calendar server, and the Oracle UltraSearch crawler), in any deployment of Oracle Collaboration Suite, the majority of database storage will be dominated by Oracle Email and Oracle Files.
For the deployment architecture shown in Figure 3-6, the guideline for using different Oracle Email and Oracle Files databases must be followed on the assumption that both databases would be handling large workloads. In addition, both databases are configured for multiserver Oracle9i Real Application Clusters access. This feature enhances the availability and scalability of the database tier.
The Oracle Files store is implemented by at least two servers for active/active access to the databases containing user files and e-mail, respectively. These servers are configured for Oracle9i Real Application Clusters. In addition, there are redundant paths to the physical disk storage for the Oracle Files store, regardless of whether the connection to the storage is NAS or SAN. As mentioned earlier in this document, if you are using NAS storage, then the network bandwidth for this segment must be 1000 MBps. In addition, the Oracle Files store is directly connected to a backup server to allow for fast backups, perhaps not requiring direct processing by the database servers.
