Address pool management method and device, electronic equipment and storage medium

Abstract

The invention provides an address pool management method and device, electronic equipment and a storage medium, and the method comprises the steps: receiving a creation request which comprises an IP address field length specified by a user; determining a first target continuous IP segment conforming to the IP address segment length from a system IP pool, and removing the first target continuous IP segment from the system IP pool; storing the first target continuous IP segment to an elastic IP address pool; and performing resource management on the elastic IP address pool according to a received management request. According to the method and the device, the distribution of the continuous IP address fields according to requirements is realized, the special requirements of scenes such as a high-availability cluster and a VPN gateway on continuous IP resources are met, and meanwhile, the problems of resource competition and fragmentation in a multi-tenant environment are effectively avoided by adopting a two-stage management architecture of a system pool-user pool.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an address pool management method, device, electronic device, and storage medium. Background Art

[0002] With the rapid development of cloud computing technology, Elastic IP (EIP), a key network resource on cloud platforms, plays a vital role in scenarios such as virtual machine communication, load balancing, and NAT gateways. In traditional network architectures, IP address allocation is typically static and pre-planned. However, cloud computing environments require dynamic allocation and flexible management of IP address resources to meet user needs for both application and release. Existing cloud platforms (such as AWS and Alibaba Cloud) generally use a discrete IP address allocation method: when a user applies for an EIP, the system randomly selects an available IP address from the public IP pool for allocation.

[0003] However, although this method is simple to implement, it has obvious defects: it cannot meet specific application scenarios that require continuous IP address segments, such as: high-availability cluster deployment requires continuous VIP (virtual IP) addresses; enterprise VPN access requires the allocation of continuous IP address ranges; specific security policies require the configuration of continuous IP address rules. Summary of the Invention

[0004] The present application provides an address pool management method, device, electronic device and storage medium to solve the problem that the discrete IP address allocation method used in the prior art cannot meet the specific application scenarios that require continuous IP address segments.

[0005] In a first aspect, the present application provides an address pool management method, comprising:

[0006] receiving a creation request, wherein the creation request includes a user-specified IP address segment length;

[0007] Determine a first target continuous IP segment that meets the IP address segment length from the system IP pool, and remove the first target continuous IP segment from the system IP pool;

[0008] Storing the first target continuous IP segment in an elastic IP address pool;

[0009] The elastic IP address pool is managed according to the received management request.

[0010] In one possible implementation, determining the first target continuous IP segment that meets the IP address segment length from the system IP pool includes:

[0011] Traverse the system IP pool and search for all candidate continuous IP segments whose length is not less than the length of the IP address segment;

[0012] From the found candidate continuous IP segments, select the continuous IP segment with the earliest starting address and the smallest length, and use the continuous IP segment as the first target continuous IP segment.

[0013] In one possible implementation, the management request includes an IP address allocation request, and performing resource management on the elastic IP address pool according to the received management request includes:

[0014] Searching the elastic IP address pool for a continuous IP address segment whose length is not less than the target length according to the target length specified in the IP address allocation request;

[0015] If there is at least one continuous IP address segment that meets the conditions, determining an address segment to be allocated in the at least one continuous IP address segment;

[0016] Allocate a second target continuous IP segment with the same target length from the address segment to be allocated, and update the length information of the address segment to be allocated in the elastic IP address pool;

[0017] If no continuous IP address segment that meets the conditions is found, an allocation failure message is returned.

[0018] In one possible implementation, determining the address segment to be allocated in at least one of the continuous IP address segments includes:

[0019] The continuous IP address segment with the smallest length is determined as the address segment to be allocated;

[0020] or,

[0021] The continuous IP address segment specified by the user is determined as the address segment to be allocated.

[0022] In one possible implementation, the method further includes:

[0023] A type field is set in the database for each elastic IP address pool to mark the address pool type. The address pool types include public pools and private pools. The resources of public pools can be shared by multiple users, while the resources of private pools belong to only one user.

[0024] When an IP address allocation request is received, locating a corresponding elastic IP address pool according to the target subnet specified in the IP address allocation request, and determining a target pool from the located elastic IP address pool based on the target type indicated by the IP address allocation request and the type field;

[0025] Search the target pool for a second target continuous IP segment that meets the target length.

[0026] In a possible implementation, the management request includes an IP address release request, and performing resource management on the elastic IP address pool according to the received management request includes:

