Table of Contents
Advertisement
bottleneck, as this will have the potential to impact the overall performance of WebSphere
Portal Server.
When using LDAP over SSL (LDAPS), care should be taken when utilizing a load balancer as
described above. LDAPS not only establishes a JNDI context against the target server, but
also implements SSL handshaking between the client and target server (including key
negotiation). Whether the load balancer simply just redirects the SSL connection to the target
directory server or whether the SSL connection is terminated at the load balancer, with the
load balancer re-negotiating a secondary SSL connection to the target directory server,
needs to be decided.
LDAP directory servers and firewalls
Problems can arise if a firewall is placed between WebSphere Portal Server and the chosen
LDAP directory server. Under such circumstances, authentication can appear to stall after a
long period of inactivity. This typically manifests itself in the morning after a night of inactivity,
whereupon users may wait up to 30 minutes before authenticating into the Portal solution
(unless the Portal is restarted or the LDAP Reuse Connection parameter is disabled from the
WebSphere administrative console and WMM connection pooling mechanism is disabled).
After this initial period, subsequent users are authenticated in the normal fashion.
The origin of this problem is not with WebSphere Portal Server or the underlying WebSphere
Application Server instance, but with the firewall idle timeout. System Administrators should
ensure that the tcp_keepidle system setting on each of the servers is smaller than the firewall
idle timeout. Failing this, when a client is left to idle for longer than the firewall idle timeout, a
communications error will be encountered. Usually, a keepAlive packet is sent according to
the tcp setting of tcp_keepidle.
2.7 Database considerations
The deployment of a suitable database is probably one of the single most critical factors in a
WebSphere Portal Server implementation. As several choices and combinations are
available, selecting the most optimal architecture involves careful consideration of many
factors.
2.7.1 WebSphere Portal Server database disclaimer
Details of the actual underlying data storage layouts are abstracted and hidden from the
WebSphere Portal Server administrator. The WebSphere Portal Server schema is not
published and IBM reserves the right to make modifications to the schema in future Portal Fix
Packs. Any manual manipulation of the underlying data store is strongly discouraged, to the
point that it will not be supported by IBM.
2.7.2 Database domains
With the introduction of database domains in WebSphere Portal Server V6.0.x, greater
flexibility was made possible in terms of the permissible operational architecture. A full
description of each of the database domains can be found in the WebSphere Portal Server
Version 6.0 Information Center. In addition, further information including worked examples
can be found in the WebSphere Portal Version 6 Enterprise Scale Deployment Best
Practices, SG24-7387, found at:
http://www.redbooks.ibm.com/abstracts/sg247387.html
46
IBM WebSphere Portal V6 Self Help Guide
Advertisement
Table of Contents
Troubleshooting
