Open topic with navigation
The diagram below represents a DAH run in non-mirror mode. The DAH distributes actions to several different IDOL Servers.
DAH system architecture (non-mirror mode)
The DAH uses either combinator or distributor virtual databases (VDBs) to distribute the actions to one or more specific IDOL Server databases. The VDBs can map to one or more IDOL Server databases, or to other virtual databases that you set up for the DAH. The way a VDB forwards actions depends on its type.
A combinator virtual database forwards actions to all the databases that it represents. The VDB collates and sorts the results before it returns them.
Distributor virtual databases map to a set of identical databases that contain identical data. You determine how the VDB distributes actions by using the
DistributionMethod configuration parameter in the DAH configuration file. You can use one of the following methods:
Load balancing. The distributor VDB assigns each action to just one of the databases that it maps to. It uses a cumulative predictive algorithm to spread the action load efficiently. When this database responds with a result, the DAH forwards it to the client.
If an IDOL Server stops responding for any reason (for example, because of a hardware failure or network outage), the DAH marks it as down. DAH assigns incoming actions only to the available IDOL Servers, which saves the time that it takes to attempt to communicate with the failed IDOL Server.
Failover. The distributor VDB forwards incoming actions to the first database that you list in the virtual database
MapsTo parameter. If this database stops responding for any reason (for example, because of a hardware failure or network outage), the DAH marks it as down. The DAH switches to the next database (the second one listed for the
MapsTo parameter) and so on, and seamlessly continues to service client actions.
The DAH periodically checks IDOL Servers that are down. If it finds that an IDOL Server has come online again (for example, because the hardware has been rebooted or the network connection repaired), it adds it back into the list of active IDOL servers.
For load balancing, this IDOL Server becomes a valid choice for actions again.
For failover, the first IDOL Server takes over as the sole destination for actions (because it has precedence over the IDOL Server that is currently serving results).