[0027] The IP address segment to be released specified in the IP address release request is put back into the system IP pool, and the IP address segment to be released is marked as idle.

[0028] In one possible implementation, the method further includes:

[0029] Determine whether there is an idle IP address segment adjacent to the IP address segment to be released in the system IP pool;

[0030] If there are adjacent idle IP address segments, the IP address segment to be released and the adjacent idle IP address segment are merged into a continuous IP address segment;

[0031] If there is no adjacent idle IP address segment, the IP address segment to be released is retained in the system IP pool as an independent idle IP address segment.

[0032] In a second aspect, the present application provides an address pool management device, comprising:

[0033] A receiving module, configured to receive a creation request, wherein the creation request includes an IP address segment length specified by a user;

[0034] a determination module, configured to determine a first target continuous IP segment that meets the IP address segment length from a system IP pool, and remove the first target continuous IP segment from the system IP pool;

[0035] A storage module, configured to store the first target continuous IP segment in an elastic IP address pool;

[0036] The management module is used to perform resource management on the elastic IP address pool according to the received management request.

[0037] In one possible implementation, the determining module is specifically configured to:

[0038] Traverse the system IP pool and search for all candidate continuous IP segments whose length is not less than the length of the IP address segment;

[0039] From the found candidate continuous IP segments, select the continuous IP segment with the earliest starting address and the smallest length, and use the continuous IP segment as the first target continuous IP segment.

[0040] In a possible implementation, the management request includes an IP address allocation request, and the management module is specifically configured to:

[0041] Searching the elastic IP address pool for a continuous IP address segment whose length is not less than the target length according to the target length specified in the IP address allocation request;

[0042] If there is at least one continuous IP address segment that meets the conditions, determining an address segment to be allocated in the at least one continuous IP address segment;

[0043] Allocate a second target continuous IP segment with the same target length from the address segment to be allocated, and update the length information of the address segment to be allocated in the elastic IP address pool;

[0044] If no continuous IP address segment that meets the conditions is found, an allocation failure message is returned.

[0045] In one possible implementation, the management module is further configured to:

[0046] The continuous IP address segment with the smallest length is determined as the address segment to be allocated;

[0047] or,

[0048] The continuous IP address segment specified by the user is determined as the address segment to be allocated.

[0049] In one possible embodiment, the device further includes a marking module, configured to:

[0050] A type field is set in the database for each elastic IP address pool to mark the address pool type. The address pool types include public pools and private pools. The resources of public pools can be shared by multiple users, while the resources of private pools belong to only one user.

[0051] When an IP address allocation request is received, locating a corresponding elastic IP address pool according to the target subnet specified in the IP address allocation request, and determining a target pool from the located elastic IP address pool based on the target type indicated by the IP address allocation request and the type field;

[0052] Search the target pool for a second target continuous IP segment that meets the target length.

[0053] In a possible implementation, the management request includes an IP address release request, and the management module is further configured to:

[0054] The IP address segment to be released specified in the IP address release request is put back into the system IP pool, and the IP address segment to be released is marked as idle.

[0055] In one possible implementation, the management module is further configured to:

[0056] Determine whether there is an idle IP address segment adjacent to the IP address segment to be released in the system IP pool;

[0057] If there are adjacent idle IP address segments, the IP address segment to be released and the adjacent idle IP address segment are merged into a continuous IP address segment;

[0058] If there is no adjacent idle IP address segment, the IP address segment to be released is retained in the system IP pool as an independent idle IP address segment.

[0059] In a third aspect, the present application provides a device comprising: a processor and a memory, wherein the processor is configured to execute an address pool management program stored in the memory to implement the address pool management method described in any one of the first aspects.

[0060] In a fourth aspect, the present application provides a storage medium storing one or more programs, which can be executed by one or more processors to implement the address pool management method described in any one of the first aspects.

