Ever since NonStop took its first steps into the virtualized arena, new and varied opportunities to improve the way customers use and manage the platform have arisen for developers to take advantage of. One such opportunity is to improve deployment and management experience. Moving from the traditional hardware-centric viewpoint to the more software-centric one that HPE Virtualized NonStop (vNS) offers means that we can enhance many of the deployment and management aspects as well. Last October, we had the pleasure of introducing some of the latest features of the deployment and management tools for vNS 3.0 on VMware vSphere at TBC 2021, some of which will be covered here.
Virtualized NonStop Easy Button
All of the vNS deployment and management tools in development are bundled under the NonStop “Easy Button” project, which aims at improving the Virtualized NonStop deployment and management experience and ultimately contributes to implementing NonStop as a truly agile software stack for modern private clouds. One could say that the program aims to make NonStop deployment as easy as clicking a button, hence the name.
Easy Button includes two primary tools that customers can take advantage of when deploying and managing vNS systems within VMware vSphere: a graphical vNS App for VMware vCenter and a set of VMware vRealize Orchestrator (vRO) workflows for vNS. The vNS App displays general information about each vNS system in a data center and interfaces with the vRO workflows to perform key deployment and maintenance operations. One can think of the vNS App as the ‘frontend’ counterpart to the vRO workflows, and likewise the vRO workflows as the ‘backend’ counterpart to the vNS App, though the workflows can be run directly from the vRO client as well. Let’s take a closer look at each of these tools.
vRealize Orchestrator Workflows for NonStop
VMware vRealize Orchestrator is an automation platform that allows users to create custom “workflows” that perform key tasks within vSphere. A set of NonStop-specific vRO workflows have been implemented to perform common tasks related to vNS deployment and maintenance. Among other things, the workflows shorten the amount of time required to perform key operations and reduce the amount of knowledge required to host a vNS system in vSphere. Most of the workflows accept local JSON files as input. All workflows can be launched directly from the vRO client, and a major subset of those workflows can be run from the vNS App in vCenter as well.
vNS App for VMware vCenter
The vNS App offers a new way to interact with vNS systems in vCenter. Instead of navigating the standard vCenter interface to search for components, which may be scattered across a data center, the vNS App shows all this information in one location.
Navigating through the NonStop systems deployed on a VMware Datacenter using the vNS App
Additionally, the vNS App provides graphical input fields for most of the vRO workflows, providing a visual, guided alternative to filling out JSON files for input to the vNS workflows.
Features in vNS 3.0
Several exciting features have been added to the vNS deployment tools for VMware vSphere as part of vNS 3.0. Let’s take a look at some of the more notable features.
Privilege checking for the vRO workflows was something that was specifically requested and has now been implemented in the latest release. While vSphere has a built-in privilege/permissions system, users running vNS workflows were not warned beforehand of a potential failure due to insufficient privileges, as the privileges are defined per-action and not per-workflow. In other words, if a workflow contains an action forbidden to the current user, the workflow will run up to that action, then fail due to insufficient privileges. Now, relevant privileges are checked prior to running any vNS workflow to ensure that the presiding user has the privileges required to complete the workflow. If any privileges are missing, they are noted in the vRO logs. Additionally, three user classes have been defined for use in deploying and managing vNS systems: vNS Administrator, vNS Creator, and vNS Monitor. In summary, the Monitor class has the ability to view system components and generate reports for review. The Creator class has the privileges of the Monitor, as well as the ability to deploy system components. Finally, the Administrator has the privileges of the Creator, as well as the ability to modify and delete system components. The privilege checking implemented for vNS workflows is completely integrated with the existing privilege system in vCenter. Users may define new classes as necessary or modify the privileges of the standard vNS user roles using vCenter. A workflow to load the predefined user classes to vCenter is also included in the latest release.
The new privilege checking feature prevents underprivileged users from running certain workflows
Something that was tricky and error-prone in the past was migrating vNS system components. In the latest release, two new workflows have been added to aid in this effort: ‘Migrate vNS VMs’ and ‘Migrate NSK Volumes’.
Migrating vNS VMs is necessary to perform frequent rolling upgrades of underlying system infrastructure. This task, while possible, is not straightforward to perform in vSphere. This is why the ‘Migrate vNS VMs’ workflows is such a great addition to the vNS deployment tools. While VMware vSphere has implemented methods to assist in migrating VMs between hosts and datastores, these are not entirely applicable to vNS VMs, given their fault-tolerant nature. Therefore, manually migrating these VMs can be tricky and error-prone at best. With the ‘Migrate vNS VMs’ workflow, one can move the VM to a new host or datastore with little hassle.
Just as migrating vNS VMs is an important task for a vNS system, so too is migrating system volumes. The new workflow, ‘Migrate NSK Volumes’, may be used to do just this. Similar to migrating vNS VMs, migrating NSK volumes comes with its own set of difficulties. Namely, access to the volume must be preserved during the migration (i.e. an online migration is required). Included in the vNS App is a new guided procedure to help users perform an online migration of their system volumes. The ‘Migrate NSK Volumes’ workflow is part of this guided procedure and does the work of copying the individual volumes to their new datastores and pointing the vCLIMs to the new volume locations. Currently, access to the NonStop system console is required to stop and start the volumes on either side of the migration, the process of which is outlined in the guided procedure.
In an effort to reduce the amount of input needed at once from the user, a new workflow has been implemented called ‘Configure vNS Resource’. The purpose of this workflow is to tag components in a vCenter server for use in future vNS systems. Currently, networks and datastores can be tagged for vNS use. The workflow leverages an existing feature in vCenter that allows users to create tags and assign them to objects. If a user has tagged components for use, other workflows will use this information to automatically provision suitable components of a vNS system. Automatic provisioning of networks and datastores is also a new feature in vNS 3.0.
Along with deployment and maintenance workflows, there is now a workflow to remove a system entirely from a data center. The ‘Delete vNS VMs’ workflow removes all vNS VMs and associated disks.
The Future of Easy Button
Looking to the future, we are trying to bring vNS closer to the idealized Easy Button process, the fabled ‘click of a button’ experience. This includes both expanding our currently offered features, as well as creating entirely new features. One feature we are looking to improve is the ‘Configure vNS Resource’ workflow, which is mentioned in the previous section. There are three additions we are looking to make to the feature:
- Define a data center as not eligible for vNS deployment. This would allow for specialized data center workloads without interfering with Easy Button functionality.
- Identify a cluster within a data center as only eligible for deploying vNS CPUs. This allows a user to have server specialization, and would be particularly useful if the datacenter has servers with different performance gradations (CPU power, IO latency).
- Identify a cluster within a data center as eligible for only deploying non-CPU VMs (vCLIMs and vNSCs). Similar to the above point, but for vCLIMs and vNSCs instead.
System Deployment Templates
When gathering user feedback, one point of pain has been creating the initial JSON input to create a system. Even for a small system, this input can be over 100 lines, which is difficult to complete for a new customer, especially one that is less familiar with vNS. Our way of tackling this issue is to introduce predefined system deployment templates. This would allow a user to create a minimal-sized JSON containing general information, specify the size of system they would like, and then our tool would automatically fill in the rest of the details.
For example, a user may decide that they want a small system. The user fills in some basic information about the system (left), then the feature would add the required 41 more lines (right) to fully define their system. In this case, it saves around 70% of the lines in the JSON, and would save even more for a medium or large-sized system.
System deployment templating would cut down on the required user input
Minimal System Deployment
To make the system deployment as fast and easy as possible, we are looking to implement minimal system deployment. System creation can take a good deal of time, sometimes requiring more than a full workday to finish if there are many large volumes. Minimal system deployment would get the essential subsystem up and running, and get it running up to at least a TACL. The user would then be able to perform tasks while additional system resources are still deploying. A user can make changes to the deployment, and the system will indicate to the user when it is fully ready and deployed.
Reconfigure VM Network Interface Resources
For post-deployment system maintenance, we are in the process of implementing the Reconfigure VM Network Interface resources feature. This would allow a user to add, remove, or provision networks for a system. This would be done while all parts of the system are running.
Be the first to comment