API Developer Portal
API Docs
Community
Knowledgebase
Training
menu icon
  1. Home
  2.  / Services
  3.  / App Stack Services
  4.  / Distributed Infrastructure Management

Distributed Infrastructure Management

On This Page:

F5® Distributed Cloud App Stack 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 App Stack 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.

App Stack's Distributed Infrastructure Management service includes the following features

  • Fleet Configuration
  • Zero-touch provisioning
image2
Figure: App Stack Distributed Infrastructure Management

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.

image1
Figure: Label Mapping for Virtual Sites

Next the user defines the network policy for the fleet. App Stack 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.

image3
Figure: Fleet and Network Policy

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

App Stack 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 F5 Distributed Cloud software on Customer Site

    1. If a customer uses F5 Distributed Cloud hardware such as the Industrial Gateway or Industrial Server, the software is installed by the manufacturer.
    2. In the case of commodity 3rd party hardware, the system integrator or the customer installs software onto the commodity hardware.

  2. The hardware, with the 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 the node software boots up, it calls home to the centralized control and management plane.

  4. Trust chain bootstrapping

    1. Every F5 Distributed Cloud 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 the F5 Distributed Cloud 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 F5 Distributed Cloud Console (Console).
    4. After initial bootup, the 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. Industrial Gateway or 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 Console or via APIs and the customer site gets admitted to the customers’ global network of sites.
    7. Next, F5 Distributed Cloud 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 system, launched on the customer site.
    9. The site identity certificate is also used to initiate IPsec connections from the site to F5 Distributed Cloud's regional edges and to other sites.

Site in Public Cloud

  1. Installing F5 Distributed Cloud Software on Customer Site:

    1. The customer installs the 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 Console, via the cloud_init input field.

  2. Trust chain bootstrapping

    1. As soon as the 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 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 Console or via APIs and the customer site gets admitted to the customers’ global network of sites.
    4. Next, F5 Distributed Cloud 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 system, launched on the customer site.
    6. The site identity certificate is also used to initiate IPsec connections from the site to F5 Distributed Cloud's regional edges and to other sites.

Concepts

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

© 2024 F5, Inc. All rights reserved | Trademarks | Policies | Privacy | California Privacy | Do Not Sell My Personal Information |