[0061] The above technical solution provided by the embodiment of the present application has the following advantages over the prior art: the method provided by the embodiment of the present application, first, receives a creation request, the creation request includes the length of the IP address segment specified by the user, then determines the first target continuous IP segment that meets the length of the IP address segment from the system IP pool, removes the first target continuous IP segment from the system IP pool, and stores the first target continuous IP segment in the elastic IP address pool, and finally, performs resource management on the elastic IP address pool according to the received management request. The present application realizes the on-demand allocation of continuous IP address segments, solves the special needs of high-availability clusters, VPN gateways and other scenarios for continuous IP resources, and at the same time, adopts the two-level management architecture of "system pool (i.e., system IP pool)-user pool (i.e., elastic IP address pool)", which effectively avoids resource competition and fragmentation problems in a multi-tenant environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0063] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0064] One or more embodiments are exemplarily illustrated by pictures in the corresponding drawings. These exemplifications do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements. Unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0065] Figure 1 A flowchart of an embodiment of an address pool management method provided in an embodiment of the present application;

[0066] Figure 2 A flowchart of an embodiment of the present application for performing resource management on the elastic IP address pool according to a received management request;

[0067] Figure 3 A flowchart of another embodiment of the present application for performing resource management on the elastic IP address pool according to a received management request;

[0068] Figure 4 A block diagram of an embodiment of an address pool management device provided in an embodiment of the present application;

[0069] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0070] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0071] The disclosure below provides many different embodiments or examples for implementing different structures of the present application. In order to simplify the disclosure of the present application, the components and settings of specific examples are described below. Of course, these are merely examples and are not intended to limit the present application. In addition, the present application may repeat reference numbers and / or letters in different examples. Such repetition is for the purpose of simplicity and clarity and does not in itself indicate the relationship between the various embodiments and / or settings discussed.

[0072] In order to solve the technical problem that the discrete IP address allocation method used in the existing technology cannot meet the specific application scenarios that require continuous IP address segments, the present application provides an address pool management method that can realize on-demand allocation of continuous IP address segments, solving the special needs of scenarios such as high-availability clusters and VPN gateways for continuous IP resources. At the same time, the "system pool-user pool" two-level management architecture is adopted to effectively avoid resource competition and fragmentation problems in a multi-tenant environment.

[0073] Figure 1 This is a flow chart of an embodiment of an address pool management method provided in the embodiment of the present application. Figure 1 As shown, the method includes the following steps:

[0074] Step 101: Receive a creation request, where the creation request includes a user-specified IP address segment length.

[0075] A creation request is a request initiated by a user to create his or her own Elastic IP Address (EIP) address pool.

[0076] The IP address segment length refers to the number of consecutive IP addresses required by the user. For example, 20 means 20 consecutive IP addresses are required.

[0077] In an embodiment of the present application, a user can submit an application for address pool creation through a dedicated interface provided by the cloud platform. In terms of technical implementation, this creation request is usually presented in the form of a RESTful API, including an address segment length parameter: explicitly specifying the number of required IP addresses (i.e., IP address segment length). This value determines the size of the address space that needs to be reserved by the subsequent system. In the application, it can also include an address pool type identifier: indicating whether the request is for public pool resources or private dedicated pool resources; business tag information: used to identify the business purpose of the address pool for subsequent management.

[0078] After receiving the request, the system will first perform parameter verification and permission verification to ensure the legitimacy of the request. After confirming the legitimacy, it will perform subsequent operations.

[0079] Step 102: Determine a first target continuous IP segment that meets the IP address segment length from the system IP pool, and remove the first target continuous IP segment from the system IP pool.

[0080] The system IP pool refers to the resource pool created by the administrator after applying to the operator in advance.

[0081] The first target continuous IP segment refers to an available IP address segment that meets the user's required length.

[0082] In an embodiment of the present application, an optimized address allocation algorithm may be used to determine a first target continuous IP segment that meets the IP address segment length from the system IP pool, which may specifically include the following steps:

[0083] Step A1: traverse the system IP pool to find all candidate continuous IP segments whose length is not less than the length of the IP address segment.

[0084] This step is the address segment search process. The specific process is as follows: the system maintains a real-time updated address space status table, recording the starting position and length of all available address segments. The search process can use a multi-level index structure to accelerate the query, first filtering out all candidate continuous IP segments that meet the length requirements.

[0085] Step A2: Select the continuous IP segment with the earliest starting address and the shortest length from the found candidate continuous IP segments, and use the continuous IP segment as the first target continuous IP segment.

[0086] This step involves selecting the optimal segment, employing a combined "minimum fit + address sorting" algorithm. Specifically, it prioritizes small segments at the front end of the address space, reserving larger segments at the back end to accommodate future large requests. Furthermore, the selection process considers the physical location of the address segments, prioritizing consecutive addresses within the same network segment. In applications, selected address segments can be locked to prevent inconsistent states caused by concurrent operations.

