Virtualization Guide – Elipse Software.

1. INTRODUCTION

Virtualization is the single most effective way to reduce IT expenses while boosting efficiency and agility for any company size, as it allows running multiple operating systems and applications on one or more computers – thus consolidating hardware to get higher productivity from fewer servers.

Hardware virtualization refers to the creation of a virtual machine (VM) that acts like a real computer with an operating system. Software executed on these virtual machines is separated from the underlying hardware resources.

In hardware virtualization, the host machine is the actual machine on which the virtualization takes place, and the guest machine is the virtual machine. The words host and guest are used to distinguish the software that runs on the physical machine from the software that runs on the virtual machine. The software or firmware that creates a virtual machine on the host hardware is called a hypervisor or Virtual Machine Manager.

2. HYPERVISORS

In their 1974 article “Formal Requirements for Virtualizable Third Generation Architectures”, Gerald J. Popek and Robert P. Goldberg classified two types of hypervisors:

• Type 1 (or native, bare metal) hypervisors run directly on the host’s hardware to control the hardware and to manage guest operating systems. A guest operating-system thus runs on another level above the hypervisor. Examples of Type 1 hypervisors are Oracle VM Server for SPARC, Oracle VM Server for x86, the Citrix XenServer, VMware ESX/ESXi and Microsoft Hyper-V.
• Type 2 (or hosted) hypervisors run within a conventional operating-system environment. With the hypervisor layer as a distinct second software level, guest operating-systems run at the third level above the hardware. VMware Workstation and VirtualBox exemplify Type 2 hypervisors.

3. KEEP IT RUNNING

One upside to virtualization is that it puts more applications on fewer servers. One downside is that the availability of those servers become more important, as the failure of a single server can put down dozens of systems or applications.

As virtualization puts more application eggs into fewer server baskets, principles such as high availability (HA) require more attention. There are a variety of approaches used to keep running non-stop applications.

3.1    Clustering

How can a VM survive the failure of its hosting hypervisor or physical server? The solution involves clustering hypervisors across multiple physical servers, so that if one fails, active VM´s are transferred to another.

Heartbeat messages are passed between clustered hypervisors and a central Virtual Infrastructure Methodology (VIM) to maintain status monitoring. Shared storage is provided for the clustered hypervisors and further used to store virtual server disks.

3.2    Shared Storage

As a VM in a cluster can be moved between different physical hosts, and even because physical hosts can also fail and therefore be inaccessible, data cannot be stored locally on each server. The correct approach to keep data safe and accessible at the same time, is to add to the cluster a Shared Storage, also known as “Storage Array” or “Disk Array”.

Storage systems typically use special hardware and software along with disk drives in order to provide very fast and reliable storage for computing and data processing. Storage systems are complex, and may be thought of as a special purpose computer designed to provide storage capacity along with advanced data protection features. Disk drives are only one element within a storage system, along with hardware and special purpose embedded software within the system.

Storage systems can provide either block accessed storage, or file accessed storage. Block access is typically delivered over Fibre Channel, iSCSI, SAS, FICON or other protocols. File access is often provided using NFS or CIFS protocols.

Within the context of a storage system, there are two primary types of virtualization that can occur:

• Block virtualization used in this context refers to the abstraction (separation) of logical storage (partition) from physical storage so that it may be accessed without regard to physical storage or heterogeneous structure. This separation allows the administrators of the storage system greater flexibility in how they manage storage for end users.
• File virtualization addresses the NAS challenges by eliminating the dependencies between the data accessed at the file level and the location where the files are physically stored. This provides opportunities to optimize storage use and server consolidation and to perform non-disruptive file migrations.

3.2.1    RAID

A Storage system generally uses a technology that combines multiple disk drive components into a logical unit for the purposes of data redundancy and performance improvement, what is called Redundant Array of Independent Disks (RAID). Data is distributed across the drives in one of several ways, referred to as RAID Levels, depending on the specific level of redundancy and performance required.

For more information, please visit http://en.wikipedia.org/wiki/RAID.

3.3    High Availability

High Availability checks the health of virtual machines and detects problems. If an operating system failure is detected, the hypervisor automatically restarts the virtual machine. If a virtual machine´s underlying physical server fails, it restarts the application on another physical server.

3.4    Fault Tolerance

While HA involves rebooting virtual machines (and the associated downtime), Fault Tolerance (FT) works around that problem by letting customers run a “shadow instance” of a production VM that is maintained in lockstep with main instance.

The shadow instance takes over if something happens to the production virtual machine, picking it up immediately without having to restart.

However, doing so does consume additional resources, as FT is effectively a mirroring method, so enabling the technology involves doubling up the hardware.

4. ELIPSE LICENSING

Elipse Software products are generally licensed using a hardware key – HASP USB hardkey.

