Note
|
This document is under development |
First, the structures of Neutron models are not consistent with the Alcor’s. We need a tool that can convert the existing Neutron network configurations into the Alcor’s, so that Alcor can process it. These converted network configurations should be handled by Alcor as batch creation requests with all parameters specified.
However, we still want users to be able to continue configuring on this OpenStack environment, as we use the tool to convert the Neutron network configurations to Alcor’s. At this time, the virtual switch in compute node side should still be taken over by neutron agents, and an Alcor Control Agent should be in a state in which agent can normally receive configurations, but does not send configurations to the virtual switch.
The newly generated configuration during this conversion may not be simultaneously converted to Alcor and processed, therefore, we also need to intercept all the write requests received by the Neutron during the conversion period. In addition to passing them through to the Neutron so that the Neutron can normally process the requests, we also need to copy those requests and temporarily cache them.
It should be mentioned that, in a production environment, the amount of write requests is very small compared to the amount of read requests, so the performance and memory consumption of the message proxy and cache can be controlled over the conversion period.
After the conversion of the original network configurations is completed, these cached write type requests should also be converted to Alcor’s requests and processed.
After that, the OpenStack CLI can switch to send requests directly to Alcor. The virtual switch of compute nodes can also be taken over to the Alcor Control Agent after waiting for appropriate time, so that the requests already in the neuron pipeline can be complete processed. Thus, the migration is completed.
Topic: Gracefully migrate user data and switch user traffic from existing OpenStack Neutron clusters to Alcor.