The Itential SaaS Platform is an Itential architecture where Itential hosts Itential Platform and all of its dependencies, and support is the responsibility of Itential. The customer is only responsible for maintaining and hosting IAG within their environments. A secure VPN tunnel is established between the customer’s location and Itential Platform instances, and NAT (Network Address Translation) rules are applied to both sides to create the necessary routing.
Components
The components used in the SaaS platform are essentially the same as those used in the on-premises installation. The difference is that the support of those components is abstracted away from the customer. Additionally, upgrades and maintenance are handled by Itential.
Support
Itential Cloud customers benefit from dedicated support of the Itential Cloud Operations team, which handles administration, upgrades, log management, and pruning of job data. This approach to handling technical issues and service requests allows customers to focus on their core activities while Itential ensures the smooth operation of the Platform.
VPN Connectivity
A hosted Itential Platform will still need to "talk" to components and systems on the customer side of the firewall. Itential establishes a VPN tunnel that enables a secure connection from our Automation Platform to the systems and devices it communicates with. There are essentially two ways this is done:
- One-to-One NAT Rules
- Netmap NAT Rules
Figure 1: VPN Connectivity
One-to-One NAT Rules
One-to-One NAT rules can be established between adapters in Itential Platform and systems in a customer’s environment. For example, if a customer has ServiceNow running internally within their private network available at “servicenow.acmecorp.com”, that can be mapped to 192.1.1.1. If the customer is also running Solarwinds at “10.0.0.1” that can be mapped to 192.1.1.2. This one-to-one mapping can be tedious to set up, but it provides assurance of what the networking mapping is intending.
Netmap NAT rules
An alternative to maintaining a potentially lengthy list of one-to-one mappings, a single network can be created using a CIDR block. This has the advantage of enabling the networking more quickly and it eliminates the bookkeeping for each adapter; however, it does potentially expose the network to unnecessary connections. Under this scenario the above example would be represented with a CIDR block like this 192.1.1.0/128 and addresses from that block would be used for adapter configurations.
IAG Installation
IAG must be installed inside the customer’s network, preferably as close to the network devices as possible. If there is a broad geographic distribution of devices, more than one IAG may be used. Multiple IAG systems are typically installed with an Ansible installer and are self-contained with no external dependencies.
IAG Server Specs
| Spec | Requirement | Development ENV |
|---|---|---|
| CPU | 64-bit x86 CPU cores | 16 |
| OS | RHEL Rocky |
8/9 8/9 |
| RAM | DDR5 DRAM 3200 Mhz | 32 GB |
| Disk (Solid State Media, i.e. SSD, NVMe) | Total/var/log/automation-gateway/var/lib/automation-gateway/opt/automation-gateway/ |
80 GB 10 GB 50 GB 10 GB 10 GB |
Hardware & Hypervisor Configurations
Processor
The processor specification requirements are:
- 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:
- DDR5 DRAM 3200 Mhz or higher
Storage
The storage performance requirements in IOPS (16 kiB) are:
- 20000+ IOPS
- Non-spinning media (i.e. SSD, NVMe)
Network
The network speed requirement is:
- 10 Gbps or higher
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 it. 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 Itential Platform:
- 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
- Memory compression disabled
- Minimal CPU Allocation settings for scheduler according to CPU clock
- Example: Assuming an Itential Platform VM on a server capable of 2.5GHz nominal speed, CPU clock reservation = 16vCPU * x 2.5GHz
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.
Adapter Configuration
Adapters make integrating with external systems possible. The Itential SaaS architecture provides the latest version of all supported adapters. For customers, there is nothing to install. They just need to be configured. Configuring the adapters requires a service account or some other suitable account for interacting with the remote system with enough privileges to perform all of the required actions against that system. Having a subject matter expert (SME) available who understands the system is useful as sometimes the configurations of connectivity are often unique from one customer to the next. With advance notice, custom adapters can also be included.
User Management
User accounts are managed in the Itential Cloud portal.
Limitations
Current limitations include the following:
- Since Itential is managing a hosted platform experience, customers will not be able to manage their Itential Platform, MongoDB, or Redis services, nor will they have access to log files.
- Customers will not have a significant amount of historical information (data from automations that have run in the past) and will be limited to only the last 30 days of job history.