Commercial hypervisors generally do not support a stable mapping of a physical host USB port directly to a VM. In our internal tests platform, we have used AnywhereUsb/14 Hub USB device provided by Digi (https://www.digi.com/products/usb-and-serial-connectivity/usb-over-ip-hubs/anywhereusb) on a local network (Lan 100 mbps default) with redundant interface and source; this device has been performing reliably and stably in our applications, and the return we get for other clients using this device (or similar) from the same vendor is also positive.

VMWare is the only hypervisor that actually supports this feature natively. However, each Elipse Virtual Machine must be configured with HA/FT disabled and linked to a fixed Physical server where the hardkey is attached.

For all other hypervisors, or when HA/FT in VMWare is needed, a softkey license is required.

Elipse Software products are compatible with various hypervisors and have been tested up to Dec/2019 with Microsoft Hyper-V (Windows 10, Server 2008,2012,2016,2019) and VMWare (ESX 4, 5, 6.X).

4.1    Softkey Generation

The softkey generation software is provided upon request. The procedure generates a pre-license based on machine information. This pre-license is sent to Elipse Software, which returns the license to be installed at the computer.

Important Information:

• Softkey licenses will be generated by Elipse Software only once. Before sending the pre-license to Elipse, please be sure you have collected it at the definitive VM running at the correct host.
• To better identify which type of licensing is required, you must inform Elipse Software which architecture will be used in your project.

4.2    Periodical Verification and Upgrade

All softkey licenses have an expiration date and therefore must be reprogrammed periodically. There are two procedures available for the upgrade: Elipse license manager (ELIC) and manual upgrade.

4.2.1    Elipse License Manager

It offers an automatic upgrade tool via internet. By using Elic, one computer in a DMZ of system network can receive the upgrade in a timely manner and transfer it to the VM or physical machines where the softkey or even the hardkey is installed.

Elipse Software can also send you emails or alerts whenever a license is near expiration or whenever an upgrade procedure has failed.

4.2.2    Manual Upgrade

It can be used if there is no internet connection available, or if by some other reason, the upgrade could not be performed by Elic.

5. ELIPSE E3 AND POWER – POSSIBLE ARCHITECTURES

5.1    Redundancy

Elipse E3 and Elipse Power SCADA systems have their own redundancy management. To use it, you need two licenses of each Server, and to configure each one as a different VM. Then, at the E3 Domain configuration options, the VM configurations must be defined, as well as other redundancy profiles and configuration options. Typically, native domain redundancy is capable to switch over (or to recover to failover server) in 2 to 30 seconds in average, depending on the application size and configuration.

However, HA and FT offer different redundancy options, which can be used regardless of the presence of E3 native redundancy.

Basic HA feature allows restarting a single VM again upon a hardware or operating system failure detection, not internal software failures. In this case, you have only one E3 Server license in a single VM, which is destroyed and restarted from beginning. Even when a physical host fails, HA can restart the VM at another host in about 30 to 60 seconds average.

HA feature can also be used alongside the E3 native redundancy, so in fact you can have a Quad-redundancy schema, just as follows:

Some hypervisors may also charge HA features separately, depending on the number of virtual CPUs (vCPUs) on the VM.

On the other hand, FT basically avoids the HA VM startup time at a network and CPU cost, keeping a second VM lockstep with a primary VM. In a few words, FT is capable of replacing native E3 redundancy system but it is designed to overcome only a hardware failure, just like HA. Anyway, FT can still be used in conjunction with E3 native redundancy in order to prevent hardware, OS, or application software failures.

However, in case of a hardware failure only, this architecture is capable of never switching over to the E3 Server VM2 Stby using native redundancy, because FT detection is likely to happen first.

5.2    Project Files and Libraries

Elipse E3 and Elipse Power database and library files (PRJ and LIB) must be kept on both Servers if you are using native redundancy (i.e. on both VMs). In order to configure a running application, E3 Studio must have network access to the servers and database files, which can be declared into E3 Domain using a network path (ex: \MACHINE1Application) or network shared path (as a F: or G: directory for example).

However, a hypervisor or Windows Server feature called DFS (Distributed File System) can be used to simplify both database sync between VMs and E3 Studio access. With DFS, a common network or sharing folder can be declared identically on both servers and other machines, like E3 Studio. Although for each machine it seems to be an independent path with the same name, in fact DFS takes care of synchronizing all folder files automatically between all partners, replicating the changes whenever they happen.

In order to allow this synchronization to happen while main processes are running, E3 version 4.5 introduces a special feature called “Hands-Off Mode” that allows runtime changes at project files, which shall be enabled to become DFS usage possible.

5.3    Database

E3 native redundancy is capable of synchronizing process data historical databases (SQL or Oracle). However, in a virtualized environment it makes no sense, since database files can be stored at the external storage disks, not inside each VM. So, for practical reasons, native database synchronization should be disabled.

The recommended approach for a virtualized E3 Application is to design an independent VM for the Database software engine (the VM where you install SQL Server or Oracle software) and place database data files directly at the external storage disks, where data will be safer due to RAID schema.

6. ELIPSE PLANT MANAGER

Elipse Plant Manager (EPM) recommended architecture relies on a safe storage for current archive and user-defined backups for older archives. Best performance is reached following these guidelines:
a) Define a VM for SQL Server system, with HA if available.
b) Define a VM for EPM Server, with HA/FT if available.
c) During EPM Database configuration, provide different paths for Database and Log files, with each path representing different physical disks/volumes. It increases system I/O capacity.
d) Install Interface Server at local data origins.

7. REFERENCES

http://www.vmware.com/virtualization/virtualization-basics/what-is-virtualization.html

http://en.wikipedia.org/wiki/Hypervisor

http://www.cio.com/article/732479/How_to_Evaluate_High_Availability_Options_for_Virtualized_IT_Environments

http://cloudpatterns.org/design_patterns/hypervisor_clustering

Elipse E3 User’s Manual, version 4.5

Elipse Plant Manager User’s Manual, version 2.0