I have a facility where I have to connect to 288 Modbus devices and historise ~2 million tags. With some Ignition Tag Group configuration, I think I could get the tag change rate down to about 150k tag changes per second.
I would like to achieve this with a single Ignition server piping the data up to Canary. Is this realistic? Can a 16-core/32GB RAM Ignition server handle that? Thinking 512GB storage for store-forward...
Not sure, but 32GB seems a bit light to me.
32GB RAM, not storage. Do you think 32GB RAM is too light? Edited original post for clarity.
So in this case is Ignition just acting as an OPC UA server connecting Canary to the 288 Modbus devices? Or is it doing anything else?
Yeah.
If you read through the guide, for a single server, IA is recommending 16GB ram for 10,000 changes/sec. You're expecting approx. 15x that.
Assuming that the server is doing more than acting as an OPC UA server, the recommendation is to allocate half of the ram to the OS and other services, so that cuts you to 16GB (You should configure Ignition to allocate all 16GB's up front).
Again, assuming that this is more than just a OPC server, I wouldn't be shocked to see 64GB of RAM for a project of this size (If not more).
A lot of this depends on exactly what you're attempting to do with the server.
Is the plan for this to be a bare-metal server or VM?
Yes in this case Ignition is mainly just responsible for the Modbus polling (at various rates), and connecting to Canary either through the dedicated module, or via MQTT. May also pipe a fraction of the data to another Ignition gateway.
Essentially the question is, is there a hardware spec that would allow a single Ignition server to achieve this or does it need to be split out at the application level? Is Ignition the right tool?
I don't think 288 devices is a problem, I've seen more than that.
2 million tags on a single server, though, is quite a bit, and it sounds like you're going to pay full price (in terms of performance/impact) because you need to create 2 million corresponding Ignition tags to expose via Canary module or MQTT, and not just act as an OPC server that some OPC client will connect to.
Is there a hardware spec? Probably. You're in "try it and see" territory, though.
Thanks for the response Kevin. These are very repetitive tags, basically the same asset repeated many times. It sounds like 2x 16-core Ignition servers might be the starting point, with some experimentation on how much RAM is required.
I am expecting this to run on a VM, but bare metal is a possibility. Not planning to host any visualisation on this server.
If you run this on a VM, i would definitely recommend at least 2 servers. Insure that you configure Ignition to allocate half of the available RAM up front (see various posts on the forum if you don't know how to do that).
Also, if running in a VM, insure that you configure your Hypervisor to not steal idle CPU time on the Ignition servers. On bare metal that isn't an issue.
How'd you go with this, any lessons learnt? I've got a 1.2m back end server on 32gb / 16 core evenly split across opc, expression, reference and sql tags. I am having lots of issues with the subscribing of opc tags after a PLC download. Wanted to see if you'd come across a similair issue.
I've been tuning it up to be split out across dozens of tag groups and a half dozen opc connections to the same server with various success.
where did you find the total tag changes per second?