[0087] Through the above steps, the small segments at the front end of the address space can be prioritized, and the large segments at the back end can be reserved to meet possible large requests in the future.

[0088] Finally, the first target continuous IP segment is completely separated from the system's available pool to ensure that other users can no longer apply for these IP addresses.

[0089] This can be achieved in the application through a real-time update mechanism. Specifically, the address allocation status table of the system IP pool is immediately updated, and the routing table and access control rules are simultaneously refreshed to ensure that network devices can immediately recognize the change. This step ensures that the allocated IP segment is completely separated from the public resource pool, laying the foundation for the subsequent establishment of a dedicated address pool and preventing the duplication of IP addresses. The entire process is typically completed in milliseconds and is imperceptible to users.

[0090] Step 103: Store the first target continuous IP segment into an elastic IP address pool.

[0091] An elastic IP address pool is a user-specific IP resource pool that is isolated from the system pool.

[0092] In the embodiment of the present application, step 103 specifically includes the following steps:

[0093] 1.1. Create a new elastic IP address pool record in the database.

[0094] 1.2. Associate the selected first target continuous IP segment with the newly created address pool (i.e., elastic IP address pool).

[0095] 1.3. Set the address pool attributes including: user ID, IP segment start and end addresses, creation timestamp, and initial status mark as "active".

[0096] 1.4. Update the system resource allocation status table: mark the IP segment as "allocated" and record the allocation target pool ID.

[0097] Through the above steps, the first target continuous IP segment is stored in the elastic IP address pool.

[0098] Step 104: Perform resource management on the elastic IP address pool according to the received management request.

[0099] Management requests, including requests for IP address allocation, IP address release, and address pool maintenance.

[0100] Specifically, the following operations are included:

[0101] IP address allocation: Based on user requests, select the continuous IP segments that meet the requirements from the pool for allocation, update the database status to "occupied", and record the user information.

[0102] IP address release: Reclaim IP addresses released by users, mark them as "available", automatically check adjacent IP segments, and merge idle segments to reduce fragmentation.

[0103] Address pool maintenance: Regularly scan resource usage and optimize IP segment arrangement. Support dynamic pool size adjustment (expansion / reduction) through the API.

[0104] In practice, new fields, such as eip_pool_type, ip_segment_length, and eip_pool_id, are added to the database to accurately identify the resource ownership (i.e., user information) and management status (including occupied but unused, in use, and reserved) of the elastic IP address pool. These fields enable the system to quickly locate information such as the usage and segment length of each IP address, optimizing resource allocation and recovery.

[0105] In addition, in another embodiment of the present application, the method further includes the following steps:

[0106] An API interface is provided to support users in creating, modifying, and deleting elastic IP address pools, as well as allocating and releasing IP addresses. Specifically, when a create request is received, an elastic IP address pool is created through the API interface; when a modify request is received, the attribute information (such as name, type, size, etc.) of the elastic IP address pool is modified through the API interface; when a delete request is received, the specified elastic IP address pool is deleted through the API interface; when an allocation request is received, a continuous IP address segment is allocated from the specified elastic IP address pool through the API interface; when a release request is received, the IP address segment is released back to the elastic IP address pool through the API interface.

[0107] The technical solution provided by the embodiment of the present application first receives a creation request, wherein the creation request includes a user-specified IP address segment length, then determines a first target continuous IP segment that meets the IP address segment length from the system IP pool, removes the first target continuous IP segment from the system IP pool, and stores the first target continuous IP segment in an elastic IP address pool. Finally, resource management of the elastic IP address pool is performed based on the received management request. This application implements on-demand allocation of continuous IP address segments, solving the special needs of high-availability clusters, VPN gateways, and other scenarios for continuous IP resources. At the same time, the "system pool-user pool" two-level management architecture is adopted to effectively avoid resource competition and fragmentation problems in a multi-tenant environment.

[0108] Figure 2 A flowchart of an embodiment of the present application is provided for performing resource management on the elastic IP address pool according to a received management request. Figure 2 The process shown in Figure 1 Based on the process shown, the following steps are included:

[0109] Step 201: According to the target length specified in the IP address allocation request, search the elastic IP address pool for a continuous IP address segment whose length is not less than the target length.

