Horizontally Scaling InterSystems IRIS for User Volume with Distributed Caching
InterSystems IRIS™ supports a distributed caching
architecture that scales horizontally for user volume by distributing both application logic and caching across a tier of application servers sitting in front of a data server, enabling partitioning of users across this tier. Each application server handles user requests and maintains its own database cache, which is automatically kept in sync with the data server, while the data server handles all data storage and management. Distributed caching allows each application server to maintain its own, independent working set of the data, which means that adding application servers lets you handle more users.
This architecture is enabled by the use of the Enterprise Cache Protocol (ECP), a core component of InterSystems IRIS® Data Platform™, for communication between the application servers and the data server.
The distributed caching architecture and application server tier are entirely transparent to the user and to application code. You can easily convert an existing standalone InterSystems IRIS serving data into the data server of a cluster by adding application servers..
Distributed Caching Architecture
An InterSystems IRIS instance becomes an application server by adding another instance that is configured as a data server as a remote server
, and then adding any or all of the data server’s databases as remote databases
. This allows local namespaces on the application server to be mapped to remote databases on the data server. A cluster of multiple application servers and at least one data server configured in this way works as follows:
The data server continues to store, update, and serve the data. The data server also synchronizes and maintains the coherency of the application servers’ caches to ensure that users do not receive or keep stale data, and manages locks across the cluster.
Each query against the data is made in a namespace on one of the various application servers, each of which uses its own individual database cache to cache the queries it receives; as a result, the total set of cached data is distributed across these individual caches. If there are multiple data servers, the application server automatically connects to the one storing the requested data. Each application server also monitors its data server connections and, if a connection is broken or encounters trouble, attempts to recover it.
User requests can be distributed round-robin across the application servers by a load balancer, but the most effective approach takes full advantage of distributed caching by directing users with similar requests to the same application server, increasing cache efficiency. For example, a healthcare application might group clinical users who run one set of queries on one application server and front-desk staff running a different set on another. If the cluster handles multiple applications, each application's users can be directed to a separate application server. The illustrations that follow compare a single InterSystems IRIS instance to a cluster in which user connections are distributed in this manner.
Local databases on a single InterSystems IRIS instance
Remote databases on a data server in a distributed cache cluster
The number of application servers in a cluster can be increased or reduced without affecting the operation of the cluster, so you can easily scale as needed as user volume increases. Data servers can be mirrored for high availability in the same way as single InterSystems IRIS instances, and application servers can be set to automatically redirect connections in the event of failover. (It is not necessary or even possible to mirror an application server, as it does not store any data.)
ECP is designed to automatically recover from interruptions in connectivity between the ECP application server and the ECP data server. If the connection between an application server and a data server is interrupted, the application server attempts to reestablish the connection.
If the connection is reestablished within the configured Time interval for Troubled state
timeout period, ECP restores all locks and open transactions to the state they were in prior to the interruption.
If the connection is not reestablished within the Time interval for Troubled state
timeout period, it is disabled and a <NETWORK> error is returned to all processes waiting for remote activities. The next request to the application server establishes a new ECP connection to the data server.
If the connection is not reestablished within the configured Time to wait for recovery
timeout period, the data server rolls back any open transactions involving the application server and then releases all locks it is holding on behalf of the application server.
Learning About Distributed Caching and ECP
You can learn about distributed caching and ECP using the following resources.
For further information about ECP, see the following InterSystems documentation and Developer Community articles:
InterSystems Developer Community