What’s Next for VMware Edge Compute: Let’s Go Over the Edge

With a sustained focus on and investment in edge computing, VMware is advancing into the future. Processing and managing data and applications near to where they are consumed and generated is the focus of this quickly expanding business.

The VMware Edge Compute is home to a sizable and expanding number of devices. The need for comprehensive and consistent Edge computing management outside of centralized data centers and clouds is on the rise as business drivers such as data transmission costs, lower latency response requirements, privacy laws, data governance, and 5G/6G rollouts continue to expand.

Long before VMworld 2021’s Vision and Innovation Keynote and Edge Breakouts, xLabs, a specialist team housed in VMware’s Office of the CTO, invested in and accelerated VMware Edge Compute technologies. We are eager to unveil more ground-breaking technology at VMware Explore 2022 to support our customers as they expand and manage their Edge workloads:

• Assisting customers in overcoming the limitations of edge computing to Satisfy their objectives for autonomy while utilizing the tried-and-true ESXi workhorse (Project Keswick)
• Modernizing virtualized world power grids
• Using Kubernetes, machine learning at the edge (Project Yellowstone)
• Balance of Workloads at the Edge (Work Balancer for Tanzu Kubernetes Grid Edge Workloads).

VMware Edge Compute: Project Keswick

At scale, even simple things frequently create complexity. The same applies to deployments. As the number of devices in an edge deployment increases to the hundreds of thousands or millions, governance and visibility issues also increase. What software versions, for instance, are these VMware Edge Compute devices running? When new versions are released, how do we update these programs? Additionally, due to their remote locations, these devices are frequently challenging to access, and updating each one takes time to provide uniform definitions for how infrastructures and workloads are run.

Project Keswick combines GitOps and ESXi, a dependable hypervisor. Version control and CI/CD are made available to us by GitOps, allowing us to document, manage, and provision infrastructure. We specify how the infrastructure should be configured and the workloads it should support as part of this flow using a YAML file.

Here is an example YAML file that defines a straightforward deployment. We would like to deploy 3 pods (replicas) to run the Nginx app using the most recent container image (hello-world: latest):

Each ESXi device linked to the git repository will be able to get this configuration update after this file is committed to source control (git). Endpoints pull their modifications down and update when they are prepared for an update.

The levels of Project Keswick are described in this architecture diagram. The Infrastructure and Workloads layers are specified through Kubernetes manifests, which are YAML files kept in a git repository. Project Keswick uses a listener on the git repository to track down manifest changes, and when the node is prepared to update, it executes the new instructions.

The use cases for Project Keswick were designed with intermittent connectivity in mind. Nodes won’t always be prepared or in the ideal location to upgrade, but when they are, they can download the most recent versions and perform an update themselves.

VMware Edge Compute: Virtualization of Workload in Power Substations

The necessity for innovation in the energy sector is highlighted by recent problems with utility grids and power outages. Particularly, power substations, or the places in-between where power plants and residences or businesses are located, are usually remote, unconnected, and unequipped to handle the rising demand for a bidirectional flow of power. When voltage transmission substations were first constructed, energy only flowed in one direction: from the power plant, through the substation, to residences and commercial buildings. Power substations in this concept reduce voltage to the proper levels for their destinations. Today, there is an increasing requirement for the grid to handle the bi-directional flow of electricity back to the grid as more renewable energy is produced at homes and businesses using options like solar panels.

To upgrade our power grids, VMware is making investments with Intel and Dell as our co-innovation partners.

The Power Substation Workload Virtualization project by VMware Edge Compute allows for the flow of energy in both directions. In the process, it efficiently gets the most out of physical hardware assets that run mission-critical software managing the flow of energy. Due to its fast-moving monitoring of electricity, this Virtual Protection Relay (VPR) program has highly stringent networking restrictions! Furthermore, testing the VPR program itself requires special equipment to deliver simulation data.