[0110] Target length refers to the number of consecutive IP addresses requested by the user.

[0111] A continuous IP address segment refers to a range of unoccupied and continuous IP addresses in the address pool.

[0112] In this embodiment of the application, when the management request is an IP address allocation request, the system scans all available IP segments in the user's elastic IP address pool using the maintained ip_segment_length field to quickly locate available resources and select continuous address segments whose length meets the user's requirements (i.e., continuous IP address segments whose length is not less than the target length). During the search, segments at the front of the address space are prioritized to improve subsequent allocation efficiency.

[0113] Step 202: If there is at least one continuous IP address segment that meets the conditions, determine an address segment to be allocated in the at least one continuous IP address segment.

[0114] The address segment to be allocated refers to the optimal IP segment selected from the candidate segments that meet the conditions.

[0115] In one embodiment, determining the address segment to be allocated in at least one of the continuous IP address segments may specifically include the following steps: determining the continuous IP address segment with the smallest corresponding length as the address segment to be allocated.

[0116] In this solution, the system uses a best-fit algorithm to select the smallest continuous IP address segment from the candidate segments found. This selection strategy minimizes IP segment fragmentation while retaining larger free segments for subsequent use.

[0117] In addition, the selection process will take into account the location characteristics of the address segment, prioritize the allocation of front-end addresses, and reserve large back-end segments to meet possible large requests in the future, reducing the probability of subsequent fragmentation.

[0118] In another embodiment, determining the address segment to be allocated in at least one of the continuous IP address segments may specifically include the following steps: determining the continuous IP address segment specified by the user as the address segment to be allocated. In this way, the address segment to be allocated can be flexibly specified according to user needs.

[0119] Step 203: Allocate a second target continuous IP segment with the same length as the target from the address segment to be allocated, and update the length information of the address segment to be allocated in the elastic IP address pool.

[0120] The second target continuous IP segment refers to the IP address range actually allocated to the user.

[0121] Length information refers to the number of available IP addresses remaining in the address segment.

[0122] In an embodiment of the present application, the system cuts the IP address of the required length from the header of the selected segment to be allocated. After allocation, the allocated IP segment is immediately marked as "used", the ip_segment_length field of the original address segment is updated (such as from 50 to 30), and the routing rules and access control lists are synchronously updated. This process uses atomic operations to ensure data consistency.

[0123] Step 204: If no continuous IP address segment meeting the conditions is found, an allocation failure message is returned.

[0124] Allocation failure information refers to the system response including the reason for the failure.

[0125] In an embodiment of the present application, when there is no sufficiently large continuous segment in the address pool, the system will generate a detailed failure report, indicating the maximum available continuous segment length, suggesting that the user adjust the request parameters or release idle resources, trigger the defragmentation process, and record the failure log for capacity planning.

[0126] This solution enables precise on-demand allocation of continuous IP segments, supports scenarios such as high-availability clusters, automatically selects the optimal address segment using the best adaptation algorithm, improves allocation accuracy, and provides clear failure feedback and optimization suggestions to achieve closed-loop management of the entire process.

[0127] In addition, in another embodiment of the present application, the method may further include the following steps:

[0128] A type field for marking the address pool type is set in the database for each elastic IP address pool, where the address pool types include public pools and private pools, wherein the resources of the public pool can be shared by multiple users, and the resources of the private pool belong only to a single user. When an IP address allocation request is received, the corresponding elastic IP address pool is located according to the target subnet specified in the IP address allocation request, and based on the target type indicated by the IP address allocation request and the type field, the target pool is determined from the located elastic IP address pool, and a second target continuous IP segment that meets the target length is searched from the target pool.

[0129] Address pool type. In database design, each elastic IP address pool has an eip_pool_type field to distinguish between public and private pools. Public pools are shared by all users and are suitable for general business needs (such as testing environments and low-priority applications). Private pools are restricted to specific users and are suitable for businesses that require exclusive resource allocation (such as core databases and financial trading systems). In practice, private pools ensure complete data isolation through virtual network isolation (such as VXLAN) and independent routing rules. Public pools employ dynamic QoS policies to prevent a single user from consuming excessive resources.

[0130] Target subnet: refers to the logical network partition specified when the user requests IP address allocation. Each subnet is associated with an independent elastic IP address pool.

[0131] Target Type: The address pool type specified in the user request (public pool or private pool).

