Highly Availabile (HA2)

Itential HA2 Architecture

A Highly Available Architecture (HA2) is an Itential architecture where all of the components are redundant and can gracefully tolerate at least 1 (one) catastrophic failure. This architecture is the recommended architecture for production environments and testing environments. The IAP application performs many reads and writes against the database and is sensitive to great latencies. All components must be installed in the same data center. All components must have authentication enabled.

The minimum HA2 architecture is comprised of 9 VMs broken down as follows:

• 2 IAP servers
• 3 MongoDB servers
• 3 Redis servers
• 1 IAG server (Optional)

Highly Available Itential Enterprise (IAP)

IAP instances communicate with one another through Redis and share data via MongoDB. Simply adding a new IAP node and pointing it to the correct MongoDB and Redis is sufficient to to achieve high availability. As IAPs are added and configured they are enabled to perform work.

IAPs must have the following configurations:

• MongoDB connection strings must contain a reference to all members of the replica set
• Redis configurations must specify the list of all known Redis Sentinels and their Sentinel username and password. Connections to an HA Redis actually occur through the Sentinels and not directly to Redis.

Highly Available MongoDB

MongoDB clusters operate in a primary/secondary model where data written to the primary will replicate to the secondary. If a primary MongoDB node fails the replica set will detect this failure and force an election for a new primary. During this time the replica set may not accept reads and writes until the new primary is selected, usually after a few seconds. Once it is finished and a new primary is identified the IAP application will resume normal operation. Operators of Itential do not have to do anything during this election.

Itential’s MongoDB cluster must have the following requirements:

• All replica set members must be defined in the IAP config.
• Authentication between the replica members must be done with either a shared key or X.509 certificate.
• The database must have an admin user able to perform any operation.
• The database must have an “itential” user that is granted the least amount of privileges required by the IAP application. IAP must be configured to use this user account.

Highly Available Redis

Redis clusters operate in a primary/secondary model where data written to the primary will replicate to the secondary. If a primary Redis node fails the replica set will detect this failure via the Redis Sentinels and force an election for a new primary. During this time the replica set may not accept reads and writes until the new primary is selected, usually after a few seconds. Once it is finished and a new primary is identified the IAP application will resume normal operation. Operators of Itential do not have to do anything during this election.

Itential’s Redis cluster must have the following requirements:

• All Redis nodes must be defined in the IAP profile configuration.
• Authentication between the replica members is done with users defined in the Redis config file.
• Redis must have an admin user able to perform any operation.
• Redis must have an “itential” user that is granted the least amount of privileges required by the application. IAP must be configured to use this user account.
• Redis must have a replication user that is granted the least amount of privileges required by the replication process.
• Redis Sentinel must be included to monitor the Redis cluster and musts be colocated with Redis.
• Redis Sentinel must have an admin user able to perform any Sentinel task.
• Redis nodes must maintain a low latency connection between nodes to avoid replication failures.