Distributed-based batch tenant migration method and system, device

Abstract

The application provides a distributed batch tenant migration method and system and device, and the method comprises the following steps: adding high-priority, full-amount, cookie-carrying, in-coming and out-going security group flow tables on a tenant virtual machine and a host machine; performing a first ping test on the virtual machine traffic on a tenant gateway; performing batch tenant migration; performing a second ping test on the virtual machine traffic after the tenant migration, and comparing two snap files; if the virtual machine traffic is connected after the migration, the migration of the virtual machine is successful; and deleting the full-amount, high-priority, cookie-carrying flow tables on the virtual machine and the host machine after the migration is completed. The application issues high-priority, cookie-carrying security group flow tables before the migration, performs two ping tests on the virtual machine traffic before and after the migration, compares the two ping test results, processes and locates the problematic virtual machine quickly, and maintains the stability of the existing network; and the batch tenant one-key migration based on a shell script improves the tenant migration efficiency of the existing network.

Description

Technical Field

[0001] This invention relates to the field of multi-tenant architecture technology in cloud computing environments, and more particularly to the field of batch tenant migration technology from virtual network elements to physical network elements in elastic networks; specifically, it relates to a distributed batch tenant migration method, system, and apparatus. Background Technology

[0002] A tenant network is a virtual network established and managed by tenants in a cloud computing environment. It connects virtual machines and virtual network elements to meet the isolation and security requirements between different applications or services and between various internal components. Each tenant can build a private or public network environment that meets its specific needs and has certain isolation and security protection measures.

[0003] However, since the performance of virtual network elements is inferior to that of physical network elements, in order to improve the performance of tenant network elements and enhance the smoothness of tenant networks, it is necessary to migrate tenants from virtual network elements to physical network elements in many applications of cloud platform tenant networks.

[0004] However, in the existing cloud platform network, the number of tenants is usually in the hundreds or thousands. If the migration operation is performed on each tenant individually, it will inevitably lead to low efficiency of the migration operation.

[0005] In addition, during the actual migration process from virtual network elements to physical network elements, after the tenant migration is completed, the tenant virtual machine traffic often becomes interrupted, causing the tenant migration to fail and resulting in poor stability of the live network.

[0006] Therefore, there is an urgent need to design an automated tool to enable batch migration of tenants and prevent customer traffic disruptions after migration, thereby improving the stability of the existing network and addressing the aforementioned difficulties and pain points of existing technologies. Summary of the Invention

[0007] Therefore, the purpose of this invention is to design a distributed batch tenant migration method and system. By issuing a high-priority security group flow table with cookies before tenant migration, performing two virtual machine traffic ping tests before and after migration, checking the results of the two ping tests, and quickly identifying virtual machines with no traffic after migration, problematic virtual machines can be found and repaired in time, thereby maintaining the stability of the live network. Furthermore, the newly added high-priority security group flow table with cookies is deleted after tenant migration, improving the efficiency of batch tenant migration.

[0008] This invention provides a distributed batch tenant migration method, comprising the following steps:

[0009] S1. Add high-priority, full, cookie-enabled inbound and outbound security group flow tables to all virtual machines and host machines owned by the tenant;

[0010] Cookies, short for small text files, are data (usually encrypted) stored on a user's local terminal (client-side) by certain websites to identify the user. They conform to the RFC 6265 standard.

[0011] The cookie flow table is only used to identify the flow table version and generally changes with the version of the controller.

[0012] Security group flow tables are divided into two types: outbound and inbound. One type allows source IPs, and the other allows outbound IPs. Traffic can only pass if traffic is allowed in both directions.

[0013] S2. Perform the first ping test on all virtual machine traffic of the tenant on the tenant gateway to check whether the virtual machine traffic is connected; save the test results of the first ping test to the local snap file;

[0014] S3. Call the controller's tenant migration interface to write a batch of tenants into the tenant file. Execute the migration script to iterate through the tenants in the tenant file one by one and perform migration on each tenant in the tenant file to achieve batch tenant migration.

