IBM BS029ML Self Help Guide - Page 60
Database considerations, 2.7.1 WebSphere Portal Server database disclaimer, 2.7.2 Database domains
View all IBM BS029ML manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 60 highlights
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