Migrating Virtual Services
Avi Vantage supports easy migration of virtual services from one Avi Service Engine (SE) to another, as would be needed when an Avi SE needs to be disabled for maintenance or upgrade.
Using the steps in this article, the virtual services on an Avi SE can be migrated to another Avi SE. The migration is transparent to end users of the virtual service, and designed to deliver no perceptible degradation in performance. Indeed, if the SE group is redefined to utilize more powerful hardware, performance should increase, as opposed to remain unchanged.
Note: Migration is not supported on a legacy active/standby SE group.
Migrating an Individual Virtual Service
- Navigate to Applications > Virtual Services.
- Click the name of the virtual service to be migrated.
- Hover the mouse over the name of the virtual service to display the quick edit menu for the virtual service.
- Click Migrate.
- By default, Avi Vantage will make a best choice for an SE on which to place the virtual service, or you can manually select an Avi SE from the SE list displayed. Especially if migrating to new hardware such that none of the existing SEs are acceptable, click Create Service Engine and select the host on which to create the SE.
Avi Vantage shows the progress of the migration:
Migrating All Virtual Services
- Navigate to Infrastructure > Clouds.
- Ensure you are on the Service Engine tab.
- Select the checkbox next to the Avi SE to be disabled.
- Click Disable.
Avi Vantage (re)places all virtual services from the Avi SE marked for disablement onto other SEs. Depending upon prevailing conditions (e.g., high client loads), a new SE may be auto-created, which can take several minutes. After all the virtual services have been placed (on one or more SEs), the original Avi SE is disabled and its health icon turns to grey (as illustrated above by Service Engines
Avi-se-nnlah). To view the virtual services that are on other enabled SEs, including any migrated virtual services, click the plus sign at the right-hand end of the row (not on the SE name). The result will resemble the following:
Note: For more on disabling Avi SEs, read the Disable SE article.
In both of the above scenarios, no mention was made of potentially changing the definition of the SE group prior to initiating migrations. Barring such changes, migrated virtual services find themselves (re-)placed on pre-existing or newly spun-up SEs with identical hardware configurations.
However, if migration to new hardware is required, the administrator needs to change the properties of the SE group prior to undertaking any VS migrations. Changing the SE group definition has no effect on SEs that are already running. Only when new SEs are spun up does the new SE group definition come into play. Virtual services placed thereafter find themselves:
- Placed on SEs whose servers are
- attached to potentially different networks (but reachable by clients, back-end servers, and Avi Controllers), and
- equipped with more (or less) powerful CPUs having different memory and disk configurations.
- Assigned more (or less) vCPUs and different virtual disk and memory capacities.
- General information about Service Engine groups
- For information related to the SE group settings
max_scaleout_per_vs, refer to Impact of Changes to Min/Max Scaleout per Virtual Service.