Administrators use disable Service Engine (SE) functionality to stop placement of virtual services on certain SEs and (optionally) to migrate multiple virtual services (VSs) from an existing SE. This can be useful during maintenance or decommissioning of an SE. Currently, VS migration lets user migrate a VS from one SE to another SE. Underneath, disable relies on VS migration from the disabled SE to prevent outages and performance degradation.
One can disable an SE using the Avi UI, CLI, or REST API.
The SE parameter
enable_state reflects the three states of an SE:
- SE_STATE_ENABLED: Default state of an SE
- SE_STATE_DISABLED_FOR_PLACEMENT: In this state the SE continues to serve traffic for virtual services already placed on it. However, new virtual services will not be placed on it. Migration of a VS cannot be initiated in this state.
- SE_STATE_DISABLED: New VS placements onto the SE are disallowed. In addition, the SE starts migrating its virtual services to others in its SE group. Client load is redirected in the same way native SE scaling is implemented.
It is important to note that (re)placements are made on the SE group in the usual way. They depend upon parameters set for the SE group and prevailing load conditions. Consequently, migration does not necessarily imply to a newly-created SE.
The following events are generated to reflect the status of this migration:
- MIGRATE_SE_STARTED: This event is generated when system initiates migration of virtual services on the disabled SE. The SE enters the OPER_DISABLING state.
- MIGRATE_SE_RESTARTED: If there is an error encountered while migrating, the system attempts to reinitiate migration.
- MIGRATE_SE_FINISHED: This event indicates all virtual services have been successfully migrated to other SEs without any failures and that the SE (whose virtual services are to be migrated) is not serving any virtual services. It enters the OPER_DISABLED state.
- MIGRATE_SE_FAILED: This state indicates the system failed to migrate at least one VS. The virtual services which encounter failures during migration continue to serve traffic. Manual intervention is required to completely take remaining virtual services out of that SE. The SE goes into the OPER_ERROR_DISABLED state.
- An SE remains in the SE_STATE_DISABLED state after the migration process is completed. Disabled SEs remain connected to the Controller and are counted towards the limit on the number of SEs in the SE group.
- The decommissioning of an SE requires an SE delete operation.
Disabling SE Members of a Legacy HA SE Group
An SE in a legacy HA SE group cannot be “disabled” per se. Instead, a special workflow is required:
- Use a
switchover serviceengine name-of-SEcommand to switch all active instantiations of virtual services to the other SE in the legacy group. The
switchovercommand determines which virtual services running on the SE are active; you need not enumerate them. Any standby instantiations running on the SE are unaffected. The
switchovercommand will appear to complete immediately, but in so doing it is merely acknowledging your intent to switch all active virtual services over to the other SE.
Note: Switchover functionality has not been exposed in the Avi UI.
- The VS switchovers occur asynchronously. Consequently, it is necessary to wait until all have completed. Poll the SE event log to verify all virtual services are in standby mode.
Note: The SE left running the standby virtual services is not and indeed dare not be in the SE_STATE_DISABLED state. On the contrary, it must be prepared to turn its virtual services active should the active SE fail. Neither can a third SE be added to the group for such a takeover purpose.
- The only way to prevent the standby SE from taking on any active virtual services is to remove it from the legacy SE group. One possibility is to move it into a “maintenance” SE group expressly created for the purpose.
- At this point, the legacy HA SE group comprises just one active SE. To return to a state of high availability, there are two options:
Option 1: If the Controller has write access to the cloud, it will automatically spin up a replacement SE.
Option 2: Otherwise, the user must manually add one to the group.
- To speed up Option 2, the user can spin up the replacement SE in the maintenance group prior to removing the standby SE from the legacy HA SE group.
- Switchovers can be accomplished either via the REST API or CLI.
- The SE moves referred to above can be accomplished via the REST API, CLI or UI.