What is the difference between hot-hot deployment, hot-warm deployment and hot-cold deployment?
Article ID: KB0089980
Updated On:
| Products | Versions |
|---|---|
| TIBCO Enterprise Message Service | - |
| Not Applicable | - |
Description
Resolution:
In hot-warm deployment TIBCO EMS fault tolerant servers must have access to a shared state, and they are deployed as a primary and secondary pair.
When a backup server assumes the role of the primary server during failover, clients attempt to reconnect to the backup server (that is, the new primary). To enable a client to reconnect, you must specify the URLs of both servers when creating a connection. Specify multiple servers as a comma-separated list of URLs. Both URLs must use the same protocol (either tcp or ssl).
The client attempts to connect to each URL in the order listed. If a connection to one URL fails, the client tries the next URL in the list. The client tries the URLs in sequence until all URLs have been tried. If the first failed connection was not the first URL in the list, the attempts wrap to the start of the list (so each URL is tried).
If none of the attempts succeed, the connection fails.
For example, to identify the first server as tcp://server0:7222, and the second
server as tcp://server1:7344 (if first server is not available), you can specify:
serverUrl = tcp://server0:7222, tcp://server1:7344
Hot-hot deployment would mean that both servers can accept client connections at the same time, which is not supported by EMS at the moment.
Currently, we provide fault tolerance support for EMS both on “Hot-Warm” and “Hot-Cold” setup.
By referring to “Hot-Cold” configuration, we mean “High Availability”. HA is a hot-cold setup, which typically requires more time to failover, though the failover time mainly depends on the clustering software. When using clustering software like Veritas, the secondary server is started by the clustering software after its remounted the shared store to the secondary host. The newly started EMS server then initializes its state from the backend store. To achieve EMS HA, hardware for connected storage (e.g. SAN) and clustering software (e.g. Veritas) are required.
In the event of an EMS server failure, the cluster service will restart the service on the same node. If it’s the node hosting EMS service that fails, the cluster service will move the entire resource group to another node in the cluster. That is the EMS service will be started on the other node.
So that, If you are using HOT-COLD setup (only one EMS server instance running at a time), you have to use the server URL in your client application as:
tcp://<hostname>:<port>,tcp://<hostname>:port to ensure that the client reconnects to the new server instance if the old server instance goes down.
If you are using JNDI lookup, you have to set the URL in the same way in the factories.conf as well. You have to define your client reconnection logic like reconnect attempt count and reconnect attempt delay in the factories.conf as well as per your existing setup.
In hot-warm deployment TIBCO EMS fault tolerant servers must have access to a shared state, and they are deployed as a primary and secondary pair.
When a backup server assumes the role of the primary server during failover, clients attempt to reconnect to the backup server (that is, the new primary). To enable a client to reconnect, you must specify the URLs of both servers when creating a connection. Specify multiple servers as a comma-separated list of URLs. Both URLs must use the same protocol (either tcp or ssl).
The client attempts to connect to each URL in the order listed. If a connection to one URL fails, the client tries the next URL in the list. The client tries the URLs in sequence until all URLs have been tried. If the first failed connection was not the first URL in the list, the attempts wrap to the start of the list (so each URL is tried).
If none of the attempts succeed, the connection fails.
For example, to identify the first server as tcp://server0:7222, and the second
server as tcp://server1:7344 (if first server is not available), you can specify:
serverUrl = tcp://server0:7222, tcp://server1:7344
Hot-hot deployment would mean that both servers can accept client connections at the same time, which is not supported by EMS at the moment.
Currently, we provide fault tolerance support for EMS both on “Hot-Warm” and “Hot-Cold” setup.
By referring to “Hot-Cold” configuration, we mean “High Availability”. HA is a hot-cold setup, which typically requires more time to failover, though the failover time mainly depends on the clustering software. When using clustering software like Veritas, the secondary server is started by the clustering software after its remounted the shared store to the secondary host. The newly started EMS server then initializes its state from the backend store. To achieve EMS HA, hardware for connected storage (e.g. SAN) and clustering software (e.g. Veritas) are required.
In the event of an EMS server failure, the cluster service will restart the service on the same node. If it’s the node hosting EMS service that fails, the cluster service will move the entire resource group to another node in the cluster. That is the EMS service will be started on the other node.
So that, If you are using HOT-COLD setup (only one EMS server instance running at a time), you have to use the server URL in your client application as:
tcp://<hostname>:<port>,tcp://<hostname>:port to ensure that the client reconnects to the new server instance if the old server instance goes down.
If you are using JNDI lookup, you have to set the URL in the same way in the factories.conf as well. You have to define your client reconnection logic like reconnect attempt count and reconnect attempt delay in the factories.conf as well as per your existing setup.
Issue/Introduction
What is the difference between hot-hot deployment, hot-warm deployment and hot-cold deployment?
Feedback
Yes
No
Powered by
