Oracle® Web Conferencing Administrator's Guide Release 2 (2.0.4.3) Part Number B10877-03 |
|
|
View PDF |
This chapter highlights the factors to consider when deploying Oracle Web Conferencing. The issues range from sizing guidelines to firewall issues to topology considerations for an enterprise that is geographically distributed.
The Oracle Web Conferencing Sizing Guide helps you determine the hardware required to set up Web Conferencing for your specific needs. Please read this guide prior to installing and deploying Web Conferencing
As discussed in previous chapters, the Oracle Web Conferencing system includes the following components:
Oracle Real-Time Collaboration Core components that provide the core functionality of Web Conferencing
The Document Conversion Server for converting Microsoft Office documents that need to be shared during a conference
The Voice Conversion Server for streaming voice data during a conference
The set of Oracle Real-Time Collaboration database schemas residing in an Oracle9iAS database
In addition, the Oracle Web Conferencing system interacts with an Oracle9iAS Infrastructure system to manage user sign-on and to synchronize user information with the Oracle Internet Directory.
Figure 3-1, "Oracle Real-Time Collaboration Basic Components" shows the components needed for Web Conferencing. After you have installed Web Conferencing, you will have the following components:
Figure 3-1 Oracle Real-Time Collaboration Basic Components
The Oracle Real-Time Collaboration Core components and Document and Voice Conversion servers are installed on Oracle9iAS mid-tier systems. Document and Voice Conversion servers must be installed on a computer running Microsoft Windows and Microsoft Office. (The Voice Conversion and Document Conversion servers have additional hardware and software requirements discussed in the Oracle Web Conferencing Sizing Guide). The supporting database and infrastructure systems are often installed on a separate database host, although they can also be installed together with the core components.
Some considerations need to be made, however, to support conference services on a corporate intranet that generally includes a secure intranet area behind a firewall, a DMZ ("demilitarized zone") between the firewall and the public Internet, and web conferencing users both within the intranet and outside the firewall in the Internet.
Figure 3-2, "Oracle Real-Time Collaboration Example Deployment" shows an example of a deployment that can allow access to users outside the corporate firewall. The components are placed as follows in the DMZ or behind the firewall:
The Real-Time Collaboration Core Components are in the DMZ, listening on port 80 for HTTP and port 443 for HTTPS
The Single Sign-On Server used to authenticate users entering a conference is in the DMZ, to communicate with users outside the firewall
The Real-Time Collaboration Repository, without Single Sign-On, is behind the inner firewall
The Oracle9iAS Infrastructure is inside the inner firewall
Figure 3-2 Oracle Real-Time Collaboration Example Deployment
The Single Sign-On Server and Oracle Real-Time Collaboration Core components can be located on the same mid-tier system, if desired. The Single Sign-On server can remain with the Oracle9iAS infrastructure if both are placed in the DMZ to serve Internet users. The repository and Oracle9iAS infrastructure can be on separate machines or combined, or can even be combined on a machine with the Oracle Real-Time Collaboration core components.
In addition, you must consider where the multiplexer listening ports are placed:
Direct TCP/IP connection to mx ports available: All intranet users should be able to make a direct TCP/IP connection to the Real-Time Collaboration Core Components (the ports that the mx is listening on).
You may use a Load Balancer (LBR) to manage processes handled by your Oracle mid-tier servers. If so, then keep these considerations in mind:
See Chapter 6, "Sample Deployments" for an example.
If you have multiple corporate locations that will use Web Conferencing, then you must consider:
The number of conferences held in a single geographic location
The number of conferences held across geographic locations
The number of streaming-voice conferences held across geographic locations
Whether creating clusters will help distribute Real-Time Collaboration processes to distinct geographic locations
The following sections outline some rules of thumb to apply when considering where to deploy Real-Time Collaboration core components and Voice Conversion servers.
Because data from one user's desktop is distributed to other end-user desktops during Web Conferencing, end users may experience latency issues depending on their location. Oracle Web Conferencing, by itself, cannot address network latency issues. You must resolve these issues through other mechanisms.
However, you can consider where you will deploy the Real-Time Collaboration core components, depending on how many meetings are held in specific geographic locations as described the the following two scenarios.
Scenario 1: Many Meetings in Separate Geographical Locations
If your company holds many conferences where most of the attendees are in the same geographical region, then Oracle Corporation recommends deploying a set of Real-Time Collaboration Core Components instances in that geographical region.
For example, a company has multiple divisions all over the world, and each division's employees hold many conferences with each other. Occasionally they hold conferences with employees from other divisions in different locations.
In such a scenario, it does not make sense to force users to use a Real-Time Collaboration cluster in a different location, thereby causing network latency problems for users. Instead, each location can have its own set of Real-Time Collaboration Core Components instances. See "Real-Time Collaboration Clusters" for discussion of how to create geographically-oriented clusters of components.
Scenario 2: Many Meetings Across Geographical Locations
If attendees of most conferences are in different regions, then having a set of Real-Time Collaboration Core Components instances in each geographical region will not help prevent latency issues.
For example, a US-based company has outsourced its sales/support organization to a site in India. If a typical conference involves a sales agent from the site in India and a customer in the US, then there deploying Real-Time Collaboration Core Components instances in the India site will not prevent a latency problem.
You should deploy Voice Conversion Servers in areas where the servers are able to successfully dial in to all conference numbers that will be used. It may be beneficial to deploy a Voice Conversion Server in the region where most calls terminate. For example, if a significantly large number of Web Conferencing users dial out to a particular region like the United Kingdom, it would be beneficial to have a Voice Conversion Server deployed in the UK instead of using a Voice Conversion Server in the United States to dial the UK numbers. See "Real-Time Collaboration Clusters" for discussion of how to create geographically-oriented components.
Without explicit partitioning of the instances in the system, all Web Conferencing Server processes in all instances are considered part of one group. Whenever a new conference is created and a Web Conferencing Server process needs to be chosen for a conference, the conference could be assigned to any one of the Web Conferencing Servers in the system. But, sometimes, it is useful to partition the system into clusters based on geographical distribution.
Figure 3-3, "Real-Time Collaboration Clustering" shows a sample Web Conferencing deployment where components are grouped according to their geographic locations.
To create clusters like those shown in Figure 3-3, you use the InstanceLocation property. Instances that have the same value for the InstanceLocation property are part of a Real-Time Collaboration cluster. The advantages of creating a cluster include:
Load balancing: All Web Conferencing Server processes in all instances that are part of the cluster become part of one pool of available servers, and the load is balanced intelligently between the different Web Conferencing Servers.
Load separation: If hardware load balancers are also geographically distributed, users can be served by separate Real-Time Collaboration clusters that are more locally situated to the users.
High availability: An instance could be down, which means that all Web Conferencing Servers in the instance are down, but other Collaboration Servers from other instances that are part of the same cluster can provide undisrupted service to users.
The Oracle Web Conferencing Application (OC4J_imeeting) is the component that picks the Web Conferencing Server process for a conference. The Oracle Web Conferencing Application knows the Web Conferencing Server process location and picks a Collaboration Server process in an instance which has the same value as its own location.
The Document Conversion server or Voice Conversion server can also be assigned an InstanceLocation property. If you have multiple Document and/or Voice Conversion servers that are installed at different geographic locations, and you used the InstanceLocation property to identify clusters of Real-Time Collaboration core components, you can also assign matching InstanceLocation properties to the Document and Voice Conversion servers. For example, as shown in Figure 3-3, "Real-Time Collaboration Clustering", each instance of the Document and Voice Conversion Servers in the United Kingdom is assigned to service a set of Real-Time Collaboration Core Components whose location attribute value is "UK." Each instance in the set of Document and Voice Conversion Servers in the United States is assigned to service a set of Real-Time Collaboration Core Components whose location attribute value is "US."
See Also: See "Properties to Configure Clusters" for details about setting the InstanceLocation property. |