[0132] Target length: The length of the continuous IP address segment required in the user request (such as how many continuous IP addresses need to be allocated).

[0133] In an embodiment of the present application, a corresponding elastic IP address pool is configured for each subnet in the database, and the public pool and private pool are distinguished by the type field to clarify the resource sharing rules. When an IP address allocation request is received, first, the elastic IP address pool set under the subnet is located according to the target subnet in the request. Then, based on the target type (public or private) specified in the request and the type field of the address pool, the target pool that meets the conditions is filtered out from the located address pool. Finally, a continuous IP address segment of the target length that meets the user's requirements is searched in the target pool for allocation.

[0134] This solution uses the type field to achieve physical / logical isolation, resolving resource competition in the shared pool. Users can choose to quickly obtain IP addresses from the public pool or secure exclusivity from the private pool. Furthermore, database field extensions (such as eip_pool_id) enable smooth upgrades without impacting the original public pool functionality.

[0135] Figure 3 Another embodiment of the present application provides a flowchart of an embodiment for performing resource management on the elastic IP address pool based on a received management request. Figure 3 The process shown in Figure 1 Based on the process shown, the following steps are included:

[0136] Step 301: Put the IP address segment to be released specified in the IP address release request back into the system IP pool, and mark the IP address segment to be released as idle.

[0137] IP address segments to be released. The continuous IP address range that a user requests to release through an API (e.g., delete_eip) must meet the following conditions: the current status is "allocated" (recorded in the database eip_allocations table) and the ownership belongs to the requesting user (verified by the user_id field).

[0138] The idle state is marked with status=available in the database, indicating that the IP segment can be reallocated.

[0139] In this embodiment of the present application, when the management request is for IP address release, the system first verifies whether the requesting user has permission to release the specified IP address segment, ensuring that the segment is currently in the "allocated" state and belongs to the user. This step is accomplished by querying the user ID and IP status fields in the database. Once verification is successful, the system marks the IP segment's status as "free" and records information such as the release time and operator for subsequent audit and tracking.

[0140] Step 302: Determine whether there is an idle IP address segment adjacent to the IP address segment to be released in the system IP pool.

[0141] Adjacent free IP address segments refer to free IP segments that are directly connected (previous or subsequent) to the segment to be released in the address space. Continuity is determined by the start and end addresses of the ip_range field in the database (e.g., 192.168.1.20-30 and 192.168.1.31-40 are adjacent in subsequent order).

[0142] In this embodiment of the present application, the system calculates the preceding and following IP addresses of the IP segment to be released based on its starting and ending addresses, and then checks the database to see if these adjacent addresses are free. For example, if the IP segment to be released is 192.168.1.20-30, the system checks whether 192.168.1.19 (predecessor) and 192.168.1.31 (following) are free.

[0143] To avoid erroneous merging of IP addresses across subnets or tenants, the system further verifies that adjacent IP segments belong to the same subnet and confirms that these IP segments are not reserved or occupied by other tenants. Once these IP segments are confirmed to be unreserved or occupied by other tenants, they can be merged.

[0144] Step 303: If there are adjacent idle IP address segments, merge the to-be-released IP address segment and the adjacent idle IP address segment into one continuous IP address segment.

[0145] Consecutive IP address segments are merged to form a larger continuous segment. After merging, the ip_segment_length field is updated (for example, merging 20-30 and 31-40 to get 20-40 changes the length from 11+10 to 21).

[0146] In an embodiment of the present application, if adjacent idle IP segments are detected, the system will perform a merge operation based on their position (pre-sequence or post-sequence). For example: Pre-sequence merge: the segment to be released (192.168.1.20-30) and the pre-sequence segment (192.168.1.10-19) are merged into 192.168.1.10-30. Post-sequence merge: the segment to be released (192.168.1.20-30) and the post-sequence segment (192.168.1.31-40) are merged into 192.168.1.20-40. Bidirectional merge: If there are idle segments before and after, they are merged into a larger continuous segment (such as 192.168.1.10-40).

[0147] Step 304: If there is no adjacent idle IP address segment, the IP address segment to be released is retained in the system IP pool as an independent idle IP address segment.