[0015] The CNP (Cloud Network Platform) controller is a core component of cloud products, primarily responsible for distributing configurations on network elements, distributing flow tables on compute nodes, allocating network element management IPs, and managing switches.

[0016] S4. After the tenant is migrated, perform a second ping test on all virtual machine traffic of the tenant on the new tenant gateway, and save the results of the second ping test to another snap file; compare the first and second snap files to see if the virtual machine traffic is connected after the migration.

[0017] If the virtual machine traffic is connected after the tenant migration, the virtual machine migration is considered successful, and the process proceeds to step S5.

[0018] S5. After the migration is complete, delete the high-priority flow tables with cookies that are fully allowed on both the virtual machine and the host machine to prevent flow table residue.

[0019] Furthermore, in step S4, the virtual machine traffic is compared to see if it is connected after migration. If a virtual machine has connected traffic before migration but not after migration, the virtual machine migration is considered to have failed (recorded as failed), and the batch migration is terminated. The virtual machines with disconnected traffic after migration are located, tenant traffic is restored as soon as possible, and the root cause of the problem is located to ensure the stability of the live network.

[0020] Furthermore, the main script for implementing the bulk tenant migration in step S3 is the migrate_bulk_tenant.sh script.

[0021] Furthermore, the script used to perform traffic ping tests on the virtual machine in steps S2 and S4 is the vpping.sh script.

[0022] Furthermore, the method for pinging the tenant's virtual machine traffic in steps S2 and S4 includes:

[0023] Before and after tenant migration, the main script calls the vpping.sh script to compare the ping test results of virtual machine traffic before and after migration.

[0024] The present invention also provides a distributed batch tenant migration system that executes the distributed batch tenant migration method described above, including:

[0025] Add Inbound and Outbound Security Group Flow Table Module: Used to add high-priority, full, cookie-enabled inbound and outbound security group flow tables on all virtual machines and hosts owned by a tenant;

[0026] First ping test module: Used to perform the first ping test on all virtual machine traffic of the tenant on the tenant gateway to check whether the virtual machine traffic is connected; save the detection results of the first ping test to the local snap file;

[0027] Batch tenant migration module: This module calls the controller's tenant migration interface to write a batch of tenants into the tenant file. It then executes a migration script to iterate through the tenants in the tenant file one by one and performs the migration for each tenant in the file, thus achieving batch tenant migration.

[0028] The second ping test module is used to perform a second ping test on all virtual machine traffic of the tenant on the new tenant gateway after the tenant migration. The test results of the second ping test are saved to another snap file. The first and second snap files are compared to check whether the virtual machine traffic is connected after the migration. If the virtual machine traffic is connected after the tenant migration, the virtual machine migration is considered successful and the process proceeds to step S5.

[0029] The Flow Table Deletion module is used to delete high-priority flow tables with cookies that are fully allowed on both the virtual machine and the host machine after migration, preventing flow table remnants.

[0030] Furthermore, the second ping test module includes:

[0031] Migration Failure Recovery Traffic Unit: If a virtual machine has uninterrupted traffic before migration but not after migration, the migration is considered a failure, and the batch migration is terminated. The unit also locates the virtual machines with uninterrupted traffic after migration, restores tenant traffic as soon as possible, and identifies the root cause of the problem.

[0032] The present invention also provides a distributed batch tenant migration apparatus, which is equipped with the distributed batch tenant migration system as described above.

[0033] In this embodiment of the invention, the number of customer work orders is reduced to 0 after the tenant migrates.

[0034] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the distributed batch tenant migration method described above.

[0035] The present invention also provides a computer device, the computer device including a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the distributed batch tenant migration method described above.

[0036] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0037] This invention, based on a distributed batch tenant migration method, distributes high-priority security group flow tables with cookies before migration. It performs two virtual machine traffic ping tests before and after migration, comparing the results. If traffic was available before migration but not after, the migration is considered a failure, allowing for rapid processing and location of problematic virtual machines. It enables one-click batch tenant migration based on shell scripts. By adding high-priority security group flow tables with cookies and comparing virtual machine ping tests before and after migration, it can immediately identify virtual machines with unavailable traffic and repair it, maintaining network stability, improving the timeliness of tenant migration, and ensuring normal tenant traffic after migration, significantly improving the efficiency of batch tenant migration on the current network. Attached Figure Description

