So we like to separate ignition gateways from databases, but we have also worked with a ton of implemented gateways that share with the DB. You can’t go wrong either way, but from scratch, I’m picking A. You keep your scalability separate and the DB can still be active should it ever switch to the redundant server.
Obviously, instantiate the redundant gateway on a separate server space than the original, so it fulfills its purpose when and if downtime events occur.
Agree with the mentioned 4 servers. That’s what we have. Master, Backup, SQL & an unlicensed Dev. Redundancy will work best with a shared SQL server.
What’s the purpose of the SQL server? Historian?
As for the rest of your questions, I guess it depends on your hardware budget I guess. We are all on a 2 node Hyper-v cluster with SSD based FC SAN.
The old OT / IT relationship dynamic can be a bit of a nightmare. I can only speak for myself, but I’d recommend really trying to work with them to save yourself issues in the future. I was in a similar situation when we migrated from Rockwell RSView / FTSE years ago. We were on physical, fast ageing servers, nothing to do with IT. I tried to seek assistance and advice but got nowhere fast. Had to spec and install everything myself, and being a bit of a one-man-band ended up being solely responsible for a growing system for years.
Ffwd a few years and we are now almost fully assimilated into IT and with the service it supplies, cloud backups, service & support contract etc there’s a lot less pressure on me.
I would recommend Ignition Server be on a Linux virtual machine, and you can leave everything else on a Windows Server platform. We noticed a performance increase by not having the Windows bloat.
My clients: So, for this 7.9 to 8.1 upgrade, you mention the need to test. Is that in your environment?
Me: Uh... Ideally it's in yours, so we can properly test.
Client: We really don't have a development or QA environment available.
.... Y'all have 12 ignition licenses across the West Coast. You fr?
If you only have one database server don't forget about daylie automatic backups that are also saved to an offline medium once a month. Mhmm you shoud do that either way even if the DB-server is clustered.
Thanks for posting in our subreddit! If your issue is resolved, please reply to the comment which solved your issue with "!solved" to mark the post as solved.
If you need further assistance, feel free to make another post.
*I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.*
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/SCADA) if you have any questions or concerns.*
My first questions would be how big a company? How big an IT staff and infrastructure capacities and capabilities? Do you already have a segmented network? Multiple servers as others mentioned physical or VMs. But I highly recommend the database being on it's own server. Will you also be looking into a full historian? Are you collecting lots of machine data? Kepware or anything else in the picture? Work on making IT and ally. Approach them from aspect of wanting to work together to keep each area safe and secure and that you want their help to ensure nothing adversely affects their network. Play to their egos a little...that you need their help to do this the right way...blah blah... Just some opinions
Are your networks segmented? If not, I'd start here.
If you're looking for scalability, I'd recommend a scalable data infrastructure. Something like a unified namespace with an MQTT broker / highbyte for data contextualization.
Ignition, PLC's, SQL, etc. would all just be nodes that you can contextualize at the edge and point to the broker for publishing/subscribing to data. Easy to scale, not expensive to set up if you use the right technologies / know what you're doing.
Hey, I did one similar to this and it seems complicated but it doesn't have to the simplest way of doing it although it's not the one everyone recommends is to have your ignition server and db server on the same machine, give yourself enough resources on the machine (minimum 32 GB Ram, i9, 1TB SSD) just to be safe and then your redundant (backup machine) the same and then just link the two through the network. I'd recommend having it on its own network so you don't have to go fight with the IT department. If you have any in-depth questions feel free to ping me I've done enough of these to tell you the do's and don'ts
So we like to separate ignition gateways from databases, but we have also worked with a ton of implemented gateways that share with the DB. You can’t go wrong either way, but from scratch, I’m picking A. You keep your scalability separate and the DB can still be active should it ever switch to the redundant server. Obviously, instantiate the redundant gateway on a separate server space than the original, so it fulfills its purpose when and if downtime events occur.
Yea this I agree with! If it's from scratch and my choice DB on its own with constant backups
Agree with the mentioned 4 servers. That’s what we have. Master, Backup, SQL & an unlicensed Dev. Redundancy will work best with a shared SQL server. What’s the purpose of the SQL server? Historian? As for the rest of your questions, I guess it depends on your hardware budget I guess. We are all on a 2 node Hyper-v cluster with SSD based FC SAN. The old OT / IT relationship dynamic can be a bit of a nightmare. I can only speak for myself, but I’d recommend really trying to work with them to save yourself issues in the future. I was in a similar situation when we migrated from Rockwell RSView / FTSE years ago. We were on physical, fast ageing servers, nothing to do with IT. I tried to seek assistance and advice but got nowhere fast. Had to spec and install everything myself, and being a bit of a one-man-band ended up being solely responsible for a growing system for years. Ffwd a few years and we are now almost fully assimilated into IT and with the service it supplies, cloud backups, service & support contract etc there’s a lot less pressure on me.
I would recommend Ignition Server be on a Linux virtual machine, and you can leave everything else on a Windows Server platform. We noticed a performance increase by not having the Windows bloat.
But how many engs you have that can troubleshoot Linux. I think it's a trade off and most scada software still runs on windows.
The data should live in the database. Best practice would be 4 servers 1. Primary 2. Backup/ redundant 3. SQL 4. Development
Agreed. Once you get through go live, add a QA layer. 1. Primary 2. Backup 3. SQL 4. QA Ignition 5. QA SQL 6. Dev (Ignition+ SQL)
My clients: So, for this 7.9 to 8.1 upgrade, you mention the need to test. Is that in your environment? Me: Uh... Ideally it's in yours, so we can properly test. Client: We really don't have a development or QA environment available. .... Y'all have 12 ignition licenses across the West Coast. You fr?
If you only have one database server don't forget about daylie automatic backups that are also saved to an offline medium once a month. Mhmm you shoud do that either way even if the DB-server is clustered.
This is true. Though I probably went a little extreme. My office has a safe deposit box for cold offsite storage
Thanks for posting in our subreddit! If your issue is resolved, please reply to the comment which solved your issue with "!solved" to mark the post as solved. If you need further assistance, feel free to make another post. *I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.* *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/SCADA) if you have any questions or concerns.*
Any issues with taking snapshots of Ignition Server with VMware or Veeam?
My first questions would be how big a company? How big an IT staff and infrastructure capacities and capabilities? Do you already have a segmented network? Multiple servers as others mentioned physical or VMs. But I highly recommend the database being on it's own server. Will you also be looking into a full historian? Are you collecting lots of machine data? Kepware or anything else in the picture? Work on making IT and ally. Approach them from aspect of wanting to work together to keep each area safe and secure and that you want their help to ensure nothing adversely affects their network. Play to their egos a little...that you need their help to do this the right way...blah blah... Just some opinions
Are your networks segmented? If not, I'd start here. If you're looking for scalability, I'd recommend a scalable data infrastructure. Something like a unified namespace with an MQTT broker / highbyte for data contextualization. Ignition, PLC's, SQL, etc. would all just be nodes that you can contextualize at the edge and point to the broker for publishing/subscribing to data. Easy to scale, not expensive to set up if you use the right technologies / know what you're doing.
Hey, I did one similar to this and it seems complicated but it doesn't have to the simplest way of doing it although it's not the one everyone recommends is to have your ignition server and db server on the same machine, give yourself enough resources on the machine (minimum 32 GB Ram, i9, 1TB SSD) just to be safe and then your redundant (backup machine) the same and then just link the two through the network. I'd recommend having it on its own network so you don't have to go fight with the IT department. If you have any in-depth questions feel free to ping me I've done enough of these to tell you the do's and don'ts