VMware SD-WAN Software Release Types and Software Upgrade Strategy for Orchestrators and Gateways
Article ID: 320668
Updated On:
Products
Issue/Introduction
- Software release types and numbering
- Orchestrator types
- Software upgrade strategy
Environment
Resolution
Software Release Types and Numbering
For software releases, VMware SD-WAN and SASE follow an a.b.c.d numbering scheme where:
- a = Major (for example, 5.0.0) → A release with multiple large features and potentially significant architectural changes.
- b = Minor (for example, 5.2.0) → A release with a handful of small features or a couple of large features and no significant architectural changes
- c = Maintenance (for example, 5.2.2) → A release with potentially a large number of fixes for field found issues and internally found issue fixes with no features except potentially new hardware platform support.
-
d = Rollup Release (for example 5.2.2.1) → A rollup is a cumulative aggregate of known customer found defect fixes or critical internal found defects that impacts the majority of customers.
Note: Issues fixed in hotfixes will typically be included in rollups.
Rollup Release builds for 4.x and earlier are distinguished by the image name's GA date where the format is YYMMDD (Year-Month-Day with no separators). For example a Release 4.5.1 rollup build which was created by VMware Engineering on January 12, 2023 would display as R451-20230112-GA.
Beginning with release 5.0.0 and later, a fourth digit is added to the Edge, Gateway, and Orchestrator builds. Adding a fourth digit for 5.0.0 builds and later allows customers to clearly see which software version is being used for a particular component. For example, the first rollup build for Release 5.1.0 would display as 5.1.0.1 and the second would display as 5.1.0.2 with a build name of R5102-20230217-GA.
UI Build: Starting from Release 5.2.0.4, VMware introduces Orchestrator UI Builds. A UI Build only contains fixes for UI issues, which are problems that affect how you use the Orchestrator's user interface. A UI Build does not include any fixes for management issues that impact the underlying functionality of the Orchestrator as a standard Orchestrator build would.
A UI build is added to an existing Orchestrator release and is distinguished by a unique build version listed below the Orchestrator build name. The UI Build can be located in the same way a user identifies the Orchestrator Version by clicking on the ? icon in the upper right corner of the Orchestrator UI screen.
For example, if an Orchestrator running version 5.2.0.4 with build R5204-20230831-GA is updated with UI Build version R5204-20230912-GA, that would appear immediately below the Orchestrator build with the name "UI Build". If an Orchestrator has no UI Build, a user only sees the Orchestrator build. The issues fixed by the UI Build are found in the respective Release Notes associated with that Orchestrator version and build. So, a UI Release associated with Orchestrator rollup build 5.2.0.4 is found in that section of the Release Notes.
Orchestrators Types
There are four types of Orchestrators and their traits influence the software upgrade strategy:
- Shared Orchestrator:
- Both the Orchestrator and Gateways are hosted and managed by VMware and used by multiple tenants (partners and customer enterprises). VMware Cloud Operations team controls when both the Orchestrator and hosted Gateways are upgraded.
- Partners can optionally deploy their own Partner Gateways for which they are responsible for the maintenance and software upgrades.
- Private Orchestrator:
- Similar to a Shared Orchestrator in that the Orchestrator and Gateways are hosted and managed by VMware, including when and to what software version the Orchestrator is upgraded.
- Partners can optionally deploy their own Partner Gateways for which they are responsible for the maintenance and software upgrades.
- The primary difference between a Private and an Shared Orchestrator is that the Private Orchestrator is for the use of a single Partner who limits Orchestrator usage to the Partner's own customers.
Note: Shared and Private Orchestrators are alike in that VMware hosts and manages them and controls when the Orchestrators and hosted Gateways are upgraded and which software version they use.
- Dedicated Orchestrator:
- VMware hosts the Orchestrator used by a single Partner who controls when and to which software version the Orchestrator and any hosted Gateways are upgraded. For this reason a Dedicated Orchestrator may be using a much older software version than what would be seen on Shared or Private Orchestrators.
- Regarding Gateways, the Partner has these options:
- VMware deploys and hosts the Gateways, but the Partner controls the Gateway software version.
- The Partner deploys and maintains their own Partner Gateways.
- Some combination of the two types.
- On Premises Orchestrator: This is a special category that differs from the others in that the customer hosts both the Orchestrator and the Gateways. The customer is responsible for the deployment, maintenance, and software upgrades for these Orchestrators and Gateways, and VMware Support and Operations has only a minimal role detailed below.
Customers also need to know which software versions are supported, and which have reached or are approaching end of support. To see which VMware SD-WAN software is supported, consult the VMware Product Lifecycle Matrix and filter for 'SD-WAN' under the Product Release column, and make plans to upgrade to a supported release well ahead of the end of support dates.
Software Upgrade Strategy
When a software release becomes generally available, the following timeline is expected to be followed:
-
Within three weeks, the VMware SD-WAN Cloud Operations Team will begin upgrading the Shared and Private Orchestrators and their hosted Gateways to the new release. If the release is an Orchestrator-only release, the Gateways are not upgraded. The Orchestrators are upgraded in a rotating lineup to make sure customers get the latest software as soon as possible.
Note: For a UI Build, both Shared and Private Orchestrators are upgraded within a week of the release. This is because the update is not disruptive to the Orchestrator or the customers using it. -
For a major or minor release it may take up to two months to complete all upgrades. It usually takes less time to upgrade all hosted Orchestrators and Gateways to a maintenance or rollup release.
- A Partner using a Dedicated Orchestrator would contact VMware Technical Support to schedule an upgrade of their Orchestrator and hosted Gateways, if any. The Partner would upgrade their Partner Gateways as needed once the Orchestrator was upgraded. VMware Operations would schedule a maintenance window for a Dedicated Orchestrator only after they had upgraded the Shared and Private Orchestrators first.
- For Shared and Private Orchestrator/Gateway upgrades, VMware would post a banner with details of what is being upgraded along with the date and time of the maintenance window at least one week prior to the scheduled upgrade. In addition to the banner, email notifications regarding the upgrades are sent to the partner administrators and direct customer administrators prior to the upgrade.
- VMware Operations does not post banners for Dedicated Orchestrator upgrades, but does send email notifications regarding the upgrades to the Operator users of the Orchestrator.
- For customers who have deployed On Premises Orchestrators and Partner Gateways, they can upgrade these components whenever they like with one condition: the customer must contact VMware SD-WAN Technical Support to review and validate their upgrade playbook to ensure the soundness of the customer's upgrade plan.
- Edge software upgrades are managed by the Partner or Customer.
- VMware is responsible for uploading the corresponding Edge software images to hosted Orchestrators (Shared, Private and Dedicated Orchestrators).
- For Customers deploying On Premises Orchestrators, VMware makes the Edge software available for download from the Customer Connect portal.
Feedback
