HI i am new to ignition and given the task to come out the design of redundant server. i needed some light toward a few area especially on the licensing portion. the application is just monitoring and control on the PLC I/O and do some report.
Redundant server as Frontend and I/O server to connect to few PLC on the ground
a. license needed x2 - ignition platform , perspestive module(unlimited), reporting module, tag historian module
Redundant SQL server for historian(Microsoft SQL)
i have a few questions for above licenses,
-on sql server do i need to install any ignition relate software or license need to apply?
-i am using the normal alarm( boolean alarm or analogue alarm) do i need to add the alarm notification module into the license?
-on the above description do i need to included the sql bridge module into the license?
-can i hosted all the license mentioned above only on the frontend server?
Ignition's native redundancy requires exactly the same modules on both gateways, and the license $$ for the 2nd is 50% less.
It sounds like you aren't aiming to use Ignition's redundancy at all, simply moving workload away from the I/O gateways.
SQL Server licensing is entirely separate from Ignition, and is based on end-users CALs. You may want get unlimited licenses, as counting CALs in Ignition is uncertain.
The alarm notification license is needed where the alarms originate. Typically just the I/O servers.
You only need the SQL Bridge module where you are running its transactions. Typically just the I/O servers.
It may be easier to draw up a simple diagram of how you intend your architecture from a physical standpoint. @pturmel thinks you're not looking to use the Ignition redundancy, but I'm interpreting it as if you are wanting the frontend and I/O server on the same server.
Ignition Platform
Perspective Unlimited
Reporting Module
Tag Historian Module
You don't need the alarm notification module unless you plan on sending email, text/SMS, or Voice/VoIP notifications to users. Normal alarms with an alarm list/journal and display on the HMI do not require an additional module.
The SQL bridge module is only needed if you want to use triggers or periodic logging of values to your own SQL tables. The tag historian has a fixed format for the tables and structure, but if you want to write values into a custom format of columns in your own tables, you'll need/want the SQL bridge.
All of this can run on a single server if needed, and if you are wanting redundancy, you'll simply multiply your base cost time 1.5 to get the full price of the system with redundancy. (Since it's 50% of the base licensing cost)
As @pturmel also mentioned, SQL server licensing is going to be separate, and depending on what Microsoft counts as a client (their licensing is confusing), it could take a lot of CALs or you can just do processor based unlimited licensing, which is more expensive, but can guarantee you're not violating any license agreements.
Also, keep in mind that you aren't required to use MS SQL Server as there's plenty of other highly capable databases out there. My personal favorite is PostgreSQL with the TimescaleDB add-on for historical data.
They just use a lot words to say that every single user that connects to a web server that connects to their database technology requires a CAL. I don't find it confusing at all.
While I am not a lawyer, since Ignition is a web server, I don't see how any other interpretation could apply.
If you are using unlimited Perspective or Vision UI modules, you almost certainly need to buy the processor-based unlimited CALs for each DB server. If using a limited UI license, I would expect you to need a CAL for each session plus one more for gateway-scope operations.
I think I always got hung up by this wording as I didn't know how the abstraction worked (if you have 10 users, 2 servers, and 2 operator workstations, did you need 14 CALs or 10 CALs or 12 CALs):
Client access licenses (CALs) are required for every user or device accessing a server in the Server + CAL licensing model.
As you said, the easiest way to guarantee an audit pass is to just buy the core licensing and not have to worry about it. (It's just not cheap which is why all the alternatives are just easier to implement if using MSSQL isn't a requirement)
thank @pturmel@Kevin.Herron@michael.flagler informative input. they cleared quite alot of the confusions that i had. i attached the simple diagram in this reply. for the application i expected for less than 5 users use on the perspective session to view on the scada,i have a few more question.
with these design is there a need for the load balance for the frontend?
also i thinking to have sql secondary on passive, are the SQL standard Basic AG is capable for this design?
Personally, I wouldn't think you would need a load balanced front end as long as you have a powerful enough server with plenty of RAM. (Don't run this on a Raspberry Pi or small underpowered desktop PC expecting good performance).
I never set up redundant SQL servers myself since the systems I usually set up only use them for historian and logging, so the store and forward system handles outages/updates/reboots just fine.
Do you need the ‘secondary’ gateway to poll different devices (than the primary gateway), host different projects, with different clients connecting to it? If so, you'll need 2 full gateway licenses, not 1.5x.
While there are some implementation details that contradict the following, a redundant gateway is coordinating with the primary gateway, waiting to assume responsibility as the active gateway. Clients are not able to operate from a standby gateway, as the standby gateway redirects all clients to the active gateway. All modules, projects, tags, (…nearly everything), is synchronized between the gateways. You can almost imagine that the secondary gateway does not exist, until it needs to.
Regarding redundant SQL Servers… If you have a DBA team that is highly proficient in SQL Server and Availability Groups, then consider their recommendation. When I pick the architecture, I often prefer to utilize Ignition’s tag history splitter, and send data to both (or multiple) standalone databases using dedicated store and forward engines within Ignition. I find these are easier to monitor & maintain. However, one should expect lots of differences between the two databases (each will have their own reference tables, etc.).
hi michael, then the sql server you running for historian will it be data lost if the running sql server is down? because the application going to design is requesting minimize the data lost when the sql server is down, so in this case would needed the SQL in HA mode. Studied furthermore realise will may need to have the Enterprise version of SQL as it can auto failover and backward data sync when primary restored back. Correct if i m wrong
Hi Chris, un-fortunely that my team didnt have one DBA expert to seek advise to. anyway is fun to go through them and learn along. Noted the licensed i will get 1.5 redundant mode, i initially planned to get the both frontend single license as i read online that both can be in redundant mode or independence even both are hosted the same project and setting
hi pturmel, based on the above diagram drew i based on understanding on the data flow between the 4 server(2 frontend+IOserver, 2 sql server) as i understand that most the data will reach the primary then only will push down to sql server and they shared the status each other with secondary, and secondary server act as backup and start working when primary down. correct me if i am wrong
The historian in Ignition will store data to the local server/disk if the SQL server is not available. You can configure how much it will store before it starts dropping data records, but once the SQL server is available again, it will send all the data that was stored locally to the historian so that you still have all of your historical data, alarms, etc.
Feel free to try it with any database you want. Sweet up a simulator or real data and have it historize it. Now either disconnect, shutdown, stop the service, or power off the SQL server. You'll see the store and forward records start to increase and once you get the SQL server back online, that data will be written back to SQL and you'll have your full historical data/trends.
The primary Ignition gateway and the backup Ignition gateway point at a single database or database cluster. The backup gateway cannot point at a different database instance. That breaks your history. Whatever you do with redundancy within the database must be invisible from Ignition.