Want to know more about VMware? Visit our course now.

The testing environment we created to enable electrical substations to perform their VPR software resiliency checks is depicted in the architectural diagram below. To support real-time operating systems, the precision time protocol, and the parallel redundancy protocol for networking resilience, the Power Grid Virtualization project modified ESXi 7.0.3 at its core. With the help of this upgrade, we were able to support the VPR software and testing apparatus:

The Doble Power System Simulator is where the workflow in this diagram begins at the bottom. The VPR Services and Simulation Management & Troubleshooting host, which is run on servers with ESXi 7.0.3, receives simulated amp readings from this device across the actual and virtual network switches. It is important that VPR software can be extensively tested to ensure that it can identify variations in amps to prevent damage. Variations in amps have the potential to seriously harm power substation equipment.

This experiment demonstrated that ESXi is capable of supporting parallel redundancy protocol, precision time protocol, and real-time operating systems. So that electricity substations are better prepared for future transformation, we are eager to keep offering our solution for running and testing VPR software with partners and customers.

Project Yellowstone

Now let’s talk about machine learning (ML) at the edge, which is dramatically changing global infrastructure and business. For instance, ML at the Edge is having a huge impact on the automotive industry. ML algorithms are fitted with thousands of sensors that collect a lot of data and are utilized in driverless vehicles, electric vehicles, and other innovative models. The sensors gather data and create a “picture” of the surroundings of the car, including pedestrians, the state of the road, traffic signals, and even the driver’s eye movement. As a result, there is a lot of data that needs to be processed quickly at the Edge due to volume, latency, and data protection restrictions.

IT administrators are experiencing a steep learning curve as firms use artificial intelligence (AI) and machine learning (ML) to automate more of their tasks. There is no guarantee that an ML task with inferences will match up with the correct node because of the wide diversity of accelerators and infrastructure that workloads are run on, which could result in failure or inefficient workloads that need time-consuming troubleshooting.

With Project Yellow Stone, we developed heterogeneous Edge AI acceleration for Kubernetes-based deployments. Recognizing and comprehending workloads at the Edge delivers speed, agility, and security to enable applications built with AI and ML.

To improve AI and ML tasks, Project Yellowstone makes use of cloud-native ideas. Several popular graph compilers, such as

• Project Yellowstone’s Apache TVM with Intel OpenVINO will allow users to:
• Set up workload clusters with the appropriate accelerators on the correct node.
• Dynamically auto-compile and tune ML inference models
• Utilize the accelerators that would be most effective for the workload.

Tanzu Kubernetes Grid Edge Workloads Work Balancer

Additionally, we are spending money on developing methods for balancing workloads at the edge. The advantages of using ML and other time-sensitive procedures can be successfully realized by ensuring that load balancing at the Edge is properly orchestrated.

Customers usually deploy Kubernetes on bare-metal devices rather than in virtual machines at the Edge due to resource constraints and non-isolation requirements. There are a couple of issues with this strategy, though:

• For bare-metal clusters, Kubernetes does not provide a network load balancing mechanism.
• The only load balancing options in Kubernetes are the NodePort or external IPs services.

Both of these choices are not the best. NodePort’s port range is constrained and requires users to have direct access to the node, neither of which is secure. To use ExternalIPs, users must explicitly give an IP to each node, which is unreliable and would require manual intervention if a node failed. Due to a shortage of IT personnel or sporadic network connectivity, manual repair is frequently ineffective.

With the help of this project, users can build a load balancer service just like they would in the cloud by using software-defined cloud management and Edge workload balancer for Kubernetes clusters deployed on bare metal.

Performance and execution are enhanced by developing a workload management capability at the Edge. Having the right tools, like load balancing, to maximize our resources becomes increasingly important when we apply techniques like ML to solving issues in compute-constrained environments at the Edge.

What’s Next for VMware Edge Compute? Click here.

Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.

For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com