Working with Portal Server Building Modules
94
Portal Server 6 2005Q1 • Deployment Planning Guide
As stated earlier, a building module consists of a a Portal Server instance, a
Directory Server master replica for profile reads and a search engine database. As
such, at least two building modules are necessary to achieve NSPOF, thereby
providing a backup if one of the building modules fails. These building modules
consist of four CPUs by eight GB RAM.
When the load balancer detects Portal Server failures, it redirects users’ requests to
a backup building module. Accuracy of failure detection varies among load
balancing products. Some products are capable of checking the availability of a
system by probing a service involving several functional areas of the server, such
as the servlet engine, and the JVM. In particular, most vendor solutions from
Resonate, Cisco, Alteon, and others enable you to create arbitrary scripts for server
availability. As the load balancer is not part of the Portal Server software, you must
acquire it separately from a third-party vendor.
Multi-master replication (MMR) takes places between the building modules. The
changes that occur on each directory are replicated to the other, which means that
each directory plays both roles of supplier and consumer. For more information on
MMR, refer to the Directory Server 6 Deployment Guide.
NOTE
The Access Manager product requires that you set up load
balancing to enforce sticky sessions. This means that once a session is
created on a particular instance, the load balancer needs to always
return to the same instance for that session. The load balancer
achieves this by binding the session cookie with the instance name
identification. In principle, that binding is reestablished when a
failed instance is decommissioned. Sticky sessions are also
recommended for performance reasons.
NOTE
In general, the Directory Server instance in each building module is
configured as a replica of a master directory, which runs elsewhere.
However, nothing prevents you from using a master directory as
part of the building module. The use of masters on dedicated nodes
does not improve the availability of the solution. Use dedicated
masters for performance reasons.
Содержание Portal Server 6 2005Q1
Страница 8: ...8 Portal Server 6 2005Q1 Deployment Planning Guide...
Страница 10: ...10 Portal Server 6 2005Q1 Deployment Planning Guide...
Страница 12: ...12 Portal Server 6 2005Q1 Deployment Planning Guide...
Страница 20: ...Sun Welcomes Your Comments 20 Portal Server Secure Remote Access 6 2005Q1 Administration Guide...
Страница 36: ...A Typical Portal Server Installation 36 Portal Server 6 2005Q1 Deployment Planning Guide...
Страница 50: ...Proxylet 50 Portal Server 6 2005Q1 Deployment Planning Guide...
Страница 78: ...SRA Sizing 78 Portal Server 6 2005Q1 Deployment Planning Guide...
Страница 132: ...Identity and Directory Structure Design 132 Portal Server 6 2005Q1 Deployment Planning Guide...
Страница 142: ...Configuration Files 142 Portal Server 6 2005Q1 Deployment Planning Guide...
Страница 152: ...Tuning Parameters for etc system 152 Portal Server 6 2005Q1 Deployment Planning Guide...
Страница 158: ...Portal Server on an Application Server Cluster 158 Portal Server 6 2005Q1 Deployment Planning Guide...
Страница 178: ...Portal Design Task List 178 Portal Server 6 2005Q1 Deployment Planning Guide...
Страница 180: ...Comparison of Solaris and Linux Path Names 180 Portal Server 6 2005Q1 Deployment Planning Guide...
Страница 182: ...182 Portal Server 6 2005Q1 Deployment Planning Guide...
Страница 192: ...Section X 192 Portal Server 6 2005Q1 Deployment Planning Guide...