"Best" Ignition Server Software Environment

I looked at some posts here that talk about server hardware and performance. I would like to know from a more software environmental standpoint what the “best practices” are to have kick’in Ignition server performance with the best security. My project will be a “Mission-Critical” hardware redundant installation, with the client IT guys caring for it when I’m done.

[ul]1. Security is foremost on this project. The client IT guys are talking about the NIST “Recommended Security Controls for Federal Information Systems and Organizations” (attached) as their bible.
2. They are also talking about VMware server software serving up a virtual machine for the Ignition server environment. My first reaction is no-way Jose, I want dedicated hardware, but I thought I’d put it out there for comment.
3. Any known gotcha’s with Ignition or support software like Matrikon or Kepware OPC in a 64-bit OS? Why use Windows Server 2008? Why use Ubuntu? What are their strengths/weaknesses relative to Ignition?[/ul]

I know there’s a lot of ground covered here, as each question relates to the next, and touches some topics discussed separately. My goal is to compare/contrast differing approaches rather than focus on each separately. I hope this spawns a very active thread full of facts and informed opinions.
sp800-53-rev3-final[1].pdf (1.21 MB)

VMware is awesome for an Ignition environment. We have 4(+1 hot spare) ESX servers, 2 of these servers are in my building, 2 are 10 miles away, and the spare is 2 miles away. W/ the ESX servers setup w/ HA, I can lose up to 3 of the ESX servers and maintain full capacity for our critical applications. This includes Ignition.

Now i’m talking about VMware ESX, I haven’t tried this w/ VMware server.

Our Ignition server has no trouble being vmotion’ed around the cluster either.

Personally, I used both Windows 2003 R2 and RHEL 5.5 system for Ignition. The RHEL box is my dev box currently.

Windows vs a Linux install: In a nutshell you won’t be able to talk to older DCOM OPC servers w/ the Linux install. OPC-UA works flawlessly though.
Otherwise I find the linux server runs a touch snappier(on identical hardware) but no big shake either way.

Security, SSL on for everything, The OPC-UA connections are encrypted, the OPC-DA connections are tunneled to the machine and connected to locally so no worries there(I use Matrikon’s tunneler product for this.)

I have Ignition running on a 64 bit CentOS vertual in our VMware ESX environment.

Oracle is installed on the same VM. We’ll see if there issues.

Dennis

VMWare ESX is the way to go. Anytime you can seamlessly move running servers from one physical box to another without interruption… Why would you even thing of one machine per server anymore?

+1 for VMWare ESX or ESXi

Thanks so much for the responses! I have a new awareness and appreciation of VMWare ESX/ESXi, where before I had no idea. I think this environment should be officially blessed and documented in an IA white paper (hint, hint).

Now for the obligatory follow-up questions:

When you utilize VMWare ESX/ESXi, does it take care of hot backup readiness virtually, or do you still need multiple Ignition licenses? What about the 3rd party OPC software and tunneller licenses?

I’m not following your question about “hot backup readiness virtually”. A virtual machine can conceptually be treated like a physical machine - it still has backup requirements. The advantage is that the “virtual machine” is really a set of files that can be copied and run on numerous physical ESX hosts. So if you have a hardware failure, you can run the virtual machine on other physical hosts. Advanced VMWare features allow this to happen automagically or semi-manually through VMotion, HA, and other features - if you go that route…check with your IT department. The features are really cool, but they require some engineering, hardware (shared storage, fast network connections), and software licenses (on the VMWare side). As to backups, you can back up the entire virtual machine and/or use “snapshots” (very awesome). Your Inductive Automation software (and other vendors) remain licensed with that VM, including backups.

Using multiple Ignition Gateways makes just as much sense in a virtualized architecture as a physical one. You can take advantage of retargeting and load balancing. You’ll need licensed copies per concurrent running gateways on a virtual machine basis - not physical host. These advantages apply to physical machines and/or virtual machines…clients have no notion of virtual machine’s physical hosts (ie, ESX/i, Xen, or Microsofy Hyper-V servers). This is an advantage of virtualization in general, really having nothing to do with Inductive Automation or Ignition. There are additional gained efficiencies and security benefits, which is why the IT field is aggresively migrating to virtualization on the server segment.

Re: Hot backup.

We have more of a lukewarm backup at the moment.

I use a separate install of Ignition as my Dev environment. It is not activated, But otherwise setup the same way as the Production server. Once a week I backup the primary Ignition setup and restore it on the backup. If I blew my Production node up completely, I would have 2 steps to follow to get back online.

A. Restore the whole machine from system level backups and repoint the DNS entries for the Production node to the Dev node and just deal w/ the 2 hour limitation till the restore completed(Took 3 hours start to finish the last time I simulated this).

B. Once the P-node is back online, Repoint the DNS and reboot the Dev node to force people to switch back over.

You could also just purchase the 2nd license package and let 2 machines load balance. In the event one falls down, Clients get bumped over to the other one w/out much fuss. I don’t have the budget for this yet or I would have gone this route from the start.

With virtual machines your “lukewarm” backup could be an activated copy of the entire machine. That way you wouldn’t need to move activations, repoint DNS entries (maybe - depends on your architecture) or anything else. The downside of this approach is that the project data is also a part of the “backup”, so you would need to have a recent backup of the project every time you update…or maintain double copies. The pros and cons depend on how frequently you make project changes, your backup strategy, how fast and seamless recovery from a total crash is, etc. It makes sense to have a development/staging setup as well. Growing into the “load balancing” approach makes the most sense for mid-sized or high availability projects. The nice thing about the architecture is that you can add that additional licensed server at any time without changing anything else about your project.

Dev - That’s also a good point about using a free (unlicensed) copy for your development environment, then having it as an option as a backup platform. Very efficient.

I think this is totally up to what type of hardware you have, what you have control of, what you are trying to accomplish, etc. Saying virtual machines is the “best” way to go is like saying …nvm cant say that. Anyways, we need to know this type of information. If you have an established IT group, and already have the infrastructure to support it, then yeah, thats the best way to go. However, running virtual machines is in no way more secure than running on real hardware. More efficient, yes, secure, no.

Also, running 2 instances of Ignition on a single physical host might get you around a OS failure, but not the physical host failure. Blah blah blah, Im rambling, you get my point. There is no “Best” Ignition server software environment. While I may prefer to run everything on top of Linux, there are instances where it is not the best choice. The best choice is running what you know, what you are comfortable with.