[0148] In this embodiment of the present application, if the IP segment to be released has no adjacent free segments, the system will retain it as an independent free segment in the system IP pool and mark it as "fragmented." These fragmented segments will be added to a monitoring list, and when the fragmentation rate exceeds a preset threshold (such as 20%), an automatic defragmentation process will be triggered. Even if retained as independent segments, the system will still ensure that these IP segments can be reallocated. Their status and attributes (such as subnet and tenant affiliation) are fully preserved, so that they can quickly match demand during subsequent allocation.

[0149] Through the above solution, adjacent idle segments can be merged in real time, thereby reducing the address fragmentation rate and improving the success rate of allocating large IP segments.

[0150] Figure 4 This is a block diagram of an embodiment of an address pool management device provided in an embodiment of the present application.

[0151] like Figure 4 As shown, the device includes:

[0152] A receiving module 41 is configured to receive a creation request, wherein the creation request includes a user-specified IP address segment length;

[0153] A determination module 42 is configured to determine a first target continuous IP segment that meets the IP address segment length from the system IP pool, and remove the first target continuous IP segment from the system IP pool;

[0154] A storage module 43 is configured to store the first target continuous IP segment in an elastic IP address pool;

[0155] The management module 44 is configured to perform resource management on the elastic IP address pool according to the received management request.

[0156] In one possible implementation, the determining module is specifically configured to:

[0157] Traverse the system IP pool and search for all candidate continuous IP segments whose length is not less than the length of the IP address segment;

[0158] From the found candidate continuous IP segments, select the continuous IP segment with the earliest starting address and the smallest length, and use the continuous IP segment as the first target continuous IP segment.

[0159] In a possible implementation, the management request includes an IP address allocation request, and the management module is specifically configured to:

[0160] Searching the elastic IP address pool for a continuous IP address segment whose length is not less than the target length according to the target length specified in the IP address allocation request;

[0161] If there is at least one continuous IP address segment that meets the conditions, determining an address segment to be allocated in the at least one continuous IP address segment;

[0162] Allocate a second target continuous IP segment with the same target length from the address segment to be allocated, and update the length information of the address segment to be allocated in the elastic IP address pool;

[0163] If no continuous IP address segment that meets the conditions is found, an allocation failure message is returned.

[0164] In one possible implementation, the management module is further configured to:

[0165] The continuous IP address segment with the smallest length is determined as the address segment to be allocated;

[0166] or,

[0167] The continuous IP address segment specified by the user is determined as the address segment to be allocated.

[0168] In one possible embodiment, the device further includes a marking module, configured to:

[0169] A type field is set in the database for each elastic IP address pool to mark the address pool type. The address pool types include public pools and private pools. The resources of public pools can be shared by multiple users, while the resources of private pools belong to only one user.

[0170] When an IP address allocation request is received, locating a corresponding elastic IP address pool according to the target subnet specified in the IP address allocation request, and determining a target pool from the located elastic IP address pool based on the target type indicated by the IP address allocation request and the type field;

[0171] Search the target pool for a second target continuous IP segment that meets the target length.

[0172] In a possible implementation, the management request includes an IP address release request, and the management module is further configured to:

[0173] The IP address segment to be released specified in the IP address release request is put back into the system IP pool, and the IP address segment to be released is marked as idle.

[0174] In one possible implementation, the management module is further configured to:

[0175] Determine whether there is an idle IP address segment adjacent to the IP address segment to be released in the system IP pool;

[0176] If there are adjacent idle IP address segments, the IP address segment to be released and the adjacent idle IP address segment are merged into a continuous IP address segment;

[0177] If there is no adjacent idle IP address segment, the IP address segment to be released is retained in the system IP pool as an independent idle IP address segment.

[0178] like Figure 5 As shown, an embodiment of the present application provides a device, including a processor 111, a communication interface 112, a memory 113 and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114.

[0179] Memory 113, for storing computer programs;

[0180] In one embodiment of the present application, the processor 111 is configured to implement the address pool management method provided by any one of the aforementioned method embodiments when executing a program stored in the memory 113, including:

[0181] receiving a creation request, wherein the creation request includes a user-specified IP address segment length;

[0182] Determine a first target continuous IP segment that meets the IP address segment length from the system IP pool, and remove the first target continuous IP segment from the system IP pool;

[0183] Storing the first target continuous IP segment in an elastic IP address pool;

[0184] The elastic IP address pool is managed according to the received management request.

[0185] An embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the address pool management method provided in any of the aforementioned method embodiments are implemented.

