One of the most common misconceptions about the level of high availability provided by SQLFire is the client configuration. A lot of times, when people see the client connection string defined with a single IP, they assume that to mean that client will only communicate with that one SQLFire cluster host and deem that to be a single point of failure in the SQLFire data grid.
In reality however, SQLFire is based on multi-faced shared nothing architecture. One of its tenants is transparent failover at the protocol level.
When the client connects to the SQLFire locator, that locator serves as a facade for all other SQLFire data nodes. Locator also balances client requests to all SQLFire servers available in a cluster; so multiple connection requests to the same locator may result in connections to different data servers. (more on SQLFire failover and redundancy)
So, even though the client is configured with a single host and port, in case of a failure of one of the data nodes, the locator to which the client connects will redirect its connections to the next available cluster tenant.
Furthermore, in case of failure of the locator itself, the client driver internally will redirect its data connections to the next available locator and continue benefiting from the same load balancing services.
In short, the locator connection on the client is only a control connection to fetch server information. This is done dynamically whenever the cluster information is updated, as to assure that all cluster node information is always up to date.
This entire process is transparent to the client application and does not require changes to the connection string.
In short, to achieve highest level of HA, the recommended configuration for SQLFire cluster should:
- Configure multiple locators in addition to data servers
- Configure locators on a standalone machines, not on the same host as data server
- Configure clients to connect to one of the standalone locators to achieve best durability of your connections
While it is possible to run SQLFire cluster without locator, for production environments the recommended configuration should include at least one standalone locator.
Separating locator from the SQLFire data servers, further increases the HA of the overall system. Since locators do not host data and have very little activity, they are unlikely to fail. Redundancy among locators themselves will further alleviate possibility of locator failures.
For detail description of connecting to a SQLFire cluster with the thin client please see on-line documentation