Virtualization, Cloud Analytics

A virtual machine is a computer that does not physically exist as a piece of hardware. The hardware that is seen by the operating system is emulated in an effort to separate the physical hardware from the operating system. This allows the virtual machine to be moved and hosted on any machine independent of hardware.

I’m often asked, “Why should I go virtual?” My first thought is why wouldn’t you? I’ll start out by listing the pros and cons of virtualization.

The pros of virtual machines

1. Less physical hardware.

In a typical distributed control system (DCS), you might have two Tag/OS servers, two batch servers, a historian or two, and an engineering station or two. Easily, you’re looking at six servers that will need to be physically maintained. You’ll find a time and overall cost savings on the replacement of hardware and maintenance.

2. Central location to manage all assets.

All of your virtual machines can be managed from one location.

3. More eco-friendly.

If you look at your current configuration, most of your machines are idling along. But, with them virtualized and running on a cluster, you maximize your machines’ potential while saving money on energy costs.

4. Disaster recovery is quick.

Re-deploy virtual machines on your system (once you get the host machine back online) and you can have your system back up and running in no time.

5. Expansion potentials.

With the infrastructure in place, it’s simply a matter of deploying a new machine and configuring. No need to go buy new servers (assuming you didn’t cheap out and buy bottom-of-the-line servers).

6. System upgrades.

The time and heartache of making system images before applying a patch and having a system restore fail are all realities. With the virtual environment, if something goes wrong while applying a patch or update, you can simply roll back the virtual machine back where it was before you applied the patch using a snapshot.

7. Software licensing.

Many software packages (such as Rockwell products) tie a license key to a hard drive ID. In a virtual environment, the hard drive ID stays the same no matter which piece of hardware it is running on.

8. Supports legacy operating systems.

As hardware evolves and operating systems become obsolete, it’s harder to find hardware and software that are compatible. Virtualizing these machines eliminates the operating system compatibility problems. This doesn’t fix the problem of obsolete operating systems that are no longer supported-which is a security risk.

9. Forward compatibility.

As new hardware becomes available, your virtual machines can still run on this new hardware (as long as it is supported by the virtual host software).

10. Use of thin clients.

Using a thin client manager, replacement of a bad terminal is as easy as a few clicks and powering on the new unit. Conversely, with a physical machine you’re stuck with re-imaging or building a replacement from scratch.

Many of the pros are related to the VMware ESXi/Sphere platform. The company has done a great job of packing high-availability features into its product:

• Monitors if a virtual machine has stopped running and restarts automatically (App High Availability).
• Can move a virtual machine running on one server to another without shutting down the guest virtual machine (VMotion).
• Can move a virtual machine running on one SAN to another without shutting down the guest machine (Storage VMotion).
• Automatically powers on a guest machine on boot of the server.

The cons of virtual machines

1. Cost. The upfront cost can be much higher and, depending on how high of an availability you want, you’ll need to be willing to design the system for your needs now and in the future.
2. Complexity. If you’re not familiar with the hardware and network aspects of the whole setup, it can be daunting to figure out. Routing rules and virtual local area networks (VLAN) continue to add complexity, especially if security is a concern.
3. Often the hardware is bundled together in one location, making a single disaster more likely to cause significant downtime. However, there are ways around this.
4. Hardware keys. Yes, you can use hardware keys. You can bind a USB port to a specific virtual machine. However, you are not able to move the virtual machine without physically moving the key as well.
5. Add-on hardware. In the past, you weren’t able to add on older PCI hardware and share it with the virtual machine. This has changed, but it doesn’t work 100% of the time. I’d recommend testing it thoroughly before deploying. Of course, this also limits which machine a virtual machine can run on because it will need to be bound to that piece of hardware.

What to consider

1. Server, switch, and SAN power

You’re going to want to have servers with dual power supplies. Each of these power supplies will need a separate circuit to run on. We typically separate them to a UPS circuit and a regular line circuit each powered from different panels.

2. Security

Usually, on a control system we recommend having a closed system (not connected to the corporate IT or Internet in the plant). I’ve not covered security in this article, as that is another topic entirely.

3. Virtualization options

There are other platforms than VMWare to virtualize with; Microsoft has its own system, which is powerful, along with many other virtual hosting options. I’ve not evaluated how other systems compare against VMware, so we’ll leave that as a topic for another day.

4. Connections to virtual machines

Connections to virtual machines can be established through remote desktop connections. Many thin clients have the ability to connect directly to a virtual machine that is running; this provides the look and feel of having a physical machine. Thin clients work much like a KVM routing the keyboard, mouse, video, and audio from the user to the virtual machine.

5. Virtual machine maintenance

Some maintenance can be performed on a virtual machine. My Colleague Chris Hardy has written a blog on maintenance that focuses on VMWare’s workstation version, but the concepts still apply for maintenance.

Use in the real world

I’ve been doing a lot of APACS virtualizations lately. We take images of the existing system and virtualize the RIS, batch, and engineering stations. Depending on the application, we’ll do physical machines or thin clients for the operator stations; this usually depends on if the customer is running dual monitor or not.

With the old process suite, you had to span your displays so it looked like one large display. As I’m sure you’ll recall, the OS’s for these systems are Windows 2K. We’ve found that XP SP2 will work just fine with Process Suite clients, and there are still some systems out there that will run Windows XP. Obviously, having outdated operating systems is not a good idea, but sometimes you just have to do what you have to do when you’re weighing the cost of both replacing all your hardware/software and rewriting it all from scratch or migrating forward to PCS7 for APACS OS.

In the end, virtualization does not absolve you from maintaining a system. You still must physically monitor the state of the hardware. But it does reduce the number of physical machines you’ll need to monitor. Some applications are better suited for virtualization than others. I’ve personally virtualized APACS, Rockwell, Wonderware, Iconics, and Ifix Platforms. Siemens has just begun supporting virtualization of an entire system (except a historian). We were fortunate to have the first that was built and used in the U.S. These days, most of the newer software packages are designed to be able to be virtualized. Many of the older platforms also play well. I’ve personally found very few things that didn’t work in a virtual environment.

– Edited by Anisa Samarxhiu, digital project manager, CFE Media, asamarxhiu@cfemedia.com