I am working with my architecture and engineering team to plan for the implementation of ICON in our environment and we had a couple questions that the documentation doesn’t seem to outline. I was hoping to get some help here. Currently our environment is about 20,000+ endpoints with items on-prem and in AWS.
Prod. Hardware Requirements:
Are there limitations on how many devices can utilize a single orchestration server?
Prod. Hardware Requirements:
From a RAM standpoint, do we find that 8gb is enough or is the orchestration server heavy on RAM for individuals with larger environments?
Prod. Hardware Requirements:
In regards to the disk space requirement, what is the difference in the amount of workflows you can use by going from 64gb to 128gb? Are we talking 10 to 20 workflows or 100 to 200 workflows?
Network Connectivity Requirements
Does the the Orchestrator server generate massive amounts of traffic on the network when performing workflows?
We have a few thousand endpoints and 31 connections and bumped up to 32 GB of RAM and 128 GB of storage, which has been good for us. We started lower but spiked the CPU pretty quickly.
For network requirements, it depends on your workflows, but I wouldn’t say it generates a ton of network traffic on it’s own.
I did see the requirements pages, but I didn’t really see much depending on the scale of the environment other than for storage. This helps though, thank you!
ICON is about plugins to APIs not devices. This isn’t like InsightVM, it integrates with the systems that do this activity via APIs e.g. InsightVM, Active Directory, SQL. Your requirements are how many Workflows and Plugins you are planning on using.
Certain Plugins have memory leaks. I have my Orchestrator set to 32GB of RAM because of this. My Active Directory Plugin and chew up over 10GB of RAM in a day and I have to reset it multiple times to keep it in check. Other than that I’ve got about 50 Plugins running and it takes the rest pretty well.
Disk Space is not dependent on Workflows, it is based on Plugins and versions. Multiple Workflows that use the same Plugin on the same version use the same docker container and don’t take up any more space. When you upgrade the Plugin version, make sure you do it everywhere so you can remove the old container, otherwise you double the resources for nothing. Each container is just a Web server that accepts a REST call, process the data using python and maybe a module specific to the Plugin, but usually it is just doing a REST call to another system itself and composing the output in a consistent JSON, so the plugins are really light weight.
Network traffic has to do with the number of times to call a Plugin and the amount of data that plugin returns, it is all RESTful microservices and no worse than any other application that does the same. All network traffic. The connects are stateful during the call out to their resource, and a JSON payload to and from ICON to the orchestrator
I’ve got around 30 Active Workflows and about 120 Inactive ones and do high transactional work and this is what my Orchestrator looks like
Also, the ICON team is bringing more and more plugins into the cloud so the on-prem resources are getting lighter and lighter. I do as much in the cloud as I and only do on-prem when I have network restrictions to the endpoints that my plugin is calling e.g. AD, or Azure because of Conditional Access Policies
