a
Master-Slave Configuration
The Master-Slave configuration of Presentation Server instances is useful to reduce load on the business logic, as well as to provide resiliency and scalability.
The Master-Slave configuration of the Presentation Server cluster is specified in the properties of Server nodes under Servers in the Explorer window. For more information see Set up Server Details.
If a Master Server fails (doesn't respond after 10 connection attempts from a slave), the attached Slave Servers abandon it and connect to the next Master Server in the cluster. This process is transparent to the Clients connected to the Slave Servers.
If the administrator tries to make changes to the configuration and one of the Servers has failed, then the administrator is notified which machines within the cluster were not able to be updated. To recover from this situation, restart the failed Server(s) and click Update again to save the changes.
For more information: see the Note on replicating applications.
The effect using a master-slave configuration of servers has on the back end business logic load depends on how the data is being obtained by the datapools. If the datapools are "pulling" data in, i.e. polling, then you want to limit the number of machines making requests for data updates to the back end. This is especially true if the datapools are polling for data frequently. To reduce this load, use a master-slave setup. The master Presentation Server makes the poll for data, and then takes care of pushing that data to all slaves attached to it.
If data is being pushed into datapools, e.g. http streaming, JMS and socket, then the advantages of using master-slave setup are less.