Distributed Infrastructure Management

VoltStack Distributed Infrastructure Management service enables customers to operate their distributed infrastructure like a fleet. Operating as a fleet means that customer declaratively defines his/her intent once, and VoltStack service then takes over the responsibility of ensuring the impacted sites are aligned with the defined intent. Examples of intent include operating system version, network policy, security policy and resource reservation such as CPU, memory.

VoltStack Distributed Infrastructure Management service includes the following features

  • Fleet Configuration
  • Zero-touch provisioning
Figure 1

Fleet Configuration

Fleet configuration capabilities can best be described through an example. Let’s take an example of a user defining a network policy for a specific segment of the fleet. First, the user segments the fleet using labels and virtual sites. A label is made up of two parts, key and value as follows

  • region=US-west, region=JP-north
  • model-year=(2015, 2016, 2017, 2018)
  • function=(spray, weld)

Once the sites are tagged, operators can define a virtual site using label key-value conditions. This can be visualized as follows using an example of a robot vertical use case.

Figure 2

Next the user defines the network policy for the fleet. VoltStack distributed control plane sends the network policy to the local control plane on each site selected by the virtual site. The local control plane on each site applies the network policy and collect statistics of rules hit per site. Fleet configuration can be visualized as shown in the following figure.

Figure 3

If a new site is added to the fleet, and the user applies the same labels on the site as defined previously, the sites get added to the configured virtual site automatically. The fleet configuration, such as network policy, is automatically applied to the new sites added to the virtual site, reducing the burden on operation teams and eliminating human errors.

Upgrading a single site’s operating system was described in earlier section. Fleet configuration capability enables a user to upgrade the operating system across the entire fleet (or segment of the fleet). First, the user defines the intent of upgrading the operating system from version 1 to version 2. Next, the user defines a deployment strategy across the fleet, such as a rolling update or A/B. A rolling update means that the operating system of every site in the fleet (or segment of the fleet) is upgraded sequentially. An A/B deployment strategy means the user wishes to test the upgrade on a set of “A” sites (e.g., dev sites) and compare the health with “B” sites (e.g., prod sites) that aren’t upgraded. Users can get an aggregated view of the upgrade status of the fleet in the virtual site dashboard.


Zero-Touch Provisioning

VoltStack Distributed Infrastructure Management service provides the ability to provision each customer site in zero-touch fashion. The benefit to customers, especially on the edge, is an accelerated new service rollout, without requiring technically skilled personnel to deploy and provision new sites. The zero-touch provisioning process is similar across private/public cloud and edge environments as described next.

Site in Private/Edge Cloud

  1. Installing Volterra software on Customer Site

    1. If a customer uses Volterra hardware such as the Volterra Industrial Gateway or Volterra Industrial Server, Volterra software is installed by the manufacturer.
    2. In the case of commodity 3rd party hardware, the system integrator or the customer installs Volterra software onto the commodity hardware.
  2. The hardware, with Volterra software installed, is then shipped from manufacturer or system integrator directly to the customer’s location, such as private data centers, retail stores, factory sites or charging stations.

  3. At the customer site, unskilled personnel has to simply plug-in the hardware and as soon as Volterra node software boots up, it calls home to the centralized control and management plane.

  4. Trust chain bootstrapping
    1. Every Volterra hardware includes a Trusted Platform Module (TPM) that is programmed with the customer’s secure device identity at the manufacturing facility. This is done in a completely automated fashion and automatically scheduled once the customer places an order from Volterra CRM portal.
    2. In the case of commodity hardware, if it supports TPM then the system integrator programs the TPM with the customers’ secure device identity.
    3. If the commodity hardware does not support TPM, the system integrator (or customer) provides an identity token during the provisioning process. This identity token can be generated by the customer directly from the Volterra Console.
    4. After initial bootup, Volterra software provides the secure device identity/identity token when calling the centralized control and management plane to register the site.
    5. Next, the customer administrator is given an opportunity to approve the registration of the customer site
      1. Volterra Industrial Gateway or Volterra Industrial Server comes with GPS and LTE providing the operator geo-coordinates of the physical location. Customers could optionally add additional steps to the provisioning process such as verifying with the person performing the installation.
    6. Once the operator is ready to approve the registration, they click on “Accept” in the Volterra Console or via APIs and the customer site gets admitted to the customers’ global network of sites.
    7. Next, Volterra Identity Authority in the centralized management plane downloads a cryptographically signed X.509 certificate to the site. This certificate called the site identity.
    8. The site identity certificate is now used as a root of trust to assign an identity to any POD, customer or Volterra, launched on the customer site.
    9. The site identity certificate is also used to initiate IPsec connections from the site to Volterra regional edges and to other sites.

Site in Public Cloud

  1. Installing Volterra Software on Customer Site:

    1. The customer installs Volterra software from the public cloud marketplace into his/her virtual private cloud instance.
    2. During installation, the customer provides the identity token, generated from the Volterra console, via the cloud_init input field.
  2. Trust chain bootstrapping
    1. As soon as Volterra software boots up, it calls the centralized control and management plane to register the site and provides the identity token.
    2. The customer gets a notification on Volterra console informing him/her the site is waiting for registration to be approved.
    3. Once the customer administrator is ready to approve the registration, they click on “Accept” in the Volterra Console or via APIs and the customer site gets admitted to the customers’ global network of sites.
    4. Next, Volterra Identity Authority in the centralized management plane downloads a cryptographically signed X.509 certificate to the site, called the site identity.
    5. The site identity certificate is now used as a root of trust to assign an identity to any POD, customer or Volterra, launched on the customer site.
    6. The site identity certificate is also used to initiate IPsec connections from the site to Volterra regional edges and to other sites.

Concepts

The following concepts are used by Distributed Infrastructure Management features. Click on each one to learn more:


How-to’s

The following How-to guides are examples of using Distributed Infrastructure Management features: