Hi,
These days everyone talks about using scale-out architecture to separate the backend from frontend, and having multiple frontends adding load balancer for large projects.
The questions is as this involve a lot of headache for SI like you have to add user to user source manually for all servers, editing report doesn't reflect to all servers and you have to do it manually and etc, isn't better to just increase hardware resource to compensate performance?
Don't forget the additional Perspective module cost for each frontend server.
Having one server with max RAM and CPU cores may better option here? Or we may have some sort of software limitations for that?
1 Like
I think splitting Perspective off from the rest makes the most sense. Its gateway load grows substantially with many clients or clients that do very much historical trending. Vision scales with clients much more "gently". You don't want to bog down the gateway that is responsible for direct communications with the plant floor. Use remote tag providers to pull from the operations/Vision gateway into the Perspective gateway. I think the only other $$ on the 2nd server are the base license and the tag historian module.
The Perspective gateway could also be placed in the plant's DMZ, or in the cloud, without compromising performance.
{ To be clear, I mean only having Vision on the operations gateway. I know that isn't precisely what you are asking. }
3 Likes
Thanks, Phil
But what about the idea of increasing hardware resources?
If 64GB of RAM and 4 CPU cores work well for 1M tags in the backend, should I set up another backend server for another 1M tags or just increase my RAM to 128GB and 8 cores to have all 2M tags in just one server?
If one front-end server with 4 cores and 64GB can handle 100 sessions of my Perspective Application, can I just increase my RAM to 128 and CPU core to 8 to support 200 clients on that server? Or there is some sort of software limitation in Ignition.
I remember in a project I have a lot of high-frequency tag change scripts and in Ignition, there is a limitation on the number of concurrent tag scripts that can run in an Ignition instance. So in this case even increasing CPU cores will not help me.
If I know all of these kinds of limitations, it will help me to choose my architecture more cost-friendly.
Also as I said earlier scale-out introduces a lot of extra engineering tasks for me.
Like edit reports should be done in Servers, or adding users to user sources should be done in all servers.
1 Like
No software limits. I'd max out the hardware before I split things up.
It is three by default, but can be configured larger. And only applies to tag events (on the tag), not gateway tag change events (in the project).
1 Like
It seems there is a limit in ignition tag System according to the
Ignition Server Sizing and Architecture Guide
Keep in mind that these are conservative values, and "high end" can mean different things to different people. "High end" might be another's "moderate end"
1 Like
The key word there is "approximately". That highlighted section is not so much the tag system itself, but the historian. And from what I've been told, the store-and-forward system in particular. Database selection matters greatly.
Also, get more cores. Ignition is highly multi-threaded, and that is greatly assisted by more cores. AMD's products seem to have better bang for the buck in that regards. I wouldn't go beyond ~32GB of RAM with only 4 cores.
My office hypervisor dedicated to testing is 16-core (+hyperthreading) w/ 64GB of RAM. (Xeon 4216, fwiw. Next one will likely be AMD.)
2 Likes