HPE Virtualized NonStop started as just a concept and challenge to the NonStop development team. Andy Bergholz, if you remember him, had sent the team off for some virtualization training and just asked “Could NonStop be virtualized”? “No”, “Never” “Of course not” “Why”? But then, as Andy suspected, there started a lot of “Well, what if…” conversations and in just a little while they had booted NonStop under OpenStack. That’s the way great leaders get things done.
NonStop needed to play in the virtual environment because our Telco clients were all ‘going to the cloud’. While that has taken much more time than expected, NonStop was ready and could be launched using OpenStack. As it turns out, even though development was told OpenStack when the rubber hit the road, the hypervisor of choice was VMWare. So a bit more development to support the more popular hypervisor and suddenly NonStop had a number of Proof of Concepts going on to try out virtual NonStop.
In our world today everything seems to be cloud-oriented. Development has marching orders to develop “cloud-native”. And while it appears everything is going ‘to the cloud’, what’s really happening is that datacenters are being run like clouds. Things can be provisioned quickly. Equipment is reusable and may be deployed for one application one day and used for a different purpose the next. What everyone wants is the ‘cloud experience’ of being able to launch things easily and quickly, use them for as long as needed and then place them back on the ‘available pile’, while only paying for what was used. This can now be done Inhouse in your own datacenter as easily as it is done in AWS, Azure, and GCP, one example being our own HPE Greenlake model. HPE builds and manages a private cloud in your datacenter. The cloud that comes to you. Still a cloud nonetheless.
Now one can buy, and Greenlake supports, the converged NonStop systems. Our latest, the NS8 and NS4 go through an intense series of integration testing before any system is delivered to a customer. I’m not sure how many realize the amount of testing done on a NonStop but before it’s shipped, it has been run pretty hot and checked out extensively. So there are advantages to the converged system, it is ‘known to be good’. Hopefully, this does not take away from our Virtualized NonStop which is still NonStop, when configured per our guidelines. The advantage is that you can pick the hardware (within reason – no Raspberry Pi yet). This allows you to choose whatever hardware on which your company has standardized. From a hardware perspective, it is very flexible. Let’s quickly review a virtualized NonStop system.
Virtualized NonStop needs a high-speed pair of switches to interconnect our virtual machines (VM). These switches should support 25-100GbE and we need two separate, independent switches that operate just as the X and Y fabric on our platform systems (NS8 & NS4). On the platform systems, a NonStop will consist of at least a pair of DL360’s for the logical CPUs (NonStop Operating System), at least 2 DL380’s for the Storage CLIMs, and another pair of DL380’s for the IP CLIMs. Additionally, there will be a Windows system running the NonStop Console.
To create a virtualized NonStop we still need all the components (processors, CLIMs, and the console) but they have become virtual machines (VM). So there is a VM that runs the NonStop operating system a vCPU and we will need to have at least two vCPU VM’s for it to be ‘NonStop’. Also, those two VM’s must not be run in the same physical server. I will load VMware ESXi on a physical server let’s call it Phy1. I will load ESXi on a second server, called Phy2. Running ESXi allows VM to share that server. So I would run vCPU0 in Phy1 and vCPU1 in Phy2. Phy1 and Phy2 must both have a high speed (40GbE) 2 port NIC where port 1 is connected to one of the high-speed switches (fabric X) and the other port is connected to the other switch (fabric Y). Now, vCPU0 and vCPU1 can connect with each other and exchange “I’m alive” messages. In Phy1 I would also load a storage VM CLIM, vSCLIM1, and an IP VM CLIM vIPCLIM1 and on Phy2 I would do the same starting vSCLIM2 and vIPCLIM2. The CPU’s, and CLIM’s communicate over the high-speed switches just like they do over the InfiniBand Fabric on the NonStop Platform systems. In either Phy1 or Phy2 I would start a Windows VM and then load the NSC software onto it creating the NonStop Console which would also communicate with all the other VM’s (CPUs, IP CLIMs, and Storage CLIMs) over a separate virtual network path. It is documented in the ‘Hardware Architecture Guide for HPE Virtualized NonStop on VMware’ how to count up the required cores, memory, and storage that will be required because unlike other VMs NonStop requires dedicated resources for latency needs.
A Virtualized NonStop system requires a specific number of cores (not threads!), a specific amount of unshared memory and dedicated datastores. That means that creating a Virtualized NonStop system requires very specific and defined resources, physical separation yet near proximity of the separate servers because of the switches. That’s a lot of requirements for a public cloud but not so much for a private/GreenLake cloud.
Internally we have several virtual NonStop’s in our Center of Excellence (CoE) in Alpharetta, Georgia. These can be used for sandbox applications and testing and also for direct customer engagement. When it was decided that abat+, our premier manufacturing partner, would host a demo at Discover, it was natural to host the demo on our existing virtual NonStop systems. As you know, virtual NonStop runs the same Operating System, L.xx.xx as the converged systems. Anything that runs on the converged systems (NS7/NS3/NS8/NS3) will run on the virtual NonStop system.
Now let’s look at some of the issues in manufacturing. The challenges in discrete manufacturing, especially in automotive production, are constantly increasing. The focus is on improving products with shorter innovation cycles at lower costs and higher quality (sounds a bit like IT…). Effective production control is the only way to achieve the 3 major requirements of process and quality improvement, cost reduction, and production flexibility. A high number of variants is usually accompanied by extensive growth in the existing system landscape, which leads to a rapid increase in the scope of costs. To meet the challenges of the market, manufacturers in the automotive industry are confronted with integrating a constantly growing number of different system solutions.
The abat+ Manufacturing Execution System (MES) PLUS, offers a product that provides universal control of the manufacturing processes while reducing manufacturing complexity. Instead of operating and maintaining countless systems within the production environment, PLUS allows a customer to consolidate the global manufacturing landscape across production plants to a single system. The abat+ MES optimizes order control and thus forms the core of the customer order process.
The modular design of the system enables flexible usage of PLUS, as it can be adapted to different production scenarios. Both the modules themselves and PLUS as a whole enables the mapping of interrelated business processes from numerous individual services, thereby reducing complexity.
This architecture ensures maximum flexibility and rapid implementation. The services can be addressed either directly in the backend or as microservices in the cloud. It is possible to use pre-existing modules in the system for business processes that are to be newly implemented or optimized. This guarantees simple and fast process adaptation – even across production sites. The possibility of simple system parameterization and standardization also allows a customer to significantly reduce the costs of maintaining and servicing when compared to in-house development. Thus, with our smart MES PLUS, a customer can react quickly and cost-effectively to changes in their manufacturing processes, implement them in production without downtime, and achieve a decisive competitive advantage.
Example of a widget-based PLUS dialog
The abat+ PLUS and their Discover demo will be running on an internal virtual NonStop System. The demo consists of two parts. The first part is a real dialogue based on PLUS widgets displayed on a screen and connected to the NonStop system. It simulates how each widget displays vehicle-relevant information provided by PLUS. With the help of the widgets, a staff member can perform coincidence checks (matching of part and vehicle), check vehicle characteristics, check recorded faults, and much more. These widgets are used by Daimler to reduce paper in the factory and are an example of how paper can be reduced by combining a lot of information on one screen.
The second part is a Virtual Reality (VR) session in which we intend to show the usage of PLUS at the assembly line. In the VR session, the user is able to act and work like a real staff member at the assembly line with the help of PLUS. The user will see and work virtually with the same dialog which is shown on the screen in part one.
The PLUS system itself has many other functions that are not part of the demos but it will be possible to discuss and show other functions from the PLUS portfolio in case Discover visitors want to know more about PLUS.
Finally, to meet the high demands for fail-safe and high availability in production-critical areas, the HPE NonStop forms a powerful basis for abat+ PLUS software. NonStop is always adapting, such as hardware-independent Virtualized NonStop in a VMware environment, and offers rich tools for DevOps, standardized development environments, and modern, open tools support for easy programming and integration. PLUS on HPE NonStop helps keep your manufacturing environment at the forefront of innovation and customer experience.
Be the first to comment