This part contains the following chapters:
Instant Messaging enables secure, real-time communication and collaboration, combining presence awareness with instant messaging capabilities such as chat, conferences, alerts, news, polls, and file transfers to create a rich collaborative environment. These features enable one-to-one as well as group collaboration through either short-lived communications or persistent venues such as conference rooms or news channels.
Instant Messaging ensures the integrity of communications through its multiple authentication mechanisms and Secure Sockets Layer (SSL) connections. Integration with Portal Server and Access Manager brings additional security features, services-based provisioning access policy, user management, and secure remote access.
This chapter contains the following sections:
At a simplistic level, an instant messaging service:
Accepts instant messages from external sites
Determines the user to which the message should be delivered, and routes it accordingly
Accepts instant messages from internal hosts
Determines the destination system to which the message should be delivered, and routes it accordingly
Provides presence updates for users who are online, offline, away, and so on
In addition, an instant messaging service can provide real-time conferencing, news and calendar alerts, and for offline users, email message forwarding.
Of crucial importance to a good instant messaging service is that the service provides for scalability, high availability, reliability, and good performance.
Instant Messaging contains the following core components:
Instant Messenger Resources (client). A set of files that makes up the client program for end users to initiate, compose, and reply to messages. Typically users also use the client to participate in conferences. The client is also called Sun Java System Instant Messenger.
Instant Messaging Server. An electronic message delivery system that supports instant message delivery from one system to another system. The server serves the presence information to Instant Messenger clients, enables end users to establish sessions, and enforces policies.
Instant Messaging Multiplexor. A scalability component that consolidates messenger connections. To support large deployments, with thousands of concurrent connections, Instant Messaging uses a connection multiplexor to improve server scalability. This component opens a single connection to the Instant Messaging server. In addition to scalability, you can install the multiplexor outside the firewall while leaving the server inside the firewall to protect it from unauthorized external access. The Instant Messaging multiplexor is also referred to as the multiplexor.
Access, Communication, and Transfer Protocols. These protocols, such as LDAP, HTTP, TCP/IP, and SMTP, can be found in Instant Messaging Supported Standards.
Access Manager Instant Messaging Service Definition. Instant Messaging provides a service definition to Access Manager using the Access Manager SDK, to provide support for Access Manager managed policies and SSO capabilities.
Instant Messaging API. Enables you to create custom Instant Messaging clients.
The software components discussed in this section work with the Instant Messaging server, but are installed separately. Chapter 21, Developing an Instant Messaging Architecture provides more detailed information that illustrates how these servers interact with Instant Messaging.
(Required) For any deployment, you need to install a web container, such as Sun Java System Web Server or Sun Java System Application Server. You can also use any open standard web server (for example, Apache). In all cases, the Instant Messenger resources must reside on the web container host.
Instant Messaging requires a web container to serve the Instant Messenger resources. The Instant Messenger resource files include:
The index.html file, provided by Instant Messenger, or a home page with a link to invoke Instant Messenger
Instant Messenger jar files (messenger.jar, imres.jar, imbrand.jar, imdesktop.jar, imnet.jar, and imjni.jar)
The Instant Messenger Online Help
You must install Instant Messenger resources on the same host where the web container is installed. In an Access Manager deployment, you can install these resources on the Access Manager server’s host or on a different web container host. In most cases, the resources will be installed on the same host where you installed the Instant Messaging server software. It is possible to locate the Instant Messenger resources on a host other than the Instant Messaging server or multiplexor.
Install the web container before configuring Instant Messaging.
(Required) Instant Messaging uses an LDAP server, such as Directory Server, for end user authentication and search. In a deployment with Portal Server, Instant Messaging uses the same LDAP server used by Portal Server. If you do not have an LDAP directory already installed, you must install one.
The Instant Messaging server does not store the Instant Messenger end-user authentication information. This information is stored in the LDAP server.
By default, the Instant Messaging server relies on the common end-user attributes cn and uid to search for end-user and group information. If you want, you can configure the server to use another attribute for search. In addition, Instant Messaging properties (such as contact lists and subscriptions) can be stored in files on the Instant Messaging server or in the LDAP server.
For instructions on configuring the server to use a non-default attribute for user search, see the Sun Java System Instant Messaging 7.2 Administration Guide.
Because a proper Directory Server implementation is instrumental to a successful Instant Messaging deployment, also see the Directory Server documentation:
http://docs.sun.com/app/docs/coll/1316.2
(Optional) An SMTP messaging server, such as Messaging Server, is used to forward instant messages, in the form of email, to end users who are offline. The SMTP server can also be used to archive instant messaging communications. This is in lieu of or in addition to the archive capability provided by Portal Server. The SMTP server does not have to reside on the same host as the Instant Messaging server.
(Optional) Calendar Server is used to notify users of calendar-based events.
(Optional) Access Manager and Access Manager SDK provide end user, service, and policy management, authentication and single sign-on services. In addition, Access Manager and Access Manager SDK are required in deployments that include Portal Server. In both deployments, the SDK must be installed on the Instant Messaging server’s host.
(Optional) Portal Server supports message archiving, and enables you to run Instant Messaging in secure mode. In addition, the Instant Messenger client is made available to end users through the Portal Server desktop. The following two Portal Server components provide additional functionality:
Instant Messenger installed in the Portal Server environment can be launched from the Instant Messaging channel available to end users on Portal Server Desktop.
Secure Remote Access enables remote end users to securely access their organization’s network and its services over the Internet. The end user can access Secure Remote Access by logging into the web-based Portal Server Desktop through the portal gateway. The authentication module configured for Portal Server authenticates the end user. The end-user session is established with Portal Server and the access is enabled to the end user’s Portal Server Desktop.
In the Portal Server environment, you can configure Instant Messenger in either secure or non-secure mode. In secure mode, communication is encrypted through the Portal Server Netlet. When you access Instant Messenger in secure mode, a lock icon appears in the Status area of the Instant Messenger application. In non-secure mode, the Instant Messenger session is not encrypted. For more information on Netlet, see the Portal Server documentation:
http://docs.sun.com/coll/1293.2
Instant Messaging is built on native Internet technology, so you can maintain a single architecture inside and outside your organization, even when collaborating with your customers and partners. Additionally, you aren’t locked into a proprietary system. All key components of Instant Messaging are based on proven, open Internet standards such as:
LDAP. Provides access to enterprise directory information, enabling an accurate, secure instant messaging system.
HTML. Formatting language for providing web browser access to the client.
HTTP. HypterText Transport Protocol for providing web browser access to the client.
SMTP. Simple Mail Transfer Protocol for reliable delivery of instant messages over Internet mail messages.
TCP/IP. Proven, worldwide networking protocol.
XMPP. Extensible Messaging and Presence Protocol for interoperating with public networks through open source gateways.
XMPP protocol is used to format the instant messages. The message bodies themselves may be wrapped in HTML.
In Instant Messaging, user information and preferences are retrieved from an LDAP directory. This directory can either be dedicated for use by Instant Messaging, or be shared by other components such as Access Manager or Portal Server. User data is typically retrieved using LDAP search functions. Instant Messaging deployments that make use of Access Manager and Portal Server make use of the same LDAP server.
Instant Messaging server-to-server and client-to-server communications occur over TCP/IP. You can secure these communications by using TLS encryption.
Instant Messaging uses SMTP to send messages to offline users and for email archiving.
Browsers use HTTP to retrieve Instant Messenger resource files from the Web server. Once retrieved, the browser reads the HTML and displays the contents of the files. Client-to-server communication can take place over HTTP/HTTPS/SOCKS proxy. Also, HTTPBIND is a server component (that uses the HTTP protocol) through which browser-based XMPP clients can communicate with the Instant Messaging server.
Instant Messaging 7.2 is an XMPP client/server solution, able to communicate with XMPP-compliant servers, clients, and gateways. Gateways are available in the open-source community to enable communication between Instant Messaging server and AOL, Yahoo, and other instant messaging systems.
Figure 19–1 shows the Instant Messaging software architecture.
The web server (or an application server with a web service embedded), downloads the Instant Messenger resources from a browser to the clients. The resource files make up the client. Clients send messages to one another through a multiplexor, which forwards the messages to the Instant Messaging server.
The directory server stores and retrieves local user and group delivery information such as preferences, location, and to which multiplexor to route messages for this user. When the Instant Messaging server receives a message, it uses this information to determine where and how the message should be delivered. In addition, the directory server can contain user information such as contact lists and subscriptions.
In this basic configuration, Instant Messaging directly accesses Directory Server to verify user login name and passwords for mail clients that use Instant Messaging.
Outgoing instant messages from clients go directly to the multiplexor. The multiplexor sends the message to the appropriate Instant Messaging server, which in turn forwards the message to another Instant Messaging server, or if the message is local, to the multiplexor with which the recipient is associated. (See Instant Messaging Physical Deployment Examples for illustrations of this process.)
New users are created by adding user entries to the directory. Entries in the directory can be created through Instant Messaging Server (by enabling new-user registration feature) or changed by using the tools provided with the directory server.
Instant Messaging components are administered through a set of command-line interfaces and text-based configuration files. Any machine connected to the Instant Messaging host can perform administrative tasks (assuming, of course, the administrator has the required privileges).
Typical Instant Messaging deployments are not installed on a single machine. They also have additional features like multiplexing and high availability enabled. See Chapter 21, Developing an Instant Messaging Architecture for more information.
The following sections outline the three primary components of Instant Messaging in further detail:
The Instant Messaging server handles tasks such as maintaining presence information for each user, controlling Instant Messenger privileges and security, enabling Instant Messenger clients to communicate with each other by sending alerts, initiating chat conversations, and posting messages to the available news channels. The Instant Messaging server also handles archiving, calendar alerts, and offline email notifications
The Instant Messaging server supports the connection of a multiplexor that consolidates connections over one socket. For more information on the multiplexor, see Instant Messaging Multiplexor.
Access control files and Access Manager policies are used for administration of end users, news channels, and conference rooms.
The Instant Messaging server routes, transfers, and delivers instant messages for the Instant Messaging product.
The server can look up directory information directly from the LDAP server. The results of the LDAP queries are cached in the process, with configurable aging and expiration, so settings are tunable. Refer to the Directory Server documentation for further information.
http://docs.sun.com/app/docs/coll/1316.2
After the message is processed, the server sends the message to the next stop along the message’s delivery path. This can be the intended recipient’s multiplexor or another server. Once received by a multiplexor, the message is routed directly to the intended recipient. See Basic Instant Messaging Architecture for an illustration of this process.
The Instant Messaging multiplexor component connects multiple instant messenger connections into one TCP (Transmission Control Protocol) connection, which is then connected to the Instant Messaging server. The multiplexor reads data from Instant Messenger and writes it to the server. Conversely, when the server sends data to Instant Messenger, the multiplexor reads the data and writes it to the appropriate connection. The multiplexor does not perform any end user authentication or parse the client-server protocol (IM protocol). Each multiplexor is connected to one and only one Instant Messaging server.
Although you can configure Instant Messaging without a multiplexor, production deployments should be configured to use the multiplexor. You can install multiple multiplexors based on your deployment requirements. For more information, Chapter 21, Developing an Instant Messaging Architecture.
Instant Messenger is Instant Messaging’s client that can be configured to be a browser-based applet using Java plugin, or a standalone Java application using JavaTM Web Start.
To run Instant Messenger client on Solaris or Linux, you must use Java Web Start. On Microsoft Windows you can run Instant Messenger as an applet or a Java Web Start application. In most cases, run Instant Messenger as a Java Web Start application.
For more information on customizing Instant Messenger, see the Sun Java System Instant Messaging 7.2 Administration Guide.
Instant Messenger provides the following modes of communication:
Chat. Instant Messenger’s version of Instant Messaging conferences is called chat. Chat is a real-time conversation capability that enables end users to complete projects, answer customer queries, and complete other time-critical assignments. Chat sessions (two or more participants) are held in chat rooms created on a need basis.
Conference Rooms. Conference rooms are persistent chat rooms that work similarly to regular chat sessions, but offer:
Access control
Moderated chats
Alerts. Alerts enable information delivery and response to end users through the Instant Messenger interface. Alerts can deliver time-critical information to the end user. The sender of the alert message is notified when the message is delivered and read by the recipient. You can also configure Instant Messaging to forward alerts to an email address.
Poll. The polling function enables you to ask end users for their response to a question. You can send a question and possible answers to poll recipients, and the recipients can respond with their selected answer.
News. News channels are forums for posting and sharing information. End users can subscribe to news channels of interest to see updates using the URL of the news channels or view the news channel updates through static messages. Administrators control news channel access by assigning end users to the channels they need, and deciding who can see or post information to the channels.
Instant messages can contain embedded URLs. If you are using proxy servers, you might need to have clients using Java Web Start modify their proxy configuration for resolving such URLs.
For more information on configuring the proxy settings manually, see the Sun Java System Instant Messaging 7.2 Administration Guide.
The deployment process consists of the following general phases, referred to as the Solution Life Cycle:
Analyzing business requirements
Analyzing technical requirements
Designing the logical architecture
Designing the deployment architecture
Implementing the deployment
Operating the deployment
The deployment phases are not rigid: the deployment process is iterative in nature.
For detailed information on the deployment process for Instant Messaging, and other Java Enterprise System components, see the Sun Java Enterprise System Deployment Planning Guide.
This chapter introduces the concepts, context, and rationale of sizing your Instant Messaging deployment.
This chapter contains the following sections:
When you design your deployment, you must decide how to configure your Instant Messaging server to provide optimum performance, scalability, and reliability.
Sizing is an important part of the design effort. The sizing process enables you to identify what hardware and software resources are needed so that you can deliver your desired level of service or response time according to the estimated workload that your Instant Messaging server users generate. Sizing is an iterative effort.
Because each deployment has its own set of unique features, this chapter will not provide detailed Instant Messaging sizing information for your specific site. Also, this chapter will not provide sizing information for servers with which Instant Messaging interoperates, such as LDAP, SMTP, and so on. Rather, this chapter explains what you need to consider when you architect your sizing plan. In addition, you’ll find general guidelines for Instant Messaging components you can modify to suit your site’s needs. Work with your Sun technical representative for your deployment hardware and software needs.
Use this section to identify the data you need to size your Instant Messaging deployment. The following topics are covered in this section:
Your peak volume is the largest concentrated numbers of unique logins to your Instant Messaging system within a given period in a day. The volume can vary from site to site as well as across different classes of users. For example, peak volume among groups might occur during corporate-held core hours which differ between time zones.
Analyzing peak volume involves three basic operations:
Determining when and for how long the peaks occur
Sizing your deployment against peak volume load assumptions
Once patterns are analyzed, choices can be made to help the system handle the load and provide the services that users demand.
Making sure that your Instant Messaging deployment can support the peak volume that you have determined
Measuring your load is important for accurate sizing. Your usage profile determines the factors that programs and processes place on your Instant Messaging servers and multiplexors.
This section helps you create your usage profile to measure the amount of load that is placed on your deployment.
Creating a usage profile involves answering the following questions:
What is the total number of users on your system?
When counting the number of users on your system, account for not only the users who have accounts and can log into the system, but also the users with accounts who are currently not logged into the system. The following table describes the types of users that make up the total.
Connection |
Description |
---|---|
Inactive User |
A user with an Instant Messaging account who currently is not logged into the system. Non-connected users consume disk space but no CPU or memory. |
Connected/Inactive |
These users are logged in, but are not currently sending or receiving instant messages. |
Connected/Active |
Logged into the system and actively sending messages, updating user information such as contact lists, and attending conferences throughout the day. |
Characterize your configured users using these three general profiles. The total of these users should give you an idea of the total number of concurrent connections you need to support.
If you have a small deployment, the defaults might be sufficient to meet your site’s needs. So, if you have a very small deployment (for example, less than 300 users), you might not need to go through this process of planning a sizing strategy. Work with your Sun Client Services representative to determine your individual needs.
How many connections are on your system during your peak volume?
Correctly formulating the maximum number of concurrent users that has to be sustained by the system is key to planning your resource requirements. Although a deployment usually has maximum number of configured users, it is important to plan for the maximum number of concurrent users (connected and more or less active). A conservative estimate for the number of concurrent users can then be determined based on a 1:10 ratio. Thus, for a deployment of 50,000 configured users, the concurrent users would be 5,000.
Specifically, note the number of concurrent connections, idle, and busy connections.
Connection |
Description |
---|---|
Concurrent Connection |
Number of unique TCP connections or sessions that are established on your system at any given time. |
Idle Connection |
Connection where no information is being sent between the client and multiplexor or server and multiplexor. |
Busy Connection |
A connection that is in progress. An established connection where information is being sent between the client and multiplexor or multiplexor and server. |
To determine the number of concurrent connections in your deployment, you can count the number of established TCP connections by using the netstat command on Solaris platforms.
To determine the number of concurrent connections you can support, you need to obtain two values from parameters within the iim.conf file that are used for tuning multiplexor performance:
iim_mux.numinstances - Specifies the number of multiplexor instances.
iim_mux.maxsessions - Specifies the maximum number of clients that one mutliplexor process can handle. The default is 1000.
Once you have obtained these values, multiply the numinstances number by the maxsessions number. This gives the total number of concurrent connections supported by your deployment. For information on the iim.conf file, see the Sun Java System Instant Messaging 7.2 Administration Guide.
If you have a large deployment, how will you organize your users?
For example, consider placing active users on one server and inactive users on another.
What is the amount of storage used for each user?
If you are storing your end user data, such as contact lists, in LDAP, you need to plan for the space required to store this data. If you configure the server to store this data outside LDAP, the server stores it in a flat file. See the Sun Java System Instant Messaging 7.2 Administration Guide for more information.
How many messages enter your Instant Messaging system from the Internet?
The number of messages should be measured in messages per second during your peak volume.
How many messages are sent by your users to:
End users on your system?
The Internet?
This number of messages is also measured in messages per second during the peak volume.
Will you be using SSL? If yes, what percentage of users and what type of users?
For example, in a particular organization, 20% of connections during peak hours will enable SSL.
Answering these questions provides a preliminary usage profile for your deployment. You can refine your usage profile as your Instant Messaging needs change.
While the following questions are not applicable to creating your usage profile, they are important to developing your sizing strategy. How you answer these questions might require you to consider additional hardware.
How much redundancy do you want in your deployment?
For example, do you need to consider high availability.
What backup and restore strategy do you have in place (such as disaster recovery and site failover)? What are the expected times to accomplish recovery tasks?
Typically you need to back up the server configuration files, database, and any resource files you have customized.
Once you establish a usage profile, compare it to sample pre-defined user bases that are described in this section. A user base is made up of the types of Instant Messaging operations that your users will perform. Instant Messaging users fall into one of these user bases:
The sample user bases described in this section broadly generalize user behavior. Your particular usage profile might not exactly match the user bases; you will be able to adjust these differences when you run your load simulator (as described in Using an Instant Messaging Load Simulator).
A lightweight user base typically consists of users with simple Instant Messaging requirements. These users rarely initiate chat sessions and rarely receive invitations. They might only use Instant Messaging as a presence tool.
A heavy user uses significantly more system resources than a casual user. Typical usage for a this type of user may be something like the following:
Presence updates equal to or greater than 20 times a day.
Contact list contains about 30 contacts.
Subscribes to the presence updates of all the contacts in the contact list.
Sets up around four conferences or chats per day where each conference has three people in the conference room and lasts an average of 10 minutes, and a message is added to the conference every 1-15 seconds.
To measure the performance of your Instant Messaging architecture, use your user bases (described in Defining Your Instant Messaging User Base or Site Profile) and your usage profile (described in Creating Your Instant Messaging Usage Profile) as inputs into a load simulator.
A load simulator creates a peak volume environment and calibrates the amount of load placed on your servers. You can determine if you need to alter your hardware, throughput, or deployment architecture to meet your expected response time, without overloading your system. Using a load simulator involves five basic steps:
Defining the user base that you want to test (for example, casual users)
If necessary, adjust individual parameters to best match your usage profile.
Defining the hardware that will be tested
Running the load simulator and measuring the maximum number of concurrent connections on the tested hardware with the user base
Publishing your results and comparing those results with production deployments
Repeating this process using different user bases and hardware until you get the response time that is within an acceptable range for your organization under peak load conditions
Contact Sun Client Services for recommended load simulators and support.
Once you evaluate your hardware and user base with a load simulator, you need to assess your system performance. The topics in this section address methods by which you can improve your overall system performance.
Make sure you have an adequate amount of physical memory on each machine in your deployment. Additional physical memory improves performance and enables the Instant Messaging server to operate at peak volume. With sufficient memory, Instant Messaging can operate efficiently without excessive swapping.
For most deployments, you need at least 256 MB of RAM. The amount of RAM needed depends on the number of concurrent client connections, and whether the server and multiplexor are deployed on the same host. For information about concurrent connections, see Creating Your Instant Messaging Usage Profile. For information on hosting the server and multiplexor on the same host, see Developing Instant Messaging Architectural Strategies.
You can set the amount of memory allocated to the server by modifying the iim.jvm.maxmemorysize parameter in the iim.conf file. This parameter specifies the maximum number of megabytes of memory that the Java Virtual Machine (JVM) running the server is allowed to use. The default setting is 256 MB, and the maximum setting is 500 MB. For instructions on modifying this parameter, see the Sun Java System Instant Messaging 7.2 Administration Guide.
Disk throughput is the amount of data that your system can transfer from memory to disk and from disk to memory. The rate at which this data can be transferred is critical to the performance of Instant Messaging. To improve efficiency in your system’s disk throughput:
Consider your maintenance operations, and ensure you have enough bandwidth for backup. Backups can also affect network bandwidth, particularly remote backups. Private backup networks can be a more efficient alternative.
Carefully partition the data stores to improve throughput efficiency.
Ensure the user base is distributed across RAID (Redundant Array of Independent Disks) environments in large deployments. Typically, you make this decision as part of the Directory Server deployment planning process.
Stripe data across multiple disk spindles in order to speed up operations that retrieve data from disk.
When planning Instant Messaging server system disk space, be sure to include space for operating environment software, Instant Messaging software, and for any servers not currently in your network that need to be installed to support Instant Messaging (such as LDAP). Be sure to use an external disk array. In addition, user disk space needs to be allocated. Typically, this space is determined by your site’s policy. Typical installations will require:
Approximately 300 MB of free disk space for each server or multiplexor
Approximately 5 K of disk space for each user
Additional space for the Instant Messaging archive
The archive captures instant messages and archives them in a Portal Server Search database. End users can query and retrieve these archived messages using the Search page on the Portal Server desktop.
Use Table 20–1 to determine server and multiplexor disk space sizing numbers whether archiving is enabled or disabled. The figures listed in the table were generated using a 400MHz Ultra SPARC II Processor.
Table 20–1 Instant Messaging Server and Multiplexor Memory Disk Space Sizing for Concurrent Users
|
Server Memory Consumption for Connected/Inactive Users |
Server Memory Consumption for Connected/Active Users |
Multiplexor Memory Consumption for Connected/Inactive Users |
Multiplexor Memory Consumption for Connected/Active Users |
---|---|---|---|---|
Archive Disabled |
8 MB +20 K per User |
120 MB + 20 K per User |
8 MB + 20 K per User |
8MB + 28K per User |
SSO/Portal/Archive enabled |
100MB +25K per User |
120MB +30K per User |
8M+35K per user |
8 MB +40K per user |
Network throughput is the amount of data at a given time that can travel through your network between your client application and server. When a networked server is unable to respond to a client request, the client typically retransmits the request a number of times. Each retransmission introduces additional system overhead and generates more network traffic.
Improving data integrity, system performance, and network congestion reduces the number of retransmissions. Steps to do this involve:
Avoiding bottlenecks to ensure that the network infrastructure can handle the load
Partitioning your network
Not using theoretical maximum values when configuring your network to ensure that sufficient capacity exists for future expansion
Separating traffic flows on different network partitions to reduce collisions and to optimize bandwidth use.
Enable enough CPU for your servers and multiplexing services. In addition, enable enough CPU for any RAID systems that you plan to use. If you intend to use archiving in your deployment, you need to take those space requirements into consideration as well.
Use Table 20–2 to help determine the number of CPUs your installation requires for optimum performance whether archive is enabled or disabled. The figures listed in the table were generated using a 400MHz Ultra SPARC II Processor.
Table 20–2 Instant Messaging CPU Utilization Numbers
|
Server CPU Utilization for Connected/Inactive Users |
Server CPU Utilization for Connected/Active Users |
Multiplexor CPU Utilization for Connected/Inactive Users |
Multiplexor CPU Utilization for Connected/Active Users |
---|---|---|---|---|
Archive Disabled |
Several hundred thousand users per CPU |
30 K users per CPU |
50 K users per CPU |
5 K users per CPU |
Consider the following suggestions and generalizations when planning your multiplexor deployment. The parameters discussed in this section are located in the iim.conf file.
The number of iim_mux.maxthreads should not exceed the number of CPUs on your server.
This helps maximize resource utilization and optimizes processing speed.
The iim_mux.maxsessions value should be high enough to avoid rejecting connections, but it should be reasonable enough so that the multiplexor processes to not get overloaded.
Be sure that your expected number of concurrent client connections is less than the maximum possible by a safe margin.
Do not configure threads or number of concurrent sessions to more than you require. Otherwise, you will unnecessarily consume system resources.
A good starting point is to configure iim_mux.numinstances to the number of CPUs on the system.
See the Sun Java System Instant Messaging 7.2 Administration Guide for more detailed information about these parameters.
Once you have identified your system performance needs, the next step in sizing your Instant Messaging deployment is to size specific components based on your architectural decisions.
The topics in this section point out sizing considerations when you deploy two-tiered and one-tiered architectures. Using load balancers with Instant Messaging is also discussed.
A two-tiered architecture splits the Instant Messaging server deployment into two layers: an access layer and a data layer. In a simplified two-tiered deployment, you might add one or more multiplexors and servers to the access layer. The multiplexor acts as a proxy for users, and relays messages to the Instant Messaging server. The data layer holds the Instant Messaging server database and Directory servers. Figure 20–1 shows a simplified two-tiered Instant Messaging architecture.
Two-tiered architectures have advantages over one-tiered architectures that can impact your sizing decisions. Two-tiered architectures:
Are easier to maintain than one-tiered architectures
Enable the offloading of load-intensive processes like SSL, message reprocessing
Are easier for growth management and you can upgrade your system with limited overall downtime
When you size your multiplexor, the calculation is based on your system load, particularly the number of concurrent connections the multiplexor needs to handle.
In addition, you must:
Add CPU or a hardware accelerator for SSL if appropriate.
Add memory to the machine if the multiplexor is being configured on it.
Add capacity for load balancing and redundancy, if appropriate.
One or more of each type of machine should still handle peak load without a substantial impact to throughput or response time when you plan for redundancy in your deployment.
In a one-tiered architecture, there is no separation between access and data layers. The Instant Messaging server, multiplexor, and sometimes the Directory server are installed in one layer. The following figure illustrates the idea.
One-tiered architectures have lower up-front hardware costs than two-tiered architectures. However, if you choose a one-tiered architecture, you need to allow for significant maintenance windows.
To size a one-tiered architecture:
Add CPU for SSL, if necessary.
Add more disks for the increased number of client connections.
Add more disks for each multiplexor.
For specific instructions on sizing Instant Messaging components in one-tiered or two-tiered architectures, contact your Sun Client Services representative.
Instant Messaging supports the use of load balancers located in front of the Instant Messaging multiplexors. However, you cannot currently use load balancers between the Instant Messaging multiplexors and the Instant Messaging server.
When deploying Instant Messaging as part of a Portal Server/Secure Remote Access deployment, you can locate load balancers between the Secure Remote Access gateway and the Instant Messaging multiplexors.
If you just need security for the client connection, and not HTTP tunneling, consider using SSL instead of Secure Remote Access. You can configure a secure Instant Messaging client connection by enabling SSL on the multiplexors and locating them outside the firewall.
This section provides example resource distributions and recommended sizing information for the following two Instant Messaging deployment types:
For a small Instant Messaging deployment with the server and multiplexor on a single server having 10,000 users with the following profile:
30 percent connected/active
20 percent connected/inactive
50 percent not connected
The hardware requirements are: one or two CPUs with 300-500 MB RAM each.
For a large Instant Messaging deployment having 1,000,000 users with the following profile:
5 percent connected/active
20 percent connected/inactive
75 percent not connected
The server memory requirements are 4 GB RAM on two CPUs. The multiplexor requirement is 4 GB RAM on 16 CPUs.
This chapter describes a variety of Instant Messaging architectures. Depending on your deployment, you will need to install different components. For example, to support email notification, you need to install an SMTP server. If you do not want to support email notification, do not install an SMTP server.
For more detailed information about components that interoperate with Instant Messaging, see Components Related to Instant Messaging.
This chapter contains the following sections:
Currently, all deployment options are available on Solaris OS. A subset of the deployment options is available on the Linux operating system.
Figure 21–1 shows the basic Instant Messaging architecture.
The basic Instant Messaging architecture provides such functionality as chat, news alerts, and conferences. To provide this basic functionality, you need to install the following components:
Instant Messaging server and one or more Instant Messaging multiplexors
Instant Messaging resources
Web server such as Sun Java System Web Server
LDAP server such as Sun Java System Directory Server
In this example:
The LDAP server provides user entries for authentication and lookup.
The clients download the Instant Messaging resources from either a web server or Sun Java System Application Server
Clients always connect to the Instant Messaging server through an Instant Messaging multiplexor.
Figure 21–2 shows the interaction of the software components in the authentication process of a basic architecture of Instant Messaging. The focus is on the flow of authentication requests. An explanation of the steps in this process follows the figure.
The authentication process in a basic architecture works as follows:
End user accesses the Instant Messenger applet URL from a browser and chooses a method to invoke the client.
Java Web Start or the Java plugin downloads the necessary Instant Messenger resource files and starts Instant Messenger.
The login window appears and the end user enters the login name and password. The login data is sent to the Instant Messaging server through the multiplexor.
The Instant Messaging server communicates with the LDAP server to authenticate the end user and to request end-user information, such as contact lists or subscriptions.
When the end-user authentication is complete, the Instant Messaging main window appears, displaying the contact list for the end user. The end user can now start and participate in Instant Messaging sessions with the other end users.
You can deploy Instant Messaging to support email notification to offline users, as well as Instant Messaging based notification of calendar events to users.
An Instant Messaging architecture that supports email notification and calendar alerts provides the same functionality as Basic Instant Messaging Architecture. To provide this functionality, you need to include the components listed in Basic Instant Messaging Architecture. To support email alerts, you also install an SMTP server such as Sun Java System Messaging Server. To support calendar alerts, you also install Sun Java System Calendar Server.
To enable email notification, you are prompted to identify the SMTP server to use with Instant Messaging during installation. If you do not have an SMTP server installed, you must install one before installing the Instant Messaging software. Figure 21–3 shows Instant Messaging with email notification enabled on the network.
If you do not have Calendar Server installed, you must install it before installing the Instant Messaging software. Figure 21–4 shows Instant Messaging with calendar notification enabled on the network.
Authentication flow in this architecture is the same as in a basic deployment. See Authentication in a Basic Architecture for more information.
In this example:
The LDAP server provides user entries for authentication and lookup.
The Instant Messaging server forwards messages intended for offline users to the SMTP server. The SMTP server then sends the message as an email to the user’s mailbox.
The clients download the Instant Messaging resources from a web server (or application server).
Clients always connect to the Instant Messaging server through an Instant Messaging multiplexor.
In this example:
The LDAP server provides user entries for authentication and lookup.
The Event Notification Server (ENS) sends notifications of calendar events to the Instant Messaging server which then forwards the notification on to the appropriate end user.
The clients download the Instant Messaging resources from a web server (or application server).
Clients always connect to the Instant Messaging server through an Instant Messaging multiplexor.
You can deploy Instant Messaging to use Access Manager policy features and single sign-on (SSO). An Instant Messaging architecture that uses Access Manager provides the same functionality as Basic Instant Messaging Architecture. To provide this functionality, you need to install the components listed in Basic Instant Messaging Architecture and also install Access Manager. In addition, you need to install the Access Manager SDK on the Instant Messaging server host.
In this architecture, Instant Messaging uses the directory to search for users but not to authenticate or authorize them. Instead, Access Manager is responsible for authenticating and authorizing users.
Figure 21–5 shows the Instant Messaging Access Manager architecture.
In this example:
The LDAP server provides user entries.
The web server (can also be an application server, which includes a web server) downloads the Instant Messaging resources via a browser to the clients. The resources are basically the client.
Clients always connect through a multiplexor.
Instant Messaging related services provided by the Access Manager include the presence service and the Instant Messaging service.
The web server can be used to access the Access Manager administration interface, which manages the identity-based services for the Instant Messaging deployment. The Web server for Access Manager can be the same as the one that serves the Instant Messaging resources. See the Access Manager documentation for more details.
The Access Manager SDK provides the API used by the Instant Messaging server to interact with the Access Manager.
Figure 21–6 illustrates the authentication process used by the Instant Messaging software in collaboration with Portal Server and Access Manager components in a single sign-on environment. As with Figure 21–2, this figure focuses on the flow of authentication requests. An explanation of the steps in this process follows the figure.
The authentication process of the Instant Messaging server in this deployment within a single sign-on environment works as follows:
The end user logs in to the Access Manager server by entering the URL in a web browser.
The Access Manager software authenticates the end user and returns a session token.
The session token is what enables single sign-on to work. This token is provided as an applet parameter and is used throughout the authentication process. End users are not asked for their credentials again as long as the session token is present.
End user accesses the Instant Messenger applet URL from a browser and chooses a method to invoke the client.
The browser invokes Java Web Start or the Java plugin as appropriate.
Java Web Start or the Java plugin downloads the necessary Instant Messenger resource files and starts Instant Messenger.
Instant Messenger requests authentication to the Instant Messaging server using the session token.
The Instant Messaging server asks Access Manager to validate the session token. If the session is valid, Instant Messenger displays the end user’s contact list and the end user can then use Instant Messenger services: chat, alerts, polls, etc.
The Instant Messaging server must query LDAP directly to get or set end-user information, such as contact lists or subscriptions.
You can deploy Instant Messaging to support message archiving and to have basic Instant Messaging functionality through the Portal Desktop. An Instant Messaging architecture that provides for this functionality also provides the same functionality as Basic Instant Messaging Architecture. In addition, the Instant Messenger client is made available to end users through the Portal Server desktop. To provide this functionality, you need to install the components listed in Basic Instant Messaging Architecture and also install Portal Server and Access Manager.
This architecture uses the directory and Web servers accessed by the Access Manager. You do not need to install additional instances of those servers. In addition, because this architecture requires Access Manager, all the features described in Instant Messaging Access Manager or SSO Architecture are also available.
Figure 21–7 shows the Instant Messaging Portal-based architecture.
In this example:
The LDAP server provides user entries.
The web server (can also be an application server, which includes a web server) downloads the Instant Messaging resources via a browser to the clients. The resources are basically the client.
Clients are always connect through an Instant Messaging multiplexor.
Instant Messaging related services provided by Access Manager include the presence service and the Instant Messaging service.
The web server can be used to access the Access Manager administration interface, which manages the identity-based services for the Instant Messaging deployment. The web server for both Access Manager and Portal Server can be the same as the one that serves the Instant Messaging resources. See the Sun Java System Access Manager and Sun Java System Portal Server documentation for more details.
The Access Manager SDK provides the API used by the Instant Messaging server to interact with the Access Manager.
The Instant Messaging channel is supported by Portal Server and enables users to access Instant Messenger from the Portal Desktop.
Portal Server provides archive functionality that allows you to save instant messages sent through the deployment.
Figure 21–8 illustrates authentication process used by the Instant Messaging software in collaboration with Portal Server and Access Manager components in a single sign-on environment. As with Figure 21–2, this figure focuses on the flow of authentication requests. An explanation of the steps in this process follows the figure.
The authentication process of the Instant Messaging server in this deployment within a single sign-on environment works as follows:
The end user logs in to the Portal Server by entering the URL in a web browser.
The Access Manager software authenticates the end user and returns a session token and the Portal Server downloads the Desktop for the end user. The Portal Server Desktop is displayed in the end user’s browser. See Step 6 for an explanation of the session token.
The end user clicks the Instant Messenger URL link from the Instant Messaging channel on the Desktop.
Java Web Start or the Java plugin downloads the necessary Instant Messenger resource files and starts the Instant Messenger.
Instant Messenger requests authentication to the Instant Messaging server using the session token.
The session token is what enables single sign-on to work. This token is provided as an applet parameter and is used throughout the authentication process. End users are not asked for their credentials again as long as the session token is present.
The Instant Messaging server asks Access Manager to validate the session token. If the session is valid, Instant Messenger displays the end user’s contact list and the end user can then use Instant Messenger services: chat, alerts, polls, and so forth.
The Instant Messaging server must query LDAP directly to get or set end-user information, such as contact lists or subscriptions.
You can deploy Instant Messaging and enable all the features listed in this section by installing:
The following components before you install Instant Messaging:
Directory Server (during Access Manager installation)
Web Server (during Access Manager installation)
Access Manager
Portal Server
Calendar Server
Messaging Server
Instant Messaging resources on the Web Server host
Access Manager SDK on the Instant Messaging server host
You also need to configure the Access Manager Instant Messaging Service on the Access Manager host.
This section explains variations to the deployment scenario described in Basic Instant Messaging Architecture. For example, you can install the various required servers and components in the following physical configurations:
Instant Messaging Physical Deployment Example: Web Server on Separate Host
Instant Messaging Physical Deployment Example: Multiplexors on Separate Hosts
Instant Messaging Physical Deployment Example: Multiple Instant Messaging Hosts
Any combination or all of the above
These variations can be applied in any of the architectures described in this chapter. You might choose to include them based on your deployment requirements.
Figure 21–9 shows a configuration consisting of the Instant Messaging server and multiplexor installed on the same host. The web server is installed on a separate host. The Instant Messaging resources are also present on the web server host. Use this configuration when there is an existing instance of a web server and an LDAP server, and you do not want to install other applications on these hosts.
Figure 21–10 shows a configuration consisting of two multiplexors installed on two separate hosts. The Instant Messaging server is installed on a different host. This configuration enables you to place a multiplexor outside your company’s firewall. Installing multiplexors on multiple hosts distributes the load of the Instant Messaging server across multiple systems.
The multiplexor can be resource-intensive, so putting it on a separate host can improve the overall performance of the system.
Figure 21–11 shows a configuration consisting of two Instant Messaging servers. This configuration is used when the site contains multiple administrative domains. The server configuration on each Instant Messaging server host has to be set up so that end users on one Instant Messaging server can communicate with end users on other Instant Messaging servers.
This chapter describes how to plan for and protect the various components of your Instant Messaging deployment.
This chapter contains the following sections:
This section describes how to secure components in your Instant Messaging deployment.
Instant Messaging supports the following levels of security:
No Security. Communication is all plain text from client through the multiplexor to the server.
Legacy SSL. Secure communication between client and multiplexor, and plain text between multiplexor and server. (This is only relevant if you are using the multiplexor).
startTLS. End-to-end secure communication between client and server. If you enable the multiplexor, it does not process any data but instead passes it on to the server.
The startTLS option enables end-to-end encryption (the communication between client-multiplexor-server is all in encryption form), while legacy SSL enables encryption between the Instant Messenger client up to the multiplexor: the communication between multiplexor and server is in plain text (though in a proprietary protocol). Use startTLS if you require a higher level of security. If you use startTLS, you do not need an alternate means of securing the multiplexor-to-server communication (it will be secure).
Instant Messaging supports TLS (Transport Layer Security) and legacy SSL (Secure Sockets Layer) for secure communications. Instant Messaging uses a startTLS extension to the Transport Layer Security (TLS) 1.0 protocol for client-to-server and server-to-server encrypted communications and for certificate-based authentication between servers. In addition, Instant Messaging supports a legacy implementation of the SSL protocol (version 3.0) for encrypted communications between the Instant Messenger client and the multiplexor.
When planning for SSL for Instant Messaging, keep in mind the following:
You can secure the Instant Messaging deployment by enabling SSL on the web container port (either Web Server or Application Server) and accessing Instant Messaging functionality by using the XMPP/HTTP Gateway (httpbind). You can also enable SSL at the mutliplexor and the Instant Messaging client can access Instant Messaging functionality directly through the mutliplexor.
The Instant Messenger client uses only legacy SSL if it is enabled at the multiplexor. In this case, the Instant Messenger client does use startTLS of the server.
Instant Messaging does not support end-to-end encryption using legacy SSL, so the communications between the Instant Messaging server and multiplexor is in the clear if the Instant Messaging server and multiplexor are deployed on multiple nodes and SSL is enabled at the multiplexor. If you want end-to-end encryption, you must use startTLS.
Set the proper file and directory permissions for Instant Messaging configuration files (iim.conf and httpbind.conf in the /etc/opt/SUNWiim/default/config directory). [Instant Messaging runs as the user specified in the iim.conf file. This user needs read access to the file. If you use httpbind, the user that runs the web container should be able to access the Instant Messaging directory path and configuration file. Typically , if the deployment of Instant Messaging includes Access Manager or Portal Server, the default user is root. ] When you create additional Instant Messaging server/multiplexor instances manually, you need to also ensure that the file and directory permissions are correct. The default installation sets the file/directory permissions. The default instance directory (/var/opt/SUNWiim/default) has the following permissions:
drwx------ 5 root other 512 Oct 16 14:24 default |
Take care when enable Instant Messaging monitoring as this exposes server statistics that could be considered security issues. The default configuration does not enable the monitoring feature. You enable this property through the iim.conf file.
Enable debug logging only when needed, as this impacts overall system performance. Though passwords are not logged, the protocol communication between users is logged, which could be a potential security issue.
When you enable startTLS, use a single server certificate for both client-to-server and server-to-server communication.
The Instant Messaging server should be able to connect to Access Manager if identity integration is enabled. Similarly, Instant Messaging server needs access to the Portal Server search when deployed with Portal Server. Additionally, an Instant Messaging deployment that leverages LDAP needs proper authentication for access. Refer to each product's individual documentation to understand how to secure each component.
The Instant Messaging default installation supports only SASL Plain. If you require a higher level of security, use the Instant Messaging public Service Provider Interface. SASL Plain and jabber:iq:auth are two forms of plain text authentication. That is, in both, the password is sent in the clear (encoded perhaps, but still clear text) and so both are insecure forms of authentication. Nevertheless, this is an issue only if end-to-end encryption (through startTLS for direct socket connection, and HTTPS for httpbind) is not enabled. If end-to-end encryption is enabled, the password is not “seen” in the clear on the network.
Alternatively, if you do not want to transmit passwords in the clear (even if over an encrypted stream), use the Instant Messaging SPI for plugging in authentication mechanism's at the server side through SASLRealm. You can implement custom SASL mechanisms as implementations but you will then need an Instant Messaging client that supports this custom mechanism. The Sun Java System Instant Messaging client supports only SASL Plain, jabber:iq:auth (both insecure).
For more information, see Chapter 12, Securing Instant Messaging Using TLS and Legacy SSL, in Sun Java System Instant Messaging 7.2 Administration Guide.
The XMPP/HTTP Gateway (httpbind) provides Instant Messaging access to XMPP-based clients, such as HTML based clients, and clients that are behind firewalls that allow HTTP traffic only and don't permit XMPP traffic. The gateway proxies Instant Messaging traffic to the XMPP server on behalf of HTTP clients.
When planning to use the XMPP/HTTP Gateway, keep in mind the following:
Use port 5222 at the Gateway if the Gateway is communicating to the server through a multiplexor. Also, use port server port 5269 if no multiplexor is involved. You can specify port 5222 or 5269 in the httpbind.conf file.
The XMPP/HTTP gateway supports both startTLS and legacy SSL. If you want legacy SSL support, enable SSL on the Web Server port. However, if the XMPP/HTTP gateway configuration points to the multiplexor instead of the server, disable legacy SSL at the multiplexor. Additionally, if you want startTLS support, enable startTLS on the server and all communications will be encrypted.
Do not expose the Instant Messaging server to direct access. In a typical deployment scenario you would locate the multiplexor in the DMZ, and open the multiplexor to server communication port (45222 usually) in the second firewall.
Instant Messaging has the capability to archive instant messages for later retrieval and searching. If you enable the email archive, you need to decide which administrators will receive email containing archived instant messages. You can configure a separate list of administrators to receive polls, news, conference, alerts, or chat sessions. You can also configure Instant Messaging to use the extended RFC 822 header. Doing so allows mail clients to filter messages based on the header content. If you do enable the Portal archive, you can decide which administrators can access the Portal archive database.
For more information, see Chapter 18, Managing Archiving for Instant Messaging, in Sun Java System Instant Messaging 7.2 Administration Guide.
User authentication enables your users to log in through their Instant Messaging clients to chat and access other features of Instant Messaging.
User IDs and passwords are stored in your LDAP directory. Password security criteria, such as minimum length, are determined by directory policy requirements. Password security criteria is not part of Instant Messaging administration. See the Directory Server documentation to understand directory server password policies:
http://docs.sun.com/coll/1316.1
All deployments of Instant Messaging require a directory server. In a deployment without Access Manager, the Instant Messaging server uses the directory server to perform end-user authentication and to search for end users. For various ways to secure the directory, see the Directory Server documentation.
In a deployment with Portal Server, the Instant Messaging server uses the directory used by Portal Server. When installed in an Access Manager deployment environment, the Instant Messaging server uses the directory used by the Access Manager to search for end users, and not for end-user authentication. In an Access Manager deployment, Access Manager performs the authentication.
If you use an LDAP directory to maintain your user namespace, the default configuration makes the following assumptions regarding the schema used by this directory:
End user entries are identified by the inetOrgPerson object class.
Group entries are identified by the groupOfUniqueNames or groupofURLs object class.
Instant Messenger user ID attribute of an end user is provided by the uid attribute (from inetOrgPerson objectclass).
The email address of an end user is provided by the mail attribute.
The display name of an end user or group is provided by the cn attribute.
The list of members of a group is provided by the uniqueMember attribute (groupOfUniqueNames object class).
Some user attributes might contain confidential information. Ensure that your directory access control is set up to prevent unauthorized access by non-privileged users.
Instant Messaging needs to be able to search the directory to function correctly. You need to ensure that your directory is configured to be searchable by anonymous users. If your directory is not readable or searchable by anonymous users, you must take configuration additional steps.
For more information, see Chapter 11, Managing Instant Messaging’s LDAP Access Configuration, in Sun Java System Instant Messaging 7.2 Administration Guide.
Instant Messaging provides the ability to control access to Instant Messaging features and preserve end-user privacy.
Site policies specify end-user access to specific functionality in Instant Messaging. When developing your site policies for Instant Messaging, keep in mind the following questions:
Can users access the presence status of other end users?
Can users send alerts to other end users?
Do you want users to save properties on the server?
Who do you want to be able to create and manage conference rooms?
Who do you want to be able to create and manage news channels?
For more information, see Chapter 17, Managing Instant Messaging and Presence Policies, in Sun Java System Instant Messaging 7.2 Administration Guide.
Different sites using Instant Messaging server have different needs in terms of enabling and restricting the type of access end users have to the Instant Messaging service. The process of controlling end user and administrator Instant Messaging server features and privileges is referred to as policy management. You choose from two methods of policy management: through access control files or through Sun Java System Access Manager.
Managing Policies Using Access Control Files. The access control file method for managing policies allows you to adjust end-user privileges in the following areas: news channel management, conference room management, the ability to change preferences in the User Settings dialog, and ability to send alerts. It also allows specific end users to be assigned as system administrators.
Managing Policies using Sun Java System Access Manager. This method gives you control of the same privileges available with the access control file method; however, it additionally allows more fine-tuned control over various features, such as the ability to receive alerts, send polls, receive polls, and so forth. Furthermore, managing policies using Sun Java System Access Manager gives you finer-tuned control over privileges.
If your deployment does not include Access Manager, you must use the access control file method to manage policies. If you are using Access Manager with Instant Messaging, and you have installed the Instant Messaging and Presence services components, you can use either of the policy management methods. Managing policies using Access Manager is a more comprehensive method. One advantage of this method is that it allows you to store all end-user information in the directory.
For more information, see Chapter 17, Managing Instant Messaging and Presence Policies, in Sun Java System Instant Messaging 7.2 Administration Guide.