Virtualization and Network Configurations

I know some of the community are already utilizing virtualization technology, and I'd like to know on what practices are being utilsed in terms of virtual NICs and networks. Are you sharing a single NIC between all VM's for DV primary traffic and another NIC for secondary or separate physical NICs per VM? Should the NICs be SR-IOV capable? 

 

I want to get a feel for how best to configure DV in a virtual environment. 

 

 

 

 

8 Replies

  • DeltaV v12 will be releasing soon and will include support for virtualization. There will be documentation surrounding the NIC requirements for On Line systems, which will be different than what you would need for a virtual environment, especially for high availability architectures.

    For Off line, I've set up two virtual networks each tied to a dedicated NIC on teh DeltaV primary and Secondary networks.  This allows for interconnection of servers and hardware nodes like controllers.

    A third network is typical and you can place your RDP clients on this network to access the VM sessions.  This pretty much matches up with a production system with a plant LAN.  

    For production systems, you might have two ACN NICS, a pair for RDP dedicated Operator station clients, a pair for the high availability SAN server and the Server clustering, and the Plant Network for integration to the DMZ/Business LAN.  For Offline, I'd say three NIC's gets you going.  You could use more NIC's to mirror your production networks and keep things separate, but from a performance picture it will not make that big a deal.  You could also use a Gigabit connection for the Plant LAN/RDP connection for increased bandwidth on this network.

    I would use separate NIC's only if I needed to have separate virtual networks that served a subset of nodes, and I needed these networks connected to the outside world in separate subnets.  In other words, keep in simple.

    Andre Dicaire

  • Adrian,

    I work for MYNAH Technologies, LLC and we design Virtual Dynamic Simulators for DeltaV Test and Operator Training Systems.  We have also virtualized all of our own internal DeltaV systems for projects and testing.

    Virutalization technology allows you to create many virtual networks and you can utilize a single NIC for multiple virtual networks.  You are limited to the number of connections to external networks by the number of physical ports on the NIC.  Typically when we order a single server we include a quad port 1Gb NIC.  We can create a bunch of virtual networks, but the server can only connect to four external networks.

    If you use VMWare for virtualization, you create virtual machines and virtual switches.  The virtual machines are connected to ports on the virtual switch, creating a network for communication.  This virtual switch can then be connected to a physical adapter for external communication but it can be completely internal to the server.

    As Andre mentioned, the DeltaV systems typically only need three networks or two if you aren't concerned with a DeltaV Secondary network (a single Plant LAN, a DeltaV Primary Network, and a DeltaV Secondary Network).  The Plant Network can be used by external workstations to remote into the virtual machines.

    Networking gets a little hairier if you have multiple DV ProPlus Systems in a single server with only one physical port for the Primary Network and only one port for the Secondary Network.  You may see this on a server running multiple simultaneous projects.  In that case you need to utilize VLANs and need smart switches that support VLANs.

    If you are interested in learning more, I recommend taking a look at VMWare's resources.  They have a lot of free information online.  I would also recommend learning about VLANs and how they work.  Understanding the key concepts of virtual machines and network virtualization is really the most important thing because from DeltaV's perspective, it does not see any difference between being on a virtual machine or on a virtual network versus being on a physical workstation or typical network.

    We have an article that describes our Virtual Dynamic Simulators that has some basic diagrams that help illustrate the relationships between virtual machines on a server using virtual switches: www.mynah.com/.../virtual-dynamic-simulators

  • In reply to Jake Nichelson:

    One thing that Andre mentioned that I think must not be overlooked is ensuring the availability of the 'client' network.

    In traditional DeltaV systems, the redundant control networks helped ensure that a failure on Primary or Secondary not only kept the controllers communicating with each other, but that all workstations also kept their visibility into the running system.

    If all of the workstation 'windows' into the system are now either via RDP or 'zero client' connections through a network that does not provide the same level of availability as the DeltaV dedicated redundant control networks did, then you will encounter scenarios in which all workstations simultaneously go dark if there is a problem on the third network.

    I have seen this occur in a running plant which used RDP client appliances as workstations, all connecting via a single 3rd network LAN.  The automation/IT department scramble to troubleshoot the third LAN took about 20 minutes and posed a potential threat to personnel safety and equipment.

  • In reply to Youssef.El-Bahtimy:

    I want to make it clear that Emerson's virtualization solution for production system does call for redundant networks on the client RDP connections.  A single network is adequate for offline applications.  It really depends on Availability requirements.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Yes, I was glad that mentioned it in your original post.   Thanks.

  • I know 12 isn’t release yet but I think we have some great feedback regarding this new arena.
     
    I’m still trying to visualize the scenario(s) both Andre and Jake proposed.
    To help me get it straight, if I had RCS and AMS applications stations virtualized on the same Hyper V host, I’d expect to have one physical DV Primary NIC associated to a Virtual DV Primary network, another physical NIC for secondary and possibly two additional NICs for a teamed Plant LAN; is the practice going to allow all VM’s to share these resources or do we need one to one physical to virtual?
     
    With the likes of SR-IOV virtualized resources, this offers a performance equivalent to near physical performance. Therefore, my scenario above should work fine….
     
    In Hyper-V 2.0 network teaming for the plant LAN is difficult (done in the hypervisor), whereas in Hyper-V 3 teaming is done in the VM, what hypervisor is DV12 supporting?
     
     
    From: Youssef.El-Bahtimy [mailto:bounce-YoussefEl-Bahtimy@community.emerson.com]
    Sent: Thursday, February 28, 2013 1:36 AM
    To: DeltaV@community.emerson.com
    Subject: RE: [EE365 DeltaV Track] Virtualization and Network Configurations
     

    One thing that Adre mentioned that I think must not be overlooked is ensuring the availability of the 'client' network.

    In traditional DeltaV systems, the redundant control networks helped ensure that a failure on Primary or Secondary not only kept the controllers communicating with each other, but that all workstations also kept their visibility into the running system.

    If all of the workstation 'windows' into the system are now either via RDP or 'zero client' connections through a network that does not provide the same level of availability as the DeltaV dedicated redundant control networks did, then you will encounter scenarios in which all workstations simultaneously go dark if there is a problem on the third network.

    I have seen this occur in a running plant which used RDP client appliances as workstations, all connecting via a single 3rd network LAN.  The automation/IT department scramble to troubleshoot the third LAN took about 20 minutes and posed a potential threat to personnel safety and equipment.

  • In reply to AdrianOffield:

    Within the virtual host server, you can define virtual switches to which your VMs will be "virtually" connected.  The VM's have NIC's defined and you bind these NIC's to the appropriate virtual network.

    Each virtual network can be External, Internal or Private.  The External binding of the virtual Network connects this Virtual switch to a physical network.  Internal Networks don't have this physical NIC, and Private networks limit connection of VM to VM, without a connection to the host manager software.

    For DeltaV, you'll need External Virtual Networks for the Primary/Secondary ACN, the RDP network(s), a Plant LAN network if different. Once a VM's NICs are assigned to their appropriate networks, you configure the NIC's for either Static or DHCP addressing, as if they were real.

    If you'r running multiple DeltaV systems in a server host, you'll need separate virtual networks for the DeltaV ACN's of each system.  If they need to also connect to external hardware, these will each need their own Physical NIC on the server.  I think the server will want each of these to have different addresses in the real world as well, and with the DeltaV networks, they need to be in the same subnet.  You should use the addresses reserved for other nodes.  If you set the physical networks to duplicate addresses, the host OS complains, and it may not allow the Host OS to access those NICs for troubleshooting...

    in my Hyper-V server, I have three networks for one DeltaV system, which has physical controllers and IO and workstation.  My host has a fourth NIC that I plan to use for my Thin Client network.  The third NIC uses DHCP networking, while the DeltaV nodes have static addresses.  I could add a 4 port NIC and add two more DeltaV networks keeping all VM's on the same Plant LAN network, and the same RDP network as these NIC's would have unique addresses.  They would all be External Networks for use with physical NIC's.

    If the environment was completely contained in one server (workstations, controllers and CIOC's all VM's) you could add Internal networks, without adding physical NIC's.  Not sure if we need Private networks. I think the internal networks allows teh Hyper-v manager to access the VMs with a terminal view. And Private networks isolate the VM's completely (you'd only access from an RDP session?).  Not sure.

    Emerson is not supporting VLANS, but if this is Offline and you're comfortable with this, and the NIC's support VLANs, this could also be used.  I have not tried this.

    Andre Dicaire

  • This is all great news, especially the supporting of V10 and up. I can see us expanding our V10 functionality without needing new hardware J
     
    So just so I have the networking side clear (I know HyperV well and understand how HyperV offers virtual switches), I understand your last post as each virtualized DeltaV workstation hosted on the same HyperV host will be dedicated to virtual network, in turn to a physical NIC/port.
     
    VM on
    HYPERV Host      Virtual Network                                             Network Card                   External Network Hardware
    DV_APP1 ->         Virtual DV Primary Network (1) ->              Physical NIC(1) ->             DeltaV SmartSwitch ->                          other nodes
    DV_APP2 ->         Virtual DV Primary Network (2) ->              Physical NIC(2) ->             DeltaV SmartSwitch ->                          other nodes
    DV_OTHER ->     Virtual DV Primary Network (x) ->               Physical NIC(x) ->              DeltaV SmartSwitch ->                          other nodes
     
    Is this the configuration you discuss or can all virtualized DV workstation (on the same host) use the same virtual network? That’s the bit I’m not sure about.
     
     
     
    From: Andre Dicaire [mailto:bounce-ADicaire@community.emerson.com]
    Sent: Thursday, March 07, 2013 9:21 PM
    To: DeltaV@community.emerson.com
    Subject: RE: [EE365 DeltaV Track] Virtualization and Network Configurations
     

    Within the virtual host server, you can define virtual switches to which your VMs will be "virtually" connected.  The VM's have NIC's defined and you bind these NIC's to the appropriate virtual network.

    Each virtual network can be External, Internal or Private.  The External binding of the virtual Network connects this Virtual switch to a physical network.  Internal Networks don't have this physical NIC, and Private networks limit connection of VM to VM, without a connection to the host manager software.

    For DeltaV, you'll need External Virtual Networks for the Primary/Secondary ACN, the RDP network(s), a Plant LAN network if different. Once a VM's NICs are assigned to their appropriate networks, you configure the NIC's for either Static or DHCP addressing, as if they were real.

    If you'r running multiple DeltaV systems in a server host, you'll need separate virtual networks for the DeltaV ACN's of each system.  If they need to also connect to external hardware, these will each need their own Physical NIC on the server.  I think the server will want each of these to have different addresses in the real world as well, and with the DeltaV networks, they need to be in the same subnet.  You should use the addresses reserved for other nodes.  If you set the physical networks to duplicate addresses, the host OS complains, and it may not allow the Host OS to access those NICs for troubleshooting...

    in my Hyper-V server, I have three networks for one DeltaV system, which has physical controllers and IO and workstation.  My host has a fourth NIC that I plan to use for my Thin Client network.  The third NIC uses DHCP networking, while the DeltaV nodes have static addresses.  I could add a 4 port NIC and add two more DeltaV networks keeping all VM's on the same Plant LAN network, and the same RDP network as these NIC's would have unique addresses.  They would all be External Networks for use with physical NIC's.

    If the environment was completely contained in one server (workstations, controllers and CIOC's all VM's) you could add Internal networks, without adding physical NIC's.  Not sure if we need Private networks. I think the internal networks allows teh Hyper-v manager to access the VMs with a terminal view. And Private networks isolate the VM's completely (you'd only access from an RDP session?).  Not sure.

    Emerson is not supporting VLANS, but if this is Offline and you're comfortable with this, and the NIC's support VLANs, this could also be used.  I have not tried this.