Itential Validated Designs

Highly Available Architecture

Overview

A Highly Available Architecture (HA2) is an Itential architecture where all of the components are redundant and can gracefully tolerate at least 1 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 datacenter. 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)

IAPs 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.

More MongoDB replication information here

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.

More Redis replication information here

Server Specs

Itential Enterprise Server

CPU64-bit x86 CPU cores16
OSRHEL
Rocky
8, 9
8, 9
RAMDDR5 DRAM 3200 Mhz64 GB
Disk
(Solid State media,ie. SSD, NVMe)
Total
/var/log/itential
/opt/itential
250 GB
100 GB
100 GB

MongoDB Server

CPU64-bit x86 CPU cores16
OSRHEL
Rocky
8, 9
8, 9
RAMDDR5 DRAM 3200 Mhz128 GB
Disk
(Solid State media,ie. SSD, NVMe)
Total
/var/log/mongo
/data
1000 GB
150 GB
850 GB

Redis Server

CPU64-bit x86 CPU cores8
OSRHEL
Rocky
8, 9
8, 9
RAMDDR5 DRAM 3200 Mhz32 GB
Disk
(Solid State media,ie. SSD, NVMe)
Total
/var/log/redis
100 GB
100 GB

IAG Server

CPU64-bit x86 CPU cores16
OSRHEL
Rocky
8, 9
8, 9
RAMDDR5 DRAM 3200 Mhz32 GB
Disk
(Solid State media,ie. SSD, NVMe)
Total50 GB

Hardware & Hypervisor Configurations

Processor

The processor specification requirement is as follow:

  • Second generation or better Intel Xeon Platinum 8000 series processors.
  • Third generation or better AMD EPYC 7000 series processors.

Memory

The memory specification requirement is as follow:

  • DDR5 DRAM 3200 Mhz or higher

Storage

The storage performance requirement in IOPS (16 kiB) is as follows:

  • 20000+ IOPS
  • Non-spinning media (i.e. SSD, NVMe)

Network

The network speed requirement is:

  • 10 Gbps or higher

Note: In some instances, adding additional dedicated interfaces that are focused on routing specific traffic to specific external systems can be explored further. This routing of traffic would be configured at the OS-level (custom interfaces and routes) and require the system administrator to manage this. An example would be separating NSO traffic from Redis/Mongo destined traffic.

Hypervisor/Host OS Settings

These settings are strongly recommended for high load applications of IAP:

  • CPU affinity settings or similar functionality to prevent CPU starvation
  • Full Memory Reservation
  • One physical CPU per VM is preferred
  • Huge pages for memory support enabled
    • Except MongoDB
      Note: MongoDB discourages the utilization of Transparent Huge Pages
  • Memory compression disabled
  • Minimal CPU Allocation settings for scheduler according to CPU clock
    • Example: assuming an IAP VM on a server capable of 2.5GHz nominal speed: CPU clock reservation = 16vCPU * x 2.5GHz

Note: Please follow Hypervisor recommendations when performing CPU reservations. In most cases the total of all CPU reservations for all VMs on a host cannot be more than 90% of the host capacity as 10% is reserved by the host itself.

Ports & Networking

In an environment where components are installed on more than one host, the following network traffic flows need to be allowed. All is TCP protocol unless otherwise noted. Not all ports will need to be open for every supported architecture. Secure ports are only required when explicitly configured.

SouceDestinationPortDescription
Desktop DevicesIAP3000Web browser connections to IAP over HTTP
Desktop DevicesIAP3443Web browser connections to IAP over HTTPS
Desktop DevicesIAG8083Web browser connections to IAP over HTTPS
Desktop DevicesIAG8443Web browser connections to IAP over HTTPS
Desktop DevicesHashicorp Vault8200Web browser connections to Hashicorp Vault
IAPMongoDB27017IAP connects to MongoDB
IAPRedis6379IAP connects to Redis
IAPRedis26379IAP connects to Redis Sentinel. Required only for HA installations.
IAPIAG8083IAP connects to IAG over HTTP.
IAPIAG8443IAP connects to IAG over HTTPS
IAPHashicorp Vault8200IAP connections to Hashicorp Vault
IAPLDAP389IAP connections to LDAP
When LDAP adapter is used for authentication
IAPLDAP636IAP connections to LDAP with TLS
When LDAP adapter is used for authentication
IAPRADIUS1812IAP connections to RADIUS
When RADIUS adapter is used for authentication. This uses UDP.
MongoDBMongoDB27017Each MongoDB talks to the other MongoDBs for replication of the database. Required only for HA installations.
RedisRedis6379Each Redis talks to the other Redis’s for replication. Required only for HA installations.
RedisRedis26379Each Redis uses Redis Sentinel to monitor the Redis processes for HA resiliency. Required only for HA installations.

Required User Accounts in Dependencies

The validated designs are very opinionated installations of Itential and its dependencies. The following user accounts are required by the dependencies for a validated design and are used for the following purposes.

MongoDB

AccountDescription
adminHas full root access to the mongo database. Can read and write to any logical database. Can be used to issue admin commands like forcing an election and configuring replica sets. This is NOT used by the Itential application but is created for admin purposes.
itentialHas read and write access to the “itential” database only. This is the account used by the IAP application.
localaaaHas read and write access to the “LocalAAA” database. This is used by the Local AAA adapter for local, non-LDAP logins.

Redis

AccountDescription
adminHas full root access to the Redis database, all channels, all keys, all commands. This is NOT used by the Itential application but is created for admin purposes.
itentialHas full access to the Redis database, all channels, all keys, EXCEPT the following commands: asking, cluster, readonly, readwrite, bgrewriteaof, bgsave, failover, flushall, flushdb, psync, replconf, replicaof, save, shutdown, sync. This is the account used by the IAP application.
repluserHas access to the minimum set of commands to perform replication: psync, replconf, ping.
adminFull root access to Redis Sentinel. This is NOT used by the Itential application but is created for admin purposes of Redis Sentinel.
sentineluserHas access to the minimum set of commands to perform sentinel monitoring: multi, slaveof, ping, exec, subscribe, config|rewrite, role, publish, info, client|setname, client|kill, script|kill.