[0186] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.

[0187] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general hardware platform, or of course, by hardware. Based on this understanding, the above technical solution, in essence, or the part that contributes to the relevant technology, can be embodied in the form of a software product. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or certain parts of the embodiment.

[0188] It should be understood that the terms used herein are for the purpose of describing specific example embodiments only and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used herein may also be meant to include plural forms. The terms "comprise", "include", "contain" and "have" are inclusive and therefore specify the presence of stated features, steps, operations, elements and / or parts, but do not exclude the presence or addition of one or more other features, steps, operations, elements, parts, and / or combinations thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring them to be performed in the specific order described or illustrated, unless the order of execution is clearly indicated. It should also be understood that additional or alternative steps may be used.

[0189] The foregoing is merely a list of specific embodiments of the present application, intended to enable those skilled in the art to understand or implement the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the broadest scope consistent with the principles and novel features of the present application.

Claims

1. A method for managing an address pool, characterized in that: The method comprises: receiving a creation request, wherein the creation request includes a user-specified IP address segment length; Determine a first target continuous IP segment that meets the IP address segment length from the system IP pool, and remove the first target continuous IP segment from the system IP pool; Storing the first target continuous IP segment in an elastic IP address pool; The elastic IP address pool is managed according to the received management request.

2. The method according to claim 1, characterized in that The determining of a first target continuous IP segment that meets the IP address segment length from the system IP pool includes: Traverse the system IP pool and search for all candidate continuous IP segments whose length is not less than the length of the IP address segment; From the found candidate continuous IP segments, select the continuous IP segment with the earliest starting address and the smallest length, and use the continuous IP segment as the first target continuous IP segment.

3. The method according to claim 1, characterized in that The management request includes an IP address allocation request, and performing resource management on the elastic IP address pool according to the received management request includes: Searching the elastic IP address pool for a continuous IP address segment whose length is not less than the target length according to the target length specified in the IP address allocation request; If there is at least one continuous IP address segment that meets the conditions, determining an address segment to be allocated in the at least one continuous IP address segment; Allocate a second target continuous IP segment with the same target length from the address segment to be allocated, and update the length information of the address segment to be allocated in the elastic IP address pool; If no continuous IP address segment that meets the conditions is found, an allocation failure message is returned.

4. The method according to claim 3, characterized in that Determining the address segment to be allocated in at least one of the continuous IP address segments includes: The continuous IP address segment with the smallest length is determined as the address segment to be allocated; or, The continuous IP address segment specified by the user is determined as the address segment to be allocated.

5. The method according to claim 3, characterized in that The method further comprises: A type field is set in the database for each elastic IP address pool to mark the address pool type. The address pool types include public pools and private pools. The resources of public pools can be shared by multiple users, while the resources of private pools belong to only one user. When an IP address allocation request is received, locating a corresponding elastic IP address pool according to the target subnet specified in the IP address allocation request, and determining a target pool from the located elastic IP address pool based on the target type indicated by the IP address allocation request and the type field; Search the target pool for a second target continuous IP segment that meets the target length.

6. The method according to claim 1, characterized in that The management request includes an IP address release request, and performing resource management on the elastic IP address pool according to the received management request includes: The IP address segment to be released specified in the IP address release request is put back into the system IP pool, and the IP address segment to be released is marked as idle.

7. The method according to claim 6, characterized in that The method further comprises: Determine whether there is an idle IP address segment adjacent to the IP address segment to be released in the system IP pool; If there are adjacent idle IP address segments, the IP address segment to be released and the adjacent idle IP address segment are merged into a continuous IP address segment; If there is no adjacent idle IP address segment, the IP address segment to be released is retained in the system IP pool as an independent idle IP address segment.

8. An address pool management device, characterized in that: The device comprises: A receiving module, configured to receive a creation request, wherein the creation request includes an IP address segment length specified by a user; a determination module, configured to determine a first target continuous IP segment that meets the IP address segment length from a system IP pool, and remove the first target continuous IP segment from the system IP pool; A storage module, configured to store the first target continuous IP segment in an elastic IP address pool; The management module is used to perform resource management on the elastic IP address pool according to the received management request.

9. A device, characterized in that include: A processor and a memory, wherein the processor is configured to execute an address pool management program stored in the memory to implement the address pool management method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the address pool management method according to any one of claims 1 to 7.

Images