[0038] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention.

[0039] In the attached diagram:

[0040] Figure 1 This is a flowchart illustrating the overall process of the distributed batch tenant migration method according to an embodiment of the present invention.

[0041] Figure 2 This is a flowchart of a distributed batch tenant migration method according to the present invention;

[0042] Figure 3 This is a schematic diagram of the configuration of a computer device according to an embodiment of the present invention. Detailed Implementation

[0043] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of systems and products consistent with some aspects of this disclosure as detailed in the appended claims.

[0044] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0045] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0046] The embodiments of the present invention will be described in further detail below.

[0047] This invention provides a distributed batch tenant migration method, see [link to relevant documentation]. Figure 2 As shown, it includes the following steps:

[0048] S1. Add high-priority, full, cookie-enabled inbound and outbound security group flow tables to all virtual machines and host machines owned by the tenant;

[0049] Cookies, short for small text files, are data (usually encrypted) stored on a user's local terminal (client-side) by certain websites to identify the user. They conform to the RFC 6265 standard.

[0050] The cookie flow table is only used to identify the flow table version and generally changes with the version of the controller.

[0051] Security group flow tables are divided into two types of security groups: outbound and inbound. One type allows source IPs, and the other allows outbound IPs. Traffic can only pass if traffic is allowed in both directions.

[0052] S2. Perform the first ping test on all virtual machine traffic of the tenant on the tenant gateway to check whether the virtual machine traffic is connected; save the test results of the first ping test to the local snap file;

[0053] S3. Call the controller's tenant migration interface to write a batch of tenants into the tenant file. Execute the migration script to iterate through the tenants in the tenant file one by one and perform migration on each tenant in the tenant file to achieve batch tenant migration.

[0054] The CNP (Cloud Network Platform) controller is a core component of cloud products, primarily responsible for distributing configurations on network elements, distributing flow tables on compute nodes, allocating network element management IPs, and managing switches.

[0055] The main script for implementing bulk tenant migration is the migrate_bulk_tenant.sh script.

[0056] S4. After the tenant is migrated, perform a second ping test on all virtual machine traffic of the tenant on the new tenant gateway, and save the results of the second ping test to another snap file; compare the first and second snap files to see if the virtual machine traffic is connected after the migration.

[0057] If the virtual machine traffic is connected after the tenant migration, the virtual machine migration is considered successful, and the process proceeds to step S5.

[0058] If a virtual machine has uninterrupted traffic before migration but not after migration, the virtual machine migration is considered a failure (recorded as failed), and the batch migration is terminated. The virtual machines with uninterrupted traffic after migration are located, tenant traffic is restored as soon as possible, the root cause of the problem is identified, and the stability of the live network is ensured.

[0059] The script used to perform traffic ping tests on virtual machines is the vpping.sh script.

[0060] Methods for pinging tenant virtual machine traffic include:

[0061] Before and after tenant migration, the main script calls the vpping.sh script to compare the ping test results of virtual machine traffic before and after migration.

[0062] S5. After the migration is complete, delete the high-priority flow tables with cookies that are fully allowed on both the virtual machine and the host machine to prevent flow table residue.

[0063] This invention also provides a distributed batch tenant migration system that executes the distributed batch tenant migration method described above, including:

[0064] Add Inbound and Outbound Security Group Flow Table Module: Used to add high-priority, full, cookie-enabled inbound and outbound security group flow tables on all virtual machines and hosts owned by a tenant;

[0065] First ping test module: Used to perform the first ping test on all virtual machine traffic of the tenant on the tenant gateway to check whether the virtual machine traffic is connected; save the detection results of the first ping test to the local snap file;

[0066] Batch tenant migration module: This module calls the controller's tenant migration interface to write a batch of tenants into the tenant file. It then executes a migration script to iterate through the tenants in the tenant file one by one and performs the migration for each tenant in the file, thus achieving batch tenant migration.

[0067] The second ping test module is used to perform a second ping test on all virtual machine traffic of the tenant on the new tenant gateway after the tenant migration. The test results of the second ping test are saved to another snap file. The first and second snap files are compared to check whether the virtual machine traffic is connected after the migration. If the virtual machine traffic is connected after the tenant migration, the virtual machine migration is considered successful and the process proceeds to step S5.

[0068] The Flow Table Deletion module is used to delete high-priority flow tables with cookies that are fully allowed on both the virtual machine and the host machine after migration, preventing flow table remnants.

[0069] The second ping test module includes:

[0070] Migration Failure Recovery Traffic Unit: If a virtual machine has uninterrupted traffic before migration but not after migration, the migration is considered a failure, and the batch migration is terminated. The unit also locates the virtual machines with uninterrupted traffic after migration, restores tenant traffic as soon as possible, and identifies the root cause of the problem.

[0071] This invention also provides a distributed batch tenant migration device, which is equipped with the distributed batch tenant migration system described above.

[0072] This invention, through the execution of the `migrate_bulk_tenant.sh` script, distributes high-priority security group flow tables with cookies before tenant migration. It performs two virtual machine traffic ping tests before and after migration, and checks the results to quickly identify virtual machines with no traffic after migration. This allows for immediate detection and repair of problematic virtual machines, maintaining network stability. Furthermore, the newly added high-priority security group flow tables with cookies are deleted after tenant migration, improving the efficiency of batch tenant migration. This embodiment reduces the number of customer work orders to zero after tenant migration.

[0073] Figure 1 The overall process of this embodiment based on the distributed batch tenant migration method is shown.

[0074] The specific script and code implementation logic of this embodiment are as follows:

[0075]

[0076]

[0077]

[0078]

[0079]

[0080]

[0081]

[0082]

[0083]

[0084]

[0085]

[0086]

[0087]

[0088] This invention also provides a computer device. Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention; see the attached drawing. Figure 3 As shown, the computer device includes: an input system 23, an output system 24, a memory 22, and a processor 21; the memory 22 is used to store one or more programs; when the one or more programs are executed by the one or more processors 21, the one or more processors 21 implement the distributed batch tenant migration method provided in the above embodiments; wherein the input system 23, the output system 24, the memory 22, and the processor 21 can be connected via a bus or other means. Figure 3 Taking the example of a connection between China and Israel via a bus.

[0089] The memory 22, as a read / write storage medium for a computing device, can be used to store software programs and computer-executable programs, such as the program instructions corresponding to the distributed batch tenant migration method described in this embodiment of the invention. The memory 22 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on the use of the device. Furthermore, the memory 22 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 22 may further include memory remotely located relative to the processor 21, and these remote memories can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0090] The input system 23 can be used to receive input digital or character information, and generate key signal inputs related to user settings and function control of the device; the output system 24 may include display devices such as a display screen.

[0091] The processor 21 executes various functional applications and data processing of the device by running software programs, instructions and modules stored in the memory 22, thereby realizing the above-mentioned distributed batch tenant migration method.

[0092] The computer equipment provided above can be used to execute the distributed batch tenant migration method provided in the above embodiments, and has the corresponding functions and beneficial effects.

[0093] This invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the distributed batch tenant migration method provided in the above embodiments. The storage medium can be any type of memory device or storage device, including: mounting media such as CD-ROM, floppy disk, or magnetic tape systems; computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory such as flash memory, magnetic media (e.g., hard disk or optical storage); registers or other similar types of memory elements; the storage medium may also include other types of memory or combinations thereof; furthermore, the storage medium may reside in a first computer system in which the program is executed, or it may reside in a different second computer system connected to the first computer system via a network (such as the Internet); the second computer system can provide program instructions to the first computer for execution. The storage medium includes two or more storage media that may reside in different locations (e.g., in different computer systems connected via a network). The storage medium may store program instructions (e.g., specifically implemented as a computer program) executable by one or more processors.

[0094] Of course, the computer-executable instructions provided in the embodiments of the present invention are not limited to the distributed batch tenant migration method described in the above embodiments, but can also perform related operations in the distributed batch tenant migration method provided in any embodiment of the present invention.

[0095] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

[0096] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A distributed batch tenant migration method, characterized in that, Includes the following steps: S1. Add high-priority, full, cookie-enabled inbound and outbound security group flow tables to all virtual machines and host machines owned by the tenant; S2. Perform the first ping test on all virtual machine traffic of the tenant on the tenant gateway to check whether the virtual machine traffic is connected; save the test results of the first ping test to the local snap file; S3. Call the controller's tenant migration interface to write a batch of tenants into the tenant file. Execute the migration script to iterate through the tenants in the tenant file one by one and perform migration on each tenant in the tenant file to achieve batch tenant migration. S4. After the tenant migrates, perform a second ping test on all virtual machine traffic of the tenant on the new tenant gateway, and save the results of the second ping test to another snap file; Compare the first and second snap files to check whether the virtual machine traffic is connected after the migration; If the virtual machine traffic is connected after the tenant migration, the virtual machine migration is considered successful, and the process proceeds to step S5. S5. After the migration is complete, delete the high-priority flow tables with cookies that are fully allowed on both the virtual machine and the host machine to prevent flow table residue.

2. The distributed batch tenant migration method according to claim 1, characterized in that, The S4 step compares whether the virtual machine traffic is connected after migration. If there is a virtual machine whose traffic was connected before migration but not after migration, the virtual machine migration is considered to have failed and the batch migration is terminated. We also located the virtual machines that experienced traffic disruptions after migration, restored tenant traffic as soon as possible, and identified the root cause of the problem.

3. The distributed batch tenant migration method according to claim 1, characterized in that, The main script for implementing the bulk tenant migration in step S3 is the migrate_bulk_tenant.sh script.

4. The distributed batch tenant migration method according to claim 1, characterized in that, The script used to perform traffic ping tests on the virtual machine in steps S2 and S4 is the vpping.sh script.

5. The distributed batch tenant migration method according to claim 4, characterized in that, The methods for pinging the tenant's virtual machine traffic in steps S2 and S4 include: Before and after tenant migration, the main script calls the vpping.sh script to compare the ping test results of virtual machine traffic before and after migration.

6. A distributed batch tenant migration system, characterized in that, include: Add Inbound and Outbound Security Group Flow Table Module: Used to add high-priority, full, cookie-enabled inbound and outbound security group flow tables on all virtual machines and hosts owned by a tenant; First ping test module: Used to perform the first ping test on all virtual machine traffic of the tenant on the tenant gateway to check whether the virtual machine traffic is connected; save the detection results of the first ping test to the local snap file; Batch tenant migration module: This module calls the controller's tenant migration interface to write a batch of tenants into the tenant file. It then executes a migration script to iterate through the tenants in the tenant file one by one and performs the migration for each tenant in the file, thus achieving batch tenant migration. The second ping test module is used to perform a second ping test on all virtual machine traffic of the tenant on the new tenant gateway after the tenant migration, and save the detection results of the second ping test to another snap file; Compare the first and second snap files to check if the virtual machine traffic is connected after the migration; if the virtual machine traffic is connected after the tenant migration, the virtual machine migration is considered successful, and proceed to step S5. The Flow Table Deletion module is used to delete high-priority flow tables with cookies that are fully allowed on both the virtual machine and the host machine after migration, preventing flow table remnants.

7. The distributed batch tenant migration system according to claim 6, characterized in that, The second ping test module includes: Migration Failure Recovery Traffic Unit: If a virtual machine has uninterrupted traffic before migration but not after migration, the migration is considered a failure, and the batch migration is terminated. The unit also locates the virtual machines with uninterrupted traffic after migration, restores tenant traffic as soon as possible, and identifies the root cause of the problem.

8. A distributed batch tenant migration device, characterized in that, The system is equipped with a distributed batch tenant migration system as described in claim 6 or 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the distributed batch tenant migration method according to any one of claims 1-5.

10. A computer device, the computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the distributed batch tenant migration method as described in any one of claims 1-5.

Images