Methods, apparatus, electronic devices and readable storage media for generating network reconnaissance tasks

Abstract

This invention provides a method, apparatus, electronic device, and readable storage medium for generating network probing tasks, belonging to cloud computing technology. The method includes: acquiring service instance data subscribed by a user to a cloud network; constructing user resource topologies for various traffic access scenarios in the cloud network based on the service instance data, wherein the user resource topologies characterize the user's access intent to the cloud network; and generating probing tasks for each traffic access scenario based on the user resource topologies and a preset probing task generation strategy for that traffic access scenario, wherein the probing tasks are used to perform network detection between user service access resources in the cloud network.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of cloud computing technology, and in particular to a method, apparatus, electronic device and readable storage medium for generating network probing tasks. Background Technology

[0002] Currently, public clouds serve millions of users simultaneously. The cloud network, jointly constructed by the underlying physical network and the upper-layer virtual network, builds a reliable and independent network environment for each user to run their applications. The physical network provides basic network connectivity, while the virtual network offers more advanced features, including network address space isolation, virtual routing, shared bandwidth, public network access, and tenant-level cross-region access. As the upper-layer network directly carrying tenant business traffic, network failures, latency, packet loss, and other anomalies in the virtual network will directly impact the user experience.

[0003] Currently, virtual network detection is usually achieved by deploying probes on cloud hosts or by actively detecting probes sent from the control plane to the measurement nodes based on a centralized controller. However, this approach cannot achieve comprehensive, end-to-end automatic monitoring of the user network. Summary of the Invention

[0004] This invention provides a method, apparatus, electronic device, and readable storage medium for generating network probing tasks, addressing the problem that existing probing tasks built for virtual networks cannot achieve comprehensive, end-to-end automatic monitoring of user networks. This invention can construct a user network assurance view based on the cloud network service instances subscribed to by the user, automatically generating virtual network probing tasks to achieve seamless, routine probing by the user, thereby providing end-to-end assurance of the user network.

[0005] In a first aspect, embodiments of the present invention provide a method for generating network reconnaissance tasks, the method comprising:

[0006] Obtain data on the service instances that the user has subscribed to for the cloud network;

[0007] Based on the business instance data, a user resource topology is constructed for each traffic access scenario in the cloud network. The user resource topology can represent the user's access intent to the cloud network.

[0008] Based on the user resource topology under each traffic access scenario and the preset detection task generation strategy for the traffic access scenario, a detection task is generated for each traffic access scenario. The detection task is used to perform network detection between user service access resources in the cloud network.

[0009] In a second aspect, embodiments of the present invention provide a network reconnaissance task generation apparatus, the apparatus comprising:

[0010] The acquisition module is used to acquire data on service instances that users have subscribed to for the cloud network.

[0011] The construction module is used to construct the user resource topology for each traffic access scenario in the cloud network based on the business instance data. The user resource topology can represent the user's access intention to the cloud network.

[0012] The generation module is used to generate a detection task for each traffic access scenario based on the user resource topology and the preset detection task generation strategy for each traffic access scenario. The detection task is used to perform network detection between user service access resources in the cloud network.

[0013] Thirdly, embodiments of the present invention provide an electronic device, including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the above-described network probing task generation method.

[0014] Fourthly, embodiments of the present invention provide a readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described network probing task generation method.

[0015] Fifthly, embodiments of the present invention provide a computer program product, including computer instructions, which, when executed by a processor, implement the steps of the above-described network probing task generation method.

[0016] In this embodiment of the invention, service instance data subscribed by a user to a cloud network is obtained. Based on the service instance data, a user resource topology is constructed for each traffic access scenario in the cloud network, where the user resource topology represents the user's access intent to the cloud network. Based on the user resource topology for each traffic access scenario and a preset detection task generation strategy for that traffic access scenario, detection tasks are generated for each traffic access scenario. These detection tasks are used to perform network detection between user service access resources in the cloud network. In this way, a user network assurance view can be constructed based on the cloud network service instances subscribed by the user, automatically generating virtual network detection tasks and achieving seamless, routine detection for the user, thus achieving end-to-end assurance of the user network. Furthermore, detection of all traffic access scenarios for user network access needs in the cloud network can be covered, enabling comprehensive, automatic end-to-end monitoring of the user network. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating the network probing task generation method provided in an embodiment of the present invention;

[0019] Figure 2 This is a diagram illustrating the process of obtaining business instance data;

[0020] Figure 3 This is a schematic diagram of the resource model relationship in an east-west access scenario between hosts;

[0021] Figure 4 This is a schematic diagram of the resource model relationships in a public network access scenario;

[0022] Figure 5 This is a schematic diagram of the resource model relationships in a dedicated line access scenario;

[0023] Figure 6 This is a schematic diagram illustrating the overall framework process for generating a virtual network probing task, as shown in the example.

[0024] Figure 7 This is a flowchart illustrating an example of a data update probe task for incremental business instances.

[0025] Figure 8 This is a schematic diagram of the network detection task generation device provided in an embodiment of the present invention;

[0026] Figure 9 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] The network detection task generation method provided in the embodiments of the present invention will be described first.

[0029] See Figure 1 The figure shows a flowchart illustrating the network probing task generation method provided in an embodiment of the present invention. Figure 1As shown, the method may include the following steps:

[0030] Step 101: Obtain the service instance data that the user has subscribed to for the cloud network.

[0031] In public cloud scenarios, the data of business instances subscribed by users often represents the user's network access needs, which can be achieved by collecting user resource change messages in real time. Figure 2 This is a diagram illustrating the process of obtaining business instance data, such as... Figure 2 As shown, this includes changes to user-subscribed service products such as Virtual Private Cloud (VPC), Elastic Load Balancer, Elastic Internet Protocol (IP) Address, and Cloud Servers; changes to underlying resources associated with user-subscribed products such as routers, subnets, and network interface cards; and physical topology updates such as the mapping relationship between cloud servers and compute nodes.

[0032] In other words, when a user subscribes to a cloud network service, the service can generate resource change messages. These real-time resource change messages can include the resource data itself and the update type, such as add, update, or delete. Figure 2 As shown, resource change messages can be actively pushed to the message queue Kafka. The central control service consumes the business instance data (i.e., topicA) in the resource change message and calls the application programming interface (API) based on the update type in the resource change message to update and write the business instance data in the resource change message to the graph database.

[0033] Step 102: Based on the business instance data, construct the user resource topology for each traffic access scenario in the cloud network. The user resource topology can represent the user's access intent to the cloud network.

[0034] The generation of probe missions depends on the automatic acquisition of probe sources and destinations. By constructing user resource topology, the user's access intention to the cloud network can be characterized. This allows the establishment of the association between the relevant resources in the user's access intention to the cloud network and the probe source and destination.

[0035] In a cloud network, traffic access scenarios can refer to user access to the cloud network for business purposes. Different traffic access scenarios in user business network access often correspond to a specific type of network access need of the user and can be independently mapped to a portion of the user's resources. By constructing the user resource topology under each traffic access scenario in the cloud network, it is possible to construct the user's access intent to the cloud network and to define all the resources that the user needs to map to in each business network access.

[0036] It can distinguish data under different traffic access scenarios in business instance data, obtain the resources that users need to access under each traffic access scenario based on the business instance data under each traffic access scenario, and build the relationship between resources to obtain the user resource topology under that traffic access scenario.

[0037] However, the business instance data may only include a portion of the resources used during user business access. To improve the resource coverage of the user resource topology and ensure that the user resource topology can fully represent the user's access intent to the cloud network, step 102 may optionally include:

[0038] Based on the business instance data and the pre-built resource model for each traffic access scenario in the cloud network, a user resource topology is constructed for each traffic access scenario.

[0039] The resource model is used to characterize the inter-resource relationships of the cloud network under the traffic access scenario.

[0040] In other words, the user resource topology distinguishes traffic access scenarios. By defining a resource model for each traffic access scenario, it obtains all the resources that users need to map to in various business network accesses, and constructs the user resource topology for each traffic access scenario based on these resources, thereby improving the accuracy of user resource topology construction and resource coverage.

[0041] Optionally, the traffic access scenario includes at least one of the following:

[0042] East-west access scenarios between cloud servers;

[0043] Public network access scenarios;

[0044] Dedicated line access scenario.

[0045] East-west access scenarios between cloud servers primarily include network connectivity between cloud servers within a VPC and cross-VPC network connectivity requirements. A user-subscribed VPC instance is associated with a Router instance. A Router instance contains multiple networks, and each network, distinguishing between Internet Protocol version 4 (IPv4) and IPv6, corresponds to a maximum of two subnets. A port uniquely belongs to one network and is bound to one of the user's cloud servers, while a cloud server uniquely belongs to one physical compute node. Accordingly, based on the VPC, peering connections, Router, Network, Subnet, and cloud server resources associated with east-west access scenarios between cloud servers, the following can be defined: Figure 3 The resource model shown.

[0046] Optionally, the traffic access scenarios include east-west access scenarios between cloud hosts, and the resource model for the east-west access scenarios between cloud hosts includes the resource relationships between virtual private clouds (VPCs) and the cloud host relationships across VPCs; the step of constructing the user resource topology for each traffic access scenario based on the business instance data and the pre-built resource model for each traffic access scenario in the cloud network includes at least one of the following:

[0047] Based on the resource relationships within the VPC and the business instance data, the user resource topology of the VPC instance in the east-west access scenario between cloud hosts is obtained. The user resource topology of the VPC instance includes at least one of the following: relationships between cloud hosts in the same subnet, relationships between cloud hosts across subnets, and mapping relationships between cloud hosts and physical computing nodes.

[0048] Based on the association between cloud hosts across VPCs and the business instance data, the user resource topology of VPC peering connection instances in the east-west access scenario between cloud hosts is obtained. The user resource topology of VPC peering connection instances includes the relationship between cloud hosts across VPCs and subnets.

[0049] By establishing relationships between resources within a VPC and business instance data for VPC instances, it is possible to quickly obtain the relationships between cloud hosts within the same subnet and across subnets under a user's VPC instance, as well as the mapping relationship between the corresponding cloud hosts and physical computing nodes.

[0050] Network connectivity between cloud hosts across VPCs is bridged through peering instances. Based on the association between cloud hosts across VPCs, as well as the peering instances associated with VPC instances and VPC peering instances, the relationships between cloud hosts across VPCs and subnets can be quickly obtained.

[0051] Public network access scenarios primarily include user needs for accessing the public network from within the cloud and the needs of providing public network services. Depending on the resources bound to the public IP instance ordered by the user, user access to the public network can be further divided into: accessing the public network by binding a cloud host and accessing the public network based on Source Network Address Translation (SNAT) rules. Providing public network services can be further divided into: providing public network services based on Destination Network Address Translation (DNAT) policies, binding an Elastic Load Balancer instance, or binding a Virtual Private Network (VPN) instance. Correspondingly, based on the resources associated with the public network access scenario, such as Elastic Public IP, shared bandwidth, SNAT gateway, DNAT gateway, Elastic Load Balancer, and VPN, the resource model for the public network access scenario is defined as follows: Figure 4 As shown.

[0052] Optionally, the traffic access scenarios include public network access scenarios, and the resource model of the public network access scenarios includes the relationship between public Internet Protocol (IP) addresses and associated resources; the step of constructing the user resource topology for each traffic access scenario based on the business instance data and the pre-built resource model for each traffic access scenario in the cloud network includes:

[0053] Based on the relationship between public Internet Protocol (IP) addresses and associated resources and the business instance data, obtain the user resource topology of public IP instances in the public network access scenario; the user resource topology of public IP instances includes at least one of the following: public network access inbound / outbound relationship, range of cloud hosts that can access the public network, and service addresses that provide public network services.

[0054] By establishing the association between public IP addresses and bound resources, and based on this association and the data of public IP instances in the business instance data, it is possible to distinguish between inbound and outbound public network access relationships. For example, it can be determined whether a public IP address is used to access the public network or to provide public network services. Accessing the public network is an outbound relationship, meaning the cloud initiates public network access from outside the cloud; providing public network services is an inbound relationship, meaning outside the cloud accesses the cloud through the public network. Furthermore, it allows determination of the range of cloud hosts that can access the public network and the service addresses that provide public network services for a specific public IP instance.

[0055] The dedicated line access scenario provides dedicated line access to the cloud and dedicated line interconnection between clouds. For dedicated line access to the cloud, a dedicated line subscribed by a customer connects the customer's local Internet Data Center (IDC) server room network segment to the interconnection network under the cloud VPC / subnet. For dedicated line interconnection between clouds, a dedicated line subscribed by a user connects the source hosts under different resource pool VPCs / subnets in the cloud. Accordingly, the resource model for the dedicated line access scenario, defined by resources such as dedicated cloud lines, cloud interconnection, VPCs, subnets, and virtual machines (VMs), is as follows: Figure 5 As shown.

[0056] Optionally, the traffic access scenarios include dedicated line access scenarios, and the resource model of the dedicated line access scenarios includes resource relationships under dedicated line access to the cloud and resource relationships under cloud-to-cloud dedicated line interconnection; the step of constructing the user resource topology under each traffic access scenario in the cloud network based on the business instance data includes at least one of the following:

[0057] Based on the resource relationships under dedicated line access to the cloud and the business instance data, the user resource topology of the dedicated line instance in the dedicated line access scenario is obtained. The user resource topology of the dedicated line instance includes the address relationship between the cloud host in the cloud network associated with the dedicated line instance and the private network segment of the Internet Data Center (IDC).

[0058] Based on the resource relationships under the cloud-to-cloud dedicated line interconnection and the business instance data, the user resource topology of the cloud interconnection instance under the dedicated line access scenario is obtained. The user resource topology of the cloud interconnection instance includes the correspondence between cloud hosts across resource pools associated with the cloud interconnection instance.

[0059] For dedicated line access scenarios, the relationship between the cloud host associated with the dedicated line access to the cloud and the customer's local IDC private network segment address can be obtained based on the resource association relationship under dedicated line access to the cloud and the data of the dedicated line instance in the business instance data. Furthermore, the relationship between the cross-resource pool cloud hosts associated with the cloud interconnection instance can be obtained based on the resource association relationship under cloud inter-dedicated line interconnection and the data of the cloud interconnection instance in the business instance data.

[0060] It should be noted that both business instance data and resource models can be stored in a graph database. Leveraging the relational query capabilities of graph databases, user resource topologies for traffic access scenarios can be automatically constructed based on the relationships between resources. These user resource topologies can also be stored in a graph database. This allows for the rapid and automated construction of user resource topologies.

[0061] This step proposes an automatic construction and update method for user resource topology. By collecting user resource change messages in real time and defining the resource model based on the traffic-sharing access scenario, the automatic construction and update of user resource topology can be achieved by leveraging the association query analysis advantages of graph databases.

[0062] Step 103: Generate a detection task for each traffic access scenario based on the user resource topology and the preset detection task generation strategy for each traffic access scenario. The detection task is used to perform network detection between user service access resources in the cloud network.

[0063] The probing task can be automatically generated based on the user resource topology and according to the probing task generation strategy for the traffic access scenario. That is, after constructing the user resource topology, the probing task can be automatically generated based on the probing task generation strategy defined for the traffic access scenario, leveraging the resource association query advantages of the graph database to quickly obtain the probe source and destination relationship data in the user resource topology under the traffic access scenario. Optionally, step 103 specifically includes:

[0064] The probe source and destination indicated by the probe task generation strategy are obtained from the user resource topology using a graph database, and a probe task is generated under the traffic access scenario.

[0065] In this way, the probe source and destination can be quickly obtained based on the user resource topology, thereby quickly generating the probe mission.

[0066] The strategy for generating probe tasks for user-facing virtual networks should consider two aspects: First, it should ensure full coverage of traffic access scenarios (especially typical traffic access scenarios). This embodiment of the invention considers east-west access scenarios between cloud hosts, public network access scenarios, and dedicated line access scenarios. Second, it should balance the trade-off between the coverage of probe service paths and the volume of probe tasks. When defining the probe task generation strategy, it is possible to define the probe task generation strategy separately for different traffic access scenarios, taking into account both the volume of probe tasks and the coverage of physical paths.

[0067] Optionally, the detection task generation strategy for the east-west access scenario between cloud hosts includes at least one of the following:

[0068] For cloud hosts located in the same VPC and under the same physical computing node, the cloud hosts are divided into two groups, which are used as probe sources and destinations respectively to generate probe tasks in pairs;

[0069] For cloud hosts located in the same VPC and subnet, select T cloud hosts as candidate cloud hosts from those belonging to the same physical computing node. Divide the candidate cloud hosts into two groups, which are used as probe sources and destinations respectively to generate probe tasks in pairs, where T is a positive integer.

[0070] For cloud hosts located in the same VPC but across subnets, cloud hosts in the same subnet are grouped according to their physical computing nodes. Within each group, T cloud hosts are selected as candidate cloud hosts. Different candidate cloud hosts across subnets are paired as probe sources and destinations to generate probe tasks.

[0071] For cloud hosts across VPCs, cloud hosts under the same VPC are grouped according to the physical computing node to which the cloud host belongs. Within each group, T cloud hosts are selected as candidate cloud hosts. Different candidate cloud hosts across VPCs are paired as probe sources and destinations to generate probe tasks.

[0072] The strategy for generating detection tasks for east-west access scenarios between cloud hosts is as follows:

[0073] a. Cloud hosts under the same VPC and physical compute node are divided into two groups for paired one-way ping to detect network connectivity at both ends. That is, multiple cloud hosts (usually more than 2) belonging to the same physical compute node under the same VPC are sorted in ascending order of IP address, then grouped based on the median. Probe tasks are generated between the cloud hosts in the two groups in a one-to-one pair. For example, if there are 10 cloud hosts, the first 5 and the last 5 are divided into two groups, and one cloud host from each group is used to generate a one-to-one probe task.

[0074] b. For cloud hosts in the same VPC and subnet (same network, same broadcast domain), firstly, randomly select T cloud hosts as candidate cloud hosts from the cloud hosts belonging to the same physical computing node; divide the candidate cloud hosts into two groups, and generate probe tasks between the cloud hosts in the two groups in a one-to-one pair; where T is greater than or equal to 1 and less than or equal to N, and N is the total number of cloud hosts belonging to the same physical computing node.

[0075] c. For cloud hosts in the same VPC but across subnets (same network, across broadcast domains), first, cloud hosts in the same subnet are grouped according to their physical computing nodes. Each group randomly selects T cloud hosts as candidate cloud hosts. Probe tasks are generated one-to-one between different candidate cloud hosts in different subnets.

[0076] d. For cross-VPC cloud hosts, firstly, cloud hosts under the same VPC are grouped according to the physical computing node to which the cloud host belongs, and T cloud hosts are randomly selected as candidate cloud hosts in each group; probe tasks are generated between different candidate cloud hosts across VPCs in a one-to-one pair.

[0077] Optionally, the strategy for generating detection tasks in the public network access scenario includes at least one of the following:

[0078] For cases where public network outbound access is used and the public IP is bound to a cloud host, the bound cloud host address is used as the probe source and the external public IP is used as the destination to generate a probe task.

[0079] For public network outbound access and public IP bound to source network address translation (SNAT), all cloud hosts covered by SNAT are grouped according to their physical computing nodes. T cloud hosts are selected as candidate cloud hosts in each group. A probe task is constructed with the candidate cloud hosts as the probe source and the public IP outside the cloud as the destination, where T is a positive integer.

[0080] For public network inbound access, a probe task is generated using a cloud host bound to a public IP address in the target resource pool as the probe source and an address providing public network services as the destination. The target resource pool is different from the resource pool involved in the public IP instance ordered by the user.

[0081] The strategy for generating probe tasks in public network access scenarios needs to consider two aspects: first, it must cover every public IP instance; second, it needs to differentiate between access directions within and outside the cloud. For access from within the cloud to the public network, such as a cloud host bound to a public IP instance accessing public network resources, a probe can be initiated from within the cloud to the public address outside the cloud. However, for cases where access from outside the cloud to the cloud via the public network, such as elastic coverage balancing overlaying public IPs to provide services to the public network, probe tasks that are closer to user business access traffic should initiate public network probes from outside the cloud. Based on these two considerations, the strategy for generating probe tasks in public network access scenarios is as follows:

[0082] a. Iterate through each Elastic Public IP instance subscribed by the user, distinguish the public network access directions, and generate probe tasks according to different strategies for binding different resources.

[0083] b. For outbound access scenarios, directly bind cloud hosts to generate a probe task with the bound cloud host VM address as the probe source and the external public IP address as the destination; for SNAT-bound scenarios, group all SNAT-covered cloud hosts according to their respective physical computing nodes, select T cloud hosts in each group as candidate cloud hosts, and construct a probe task with the candidate cloud hosts as the probe source and the external public IP address as the destination.

[0084] c. For inbound access, to maintain consistency in virtual network packet detection, a cloud host can be ordered from another resource pool and bound to a public IP address as a target machine. This cloud host can then be used as the probe source to initiate probes to the destination service. This other resource pool can be any resource pool different from the one involved in the user's ordered public IP instance, such as the closest resource pool.

[0085] Specifically, for scenarios with overlaid elastic load balancing, the destination address can be a public IP instance address plus a port; for scenarios with overlaid DNAT, the destination address can be a public IP instance plus various mapped ports. For both of these scenarios, Transmission Control Protocol (TCP) Ping can be used to generate probe tasks. For scenarios with overlaid VPN, the destination address can be a public IP instance address, and Internet Control Message Protocol (ICMP) Ping can be used to generate probe tasks. In VPN scenarios, the destination is captured and responded to by the corresponding VPN instance.

[0086] Optionally, the detection task generation strategy for the dedicated line access scenario includes at least one of the following:

[0087] For the case of accessing the cloud dedicated line, the cloud hosts covered by the cloud dedicated line instance are grouped according to the physical computing node to which they belong. In each group, T cloud hosts are selected as candidate cloud hosts. The candidate cloud hosts are used as the probe source, and the remote local address of the cloud dedicated line access is used as the destination to generate a probe task.

[0088] For the case of cloud-to-cloud private line interconnection, the cloud hosts covered at both ends of the cloud-to-cloud private line interconnection are grouped according to their respective physical computing nodes. In each group, T cloud hosts are selected as candidate cloud hosts. The candidate cloud hosts at both ends of the interconnection are paired as the probe source and the probe destination to generate probe tasks.

[0089] The strategy for generating detection tasks in dedicated line access scenarios is as follows:

[0090] a. For cloud dedicated line access scenarios, iterate through each dedicated line instance subscribed by the user, and for all cloud hosts under the VPC / subnet associated with the instance, group the covered cloud hosts according to their affiliated physical computing nodes. Select T cloud hosts as candidate cloud hosts in each group, and generate a probe task from the candidate cloud hosts to the customer's remote local address.

[0091] b. For cloud interconnection scenarios, traverse each cloud interconnection dedicated line instance, and group all cloud hosts under the VPC / coverage subnet at both ends of the interconnection according to their respective physical computing nodes. Select T cloud hosts as candidate cloud hosts in each group, and generate probe tasks between the candidate cloud hosts at both ends of the interconnection in a one-to-one pair.

[0092] Therefore, a detection task generation strategy for traffic-segmented access scenarios is proposed. This strategy weighs several factors such as user network access traffic scenario coverage, business path coverage, and detection task volume, and can achieve tenant-level full-scenario virtual network quality detection.

[0093] In the above-mentioned traffic-sharing access scenario, the detection task generation strategy adopts a candidate cloud host selection method for multiple cloud hosts belonging to the same physical computing node. This mechanism ensures coverage of all physical business paths (starting from the physical computing node) and allows the T-value parameter to be adjusted as needed, affecting the coverage of user cloud hosts. When the T-value is close to the N-value, the more cloud hosts are covered, but the larger the detection task volume and the higher the computational cost required.

[0094] Optionally, the method further includes:

[0095] The number of candidate cloud hosts in the detection task generation strategy is determined based on the user level.

[0096] In this way, the T-value setting can be influenced according to the user level, which can take into account both the coverage of physical business paths and the amount of detection tasks.

[0097] In this embodiment, service instance data subscribed by the user to the cloud network is acquired. Based on the service instance data, a user resource topology is constructed for each traffic access scenario in the cloud network. This user resource topology represents the user's access intent to the cloud network. Based on the user resource topology for each traffic access scenario and a preset detection task generation strategy for that scenario, detection tasks are generated. These detection tasks are used to perform network detection between user service access resources in the cloud network. In this way, a user network assurance view can be constructed based on the cloud network service instances subscribed by the user, automatically generating virtual network detection tasks and achieving seamless, routine detection for the user, thus enabling end-to-end assurance of the user network. Furthermore, it can cover the detection of all traffic access scenarios for user network access needs in the cloud network, thereby achieving comprehensive, automatic end-to-end monitoring of the user network.

[0098] In public cloud scenarios, resource changes are frequent, and regenerating a full probe task when user resources change is extremely costly. Furthermore, user actions such as adding / deleting virtual private clouds or changing access controls often affect the probe task, while changes to resource configurations, such as adjusting bandwidth, although altering user resource attributes, do not require regenerating the probe task. Considering these factors, a task generation trigger can be introduced to consume resource change messages a second time and determine the update scope of the probe task. Then, the probe task is updated according to the update scope.

[0099] Optionally, after step 103, the method further includes:

[0100] Based on the business instance data obtained within the time window, determine the update scope of the probe task;

[0101] Update the detection missions within the update range.

[0102] In this embodiment, the business instance data obtained within the time window is incremental data generated after the detection task is generated based on the business instance data. The window size of the time window can be preset, such as one day or one month, and is not specifically limited here.

[0103] Thus, by determining the update scope of the detection mission based on incremental data and updating only the detection missions within the update scope, the scope and cost of generating detection mission updates can be greatly reduced.

[0104] The overall framework for generating virtual network reconnaissance tasks is as follows: Figure 6 As shown, by collecting user resource change messages in real time, the system constructs user resource topologies for each traffic access scenario based on the resource model defined for traffic-based access scenarios. The task generation trigger synchronously consumes user resource change messages and determines the generation / update scope of the probe task based on incremental resource change messages within a time window. The probe task generation / update module can automatically generate / update probe tasks based on the determined scope, user resource topology, and probe task generation strategy.

[0105] Optionally, determining the update scope of the probe task based on the business instance data obtained within the time window includes:

[0106] Business instance data acquired within the time window is grouped and processed according to resource identifiers;

[0107] For the business instance data within the group, the graph database is queried based on the resource identifier to determine the update scope of the probe task. The update scope includes the target resource instances affected by the business instance data within the group. The graph database stores the business instance data acquired before the time window.

[0108] Therefore, to address the high cost of frequently regenerating all probe tasks, an impact-oriented probe task update mechanism is proposed. By adding a task generation trigger and leveraging the advantages of graph database association queries to obtain the impact scenarios and instances of tenant resource changes within a time window, only probe tasks related to the affected scenarios and instances are updated, significantly reducing the scope and cost of probe task update generation.

[0109] Optionally, the service instance data within the group is further grouped according to user identifiers. The step of querying the graph database based on resource identifiers to determine the update scope of the probe task for the service instance data within the group includes:

[0110] For business instance data within a group, the graph database is queried in parallel based on user identifiers and resource identifiers to determine the update scope of the probe task.

[0111] Resource change messages within a time window can be grouped by user ID. After grouping, the update range of the probe task can be calculated in parallel based on the resource change messages of users in different groups, and the update processing of the probe task can be triggered. The probe tasks between users are independent of each other, which can improve the update efficiency of the probe task.

[0112] In some embodiments, the specific process of automatically updating the probe task based on incremental data is as follows: Figure 7 As shown below:

[0113] Data preprocessing: The task generation trigger consumes resource change messages from Kafka in real time, filtering out resource change messages that are irrelevant to the probe task updates, such as updates to cloud host type, specifications, and public network access bandwidth. This reduces the amount of resource update messages that need to be processed.

[0114] Resource change messages are aggregated based on time windows. Within a time window, resource change messages are grouped by resource ID, and data with the same resource ID are sorted in chronological order by timestamp. Multiple resource change messages that were added and then deleted for the same resource within a time window are removed. This improves the accuracy of resource change message processing.

[0115] The remaining resource update messages after filtering within the time window are grouped by user ID. After grouping, the update range of the probe task can be calculated in parallel based on the resource change messages of users in different groups, and the update processing of the probe task can be triggered.

[0116] For resource change messages within a group, the graph database is queried based on the resource ID in the resource change message to determine the highest-level resource instance affected in the corresponding scenario, i.e., the target resource instance. For example, in the east-west access scenario between cloud hosts, the highest-level resource instance is the VPC instance in the user resource topology; in the public network access scenario, the highest-level resource instance is the Fibre Channel over Ethernet (FCoE) Initialization Protocol (FIP) instance in the user resource topology; and in the leased line access scenario, the highest-level resource instance is the leased line instance in the user resource topology.

[0117] After identifying the highest-level resource instance affected by each traffic access scenario, only the probing tasks related to that instance need to be regenerated. For VPC instance changes, if the VPC instance has associated peering instances, the probing tasks for these instances also need to be regenerated.

[0118] This embodiment proposes an automatic generation and updating method for virtual network probing tasks based on user network access intent. By collecting user service instances to perceive user network access intent, a user resource topology for traffic-segmented access scenarios is constructed. The advantages of graph database association query analysis are utilized to achieve rapid construction of tenant-oriented probing tasks and query of impact surface resources. Based on a traffic-segmented access scenario probing task generation strategy, the automatic generation and updating of tenant-level virtual network probing tasks is achieved. This addresses the problems of tenant-level focus, network traffic scenario coverage, and insufficient automation in related methods, and innovatively proposes a method for generating virtual network probing tasks based on user network access intent perception.

[0119] The network probing task generation method provided by the embodiments of the present invention will be described in detail below with reference to practical application scenarios.

[0120] The embodiments of this invention can be applied to the generation of routine virtual network detection tasks, can build virtual network assurance capabilities for cloud service providers, can build a tenant-level end-to-end network quality assurance view, provide service level agreement (SLA) guarantees, improve customer satisfaction, and further evolve products to achieve revenue generation and monetization.

[0121] This invention relates to network plane monitoring within a computing network operation and maintenance (COP) platform, applicable to the field of computing power network awareness and assurance. In the network measurement module of the COP platform, user network access intent is perceived by collecting user business instances, and a user resource topology for traffic-sharing access scenarios is constructed. The advantages of graph database association query analysis are utilized to achieve rapid construction of tenant-oriented probing tasks and query of impact surface resources. Based on a traffic-sharing access scenario-based probing task generation strategy, the automated generation and updating of tenant-level virtual network probing tasks are achieved. Subsequently, overlay probing based on OVS injection packages injects the generated / updated probing tasks into the cloud network for comprehensive virtual network monitoring. This addresses issues related to tenant-level coverage, network traffic scenario coverage, and insufficient automation in related methods, enabling user-unnoticed, routine probing and thus achieving end-to-end assurance of the user network.

[0122] The network detection task generation device provided in the embodiments of the present invention will be described below.

[0123] See Figure 8 The figure shows a schematic diagram of the network probing task generation device provided in an embodiment of the present invention. Figure 8 As shown, the network reconnaissance task generation device 800 includes:

[0124] Module 801 is used to obtain service instance data subscribed by the user for the cloud network.

[0125] The construction module 802 is used to construct the user resource topology for each traffic access scenario in the cloud network based on the business instance data. The user resource topology can represent the user's access intention to the cloud network.

[0126] The generation module 803 is used to generate a detection task for each traffic access scenario based on the user resource topology and the preset detection task generation strategy for each traffic access scenario. The detection task is used to perform network detection between user service access resources in the cloud network.

[0127] Optionally, the traffic access scenario includes at least one of the following:

[0128] East-west access scenarios between cloud servers;

[0129] Public network access scenarios;

[0130] Dedicated line access scenario.

[0131] Optionally, the building module 802 is specifically used for:

[0132] Based on the business instance data and the pre-built resource model for each traffic access scenario in the cloud network, a user resource topology is constructed for each traffic access scenario.

[0133] The resource model is used to characterize the inter-resource relationships of the cloud network under the traffic access scenario.

[0134] Optionally, the traffic access scenario includes an east-west access scenario between cloud hosts, and the resource model for the east-west access scenario between cloud hosts includes the relationship between resources under a Virtual Private Cloud (VPC) and the relationship between cloud hosts across VPCs; the construction module 802 is specifically used for:

[0135] Based on the resource relationships within the VPC and the business instance data, the user resource topology of the VPC instance in the east-west access scenario between cloud hosts is obtained. The user resource topology of the VPC instance includes at least one of the following: relationships between cloud hosts in the same subnet, relationships between cloud hosts across subnets, and mapping relationships between cloud hosts and physical computing nodes.

[0136] Based on the association between cloud hosts across VPCs and the business instance data, the user resource topology of VPC peering connection instances in the east-west access scenario between cloud hosts is obtained. The user resource topology of VPC peering connection instances includes the relationship between cloud hosts across VPCs and subnets.

[0137] Optionally, the traffic access scenario includes a public network access scenario, and the resource model of the public network access scenario includes the relationship between public Internet Protocol (IP) addresses and associated resources; the construction module 802 is specifically used for:

[0138] Based on the relationship between public Internet Protocol (IP) addresses and associated resources and the business instance data, obtain the user resource topology of public IP instances in the public network access scenario; the user resource topology of public IP instances includes at least one of the following: public network access inbound / outbound relationship, range of cloud hosts that can access the public network, and service addresses that provide public network services.

[0139] Optionally, the traffic access scenario includes a dedicated line access scenario, and the resource model of the dedicated line access scenario includes resource relationships under dedicated line to cloud access and resource relationships under cloud-to-cloud dedicated line interconnection; the construction module 802 is specifically used for:

[0140] Based on the resource relationships under dedicated line access to the cloud and the business instance data, the user resource topology of the dedicated line instance in the dedicated line access scenario is obtained. The user resource topology of the dedicated line instance includes the address relationship between the cloud host in the cloud network associated with the dedicated line instance and the private network segment of the Internet Data Center (IDC).

[0141] Based on the resource relationships under the cloud-to-cloud dedicated line interconnection and the business instance data, the user resource topology of the cloud interconnection instance under the dedicated line access scenario is obtained. The user resource topology of the cloud interconnection instance includes the correspondence between cloud hosts across resource pools associated with the cloud interconnection instance.

[0142] Optionally, the detection task generation strategy for the east-west access scenario between cloud hosts includes at least one of the following:

[0143] For cloud hosts located in the same VPC and under the same physical computing node, the cloud hosts are divided into two groups, which are used as probe sources and destinations respectively to generate probe tasks in pairs;

[0144] For cloud hosts located in the same VPC and subnet, select T cloud hosts as candidate cloud hosts from those belonging to the same physical computing node. Divide the candidate cloud hosts into two groups, which are used as probe sources and destinations respectively to generate probe tasks in pairs, where T is a positive integer.

[0145] For cloud hosts located in the same VPC but across subnets, cloud hosts in the same subnet are grouped according to their physical computing nodes. Within each group, T cloud hosts are selected as candidate cloud hosts. Different candidate cloud hosts across subnets are paired as probe sources and destinations to generate probe tasks.

[0146] For cloud hosts across VPCs, cloud hosts under the same VPC are grouped according to the physical computing node to which the cloud host belongs. Within each group, T cloud hosts are selected as candidate cloud hosts. Different candidate cloud hosts across VPCs are paired as probe sources and destinations to generate probe tasks.

[0147] Optionally, the strategy for generating detection tasks in the public network access scenario includes at least one of the following:

[0148] For cases where public network outbound access is used and the public IP is bound to a cloud host, the bound cloud host address is used as the probe source and the external public IP is used as the destination to generate a probe task.

[0149] For public network outbound access and public IP bound to source network address translation (SNAT), all cloud hosts covered by SNAT are grouped according to their physical computing nodes. T cloud hosts are selected as candidate cloud hosts in each group. A probe task is constructed with the candidate cloud hosts as the probe source and the public IP outside the cloud as the destination, where T is a positive integer.

[0150] For public network inbound access, a probe task is generated using a cloud host bound to a public IP address in the target resource pool as the probe source and an address providing public network services as the destination. The target resource pool is different from the resource pool involved in the public IP instance ordered by the user.

[0151] Optionally, the detection task generation strategy for the dedicated line access scenario includes at least one of the following:

[0152] For the case of accessing the cloud dedicated line, the cloud hosts covered by the cloud dedicated line instance are grouped according to the physical computing node to which they belong. In each group, T cloud hosts are selected as candidate cloud hosts. The candidate cloud hosts are used as the probe source, and the remote local address of the cloud dedicated line access is used as the destination to generate a probe task.

[0153] For the case of cloud-to-cloud private line interconnection, the cloud hosts covered at both ends of the cloud-to-cloud private line interconnection are grouped according to their respective physical computing nodes. In each group, T cloud hosts are selected as candidate cloud hosts. The candidate cloud hosts at both ends of the interconnection are paired as the probe source and the probe destination to generate probe tasks.

[0154] Optionally, the device further includes:

[0155] The first determining module is used to determine the number of candidate cloud hosts in the detection task generation strategy based on the user level.

[0156] Optionally, the generation module 803 is specifically used for:

[0157] The probe source and destination indicated by the probe task generation strategy are obtained from the user resource topology using a graph database, and a probe task is generated under the traffic access scenario.

[0158] Optionally, the device further includes:

[0159] The second determination module is used to determine the update range of the probe task based on the business instance data obtained within the time window;

[0160] The update module is used to update the detection tasks within the update range.

[0161] Optionally, the second determining module is specifically used for:

[0162] Business instance data acquired within the time window is grouped and processed according to resource identifiers;

[0163] For the business instance data within the group, the graph database is queried based on the resource identifier to determine the update scope of the probe task. The update scope includes the target resource instances affected by the business instance data within the group. The graph database stores the business instance data acquired before the time window.

[0164] Optionally, the business instance data within the group is further grouped according to user identifiers, and the second determining module is further configured to:

[0165] For business instance data within a group, the graph database is queried in parallel based on user identifiers and resource identifiers to determine the update scope of the probe task.

[0166] The network probing task generation device 800 can implement all the processes implemented in the above-described network probing task generation method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0167] The electronic device provided in the embodiments of the present invention will be described below.

[0168] See Figure 9 The figure shows a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Figure 9 As shown, the electronic device 900 includes: a processor 901, a memory 902, a user interface 903, and a bus interface 904.

[0169] Processor 901 is used to read the program from memory 902 and execute the following procedures:

[0170] Obtain data on the service instances that the user has subscribed to for the cloud network;

[0171] Based on the business instance data, a user resource topology is constructed for each traffic access scenario in the cloud network. The user resource topology can represent the user's access intent to the cloud network.

[0172] Based on the user resource topology under each traffic access scenario and the preset detection task generation strategy for the traffic access scenario, a detection task is generated for each traffic access scenario. The detection task is used to perform network detection between user service access resources in the cloud network.

[0173] exist Figure 9 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 901 and memory represented by memory 902 together. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 904 provides an interface. For different user devices, user interface 903 can also be an interface capable of connecting external or internal devices, including but not limited to keypads, displays, speakers, microphones, joysticks, etc.

[0174] The processor 901 is responsible for managing the bus architecture and general processing, while the memory 902 can store the data used by the processor 901 when performing operations.

[0175] Optionally, the traffic access scenario includes at least one of the following:

[0176] East-west access scenarios between cloud servers;

[0177] Public network access scenarios;

[0178] Dedicated line access scenario.

[0179] Optionally, the processor 901 is also used for:

[0180] Based on the business instance data and the pre-built resource model for each traffic access scenario in the cloud network, a user resource topology is constructed for each traffic access scenario.

[0181] The resource model is used to characterize the inter-resource relationships of the cloud network under the traffic access scenario.

[0182] Optionally, the traffic access scenario includes an east-west access scenario between cloud hosts, and the resource model of the east-west access scenario between cloud hosts includes the relationship between resources under a Virtual Private Cloud (VPC) and the relationship between cloud hosts across VPCs. The processor 901 is further used for:

[0183] Based on the resource relationships within the VPC and the business instance data, the user resource topology of the VPC instance in the east-west access scenario between cloud hosts is obtained. The user resource topology of the VPC instance includes at least one of the following: relationships between cloud hosts in the same subnet, relationships between cloud hosts across subnets, and mapping relationships between cloud hosts and physical computing nodes.

[0184] Based on the association between cloud hosts across VPCs and the business instance data, the user resource topology of VPC peering connection instances in the east-west access scenario between cloud hosts is obtained. The user resource topology of VPC peering connection instances includes the relationship between cloud hosts across VPCs and subnets.

[0185] Optionally, the traffic access scenario includes a public network access scenario, and the resource model of the public network access scenario includes the relationship between public Internet Protocol (IP) addresses and associated resources; the processor 901 is further configured to:

[0186] Based on the relationship between public Internet Protocol (IP) addresses and associated resources and the business instance data, obtain the user resource topology of public IP instances in the public network access scenario; the user resource topology of public IP instances includes at least one of the following: public network access inbound / outbound relationship, range of cloud hosts that can access the public network, and service addresses that provide public network services.

[0187] Optionally, the traffic access scenario includes a dedicated line access scenario, and the resource model of the dedicated line access scenario includes resource relationships under dedicated line to cloud access and resource relationships under cloud-to-cloud dedicated line interconnection; the processor 901 is further configured to:

[0188] Based on the resource relationships under dedicated line access to the cloud and the business instance data, the user resource topology of the dedicated line instance in the dedicated line access scenario is obtained. The user resource topology of the dedicated line instance includes the address relationship between the cloud host in the cloud network associated with the dedicated line instance and the private network segment of the Internet Data Center (IDC).

[0189] Based on the resource relationships under the cloud-to-cloud dedicated line interconnection and the business instance data, the user resource topology of the cloud interconnection instance under the dedicated line access scenario is obtained. The user resource topology of the cloud interconnection instance includes the correspondence between cloud hosts across resource pools associated with the cloud interconnection instance.

[0190] Optionally, the detection task generation strategy for the east-west access scenario between cloud hosts includes at least one of the following:

[0191] For cloud hosts located in the same VPC and under the same physical computing node, the cloud hosts are divided into two groups, which are used as probe sources and destinations respectively to generate probe tasks in pairs;

[0192] For cloud hosts located in the same VPC and subnet, select T cloud hosts as candidate cloud hosts from those belonging to the same physical computing node. Divide the candidate cloud hosts into two groups, which are used as probe sources and destinations respectively to generate probe tasks in pairs, where T is a positive integer.

[0193] For cloud hosts located in the same VPC but across subnets, cloud hosts in the same subnet are grouped according to their physical computing nodes. Within each group, T cloud hosts are selected as candidate cloud hosts. Different candidate cloud hosts across subnets are paired as probe sources and destinations to generate probe tasks.

[0194] For cloud hosts across VPCs, cloud hosts under the same VPC are grouped according to the physical computing node to which the cloud host belongs. Within each group, T cloud hosts are selected as candidate cloud hosts. Different candidate cloud hosts across VPCs are paired as probe sources and destinations to generate probe tasks.

[0195] Optionally, the strategy for generating detection tasks in the public network access scenario includes at least one of the following:

[0196] For cases where public network outbound access is used and the public IP is bound to a cloud host, the bound cloud host address is used as the probe source and the external public IP is used as the destination to generate a probe task.

[0197] For public network outbound access and public IP bound to source network address translation (SNAT), all cloud hosts covered by SNAT are grouped according to their physical computing nodes. T cloud hosts are selected as candidate cloud hosts in each group. A probe task is constructed with the candidate cloud hosts as the probe source and the public IP outside the cloud as the destination, where T is a positive integer.

[0198] For public network inbound access, a probe task is generated using a cloud host bound to a public IP address in the target resource pool as the probe source and an address providing public network services as the destination. The target resource pool is different from the resource pool involved in the public IP instance ordered by the user.

[0199] Optionally, the detection task generation strategy for the dedicated line access scenario includes at least one of the following:

[0200] For the case of accessing the cloud dedicated line, the cloud hosts covered by the cloud dedicated line instance are grouped according to the physical computing node to which they belong. In each group, T cloud hosts are selected as candidate cloud hosts. The candidate cloud hosts are used as the probe source, and the remote local address of the cloud dedicated line access is used as the destination to generate a probe task.

[0201] For the case of cloud-to-cloud private line interconnection, the cloud hosts covered at both ends of the cloud-to-cloud private line interconnection are grouped according to their respective physical computing nodes. In each group, T cloud hosts are selected as candidate cloud hosts. The candidate cloud hosts at both ends of the interconnection are paired as the probe source and the probe destination to generate probe tasks.

[0202] Optionally, the processor 901 is also used for:

[0203] The number of candidate cloud hosts in the detection task generation strategy is determined based on the user level.

[0204] Optionally, the processor 901 is also used for:

[0205] The probe source and destination indicated by the probe task generation strategy are obtained from the user resource topology using a graph database, and a probe task is generated under the traffic access scenario.

[0206] Optionally, the processor 901 is also used for:

[0207] Based on the business instance data obtained within the time window, determine the update scope of the probe task;

[0208] Update the detection missions within the update range.

[0209] Optionally, the processor 901 is also used for:

[0210] Business instance data acquired within the time window is grouped and processed according to resource identifiers;

[0211] For the business instance data within the group, the graph database is queried based on the resource identifier to determine the update scope of the probe task. The update scope includes the target resource instances affected by the business instance data within the group. The graph database stores the business instance data acquired before the time window.

[0212] Optionally, the service instance data within the group is further grouped according to user identifiers, and the processor 901 is further used for:

[0213] For business instance data within a group, the graph database is queried in parallel based on user identifiers and resource identifiers to determine the update scope of the probe task.

[0214] Preferably, the present invention also provides an electronic device 900, including a processor 901, a memory 902, and a computer program stored in the memory 902 and executable on the processor 901. When the computer program is executed by the processor 901, it implements the various processes of the above-described network probing task generation method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0215] This invention also provides a readable storage medium storing a computer program. When executed by a processor, this computer program implements the various processes of the network probing task generation method embodiments described above, achieving the same technical effects. To avoid repetition, it will not be described again here. The readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0216] This application also provides a computer program product, including computer instructions. When executed by a processor, these computer instructions implement the various processes of the above-described network probing task generation method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0217] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0218] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0219] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0220] The units described as separate components may or may not be physically separate. 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 units can be selected to achieve the purpose of the embodiments of the present invention, depending on actual needs.

[0221] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0222] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0223] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for generating network reconnaissance tasks, characterized in that, The method includes: Obtain data on the service instances that the user has subscribed to for the cloud network; Based on the business instance data, a user resource topology is constructed for each traffic access scenario in the cloud network. The user resource topology can represent the user's access intent to the cloud network. Based on the user resource topology under each traffic access scenario and the preset detection task generation strategy for the traffic access scenario, a detection task is generated for each traffic access scenario. The detection task is used to perform network detection between user service access resources in the cloud network. The strategy for generating detection tasks for east-west access scenarios between cloud hosts includes at least one of the following: For cloud hosts located in the same VPC and under the same physical computing node, the cloud hosts are divided into two groups, which are used as probe sources and destinations respectively to generate probe tasks in pairs; For cloud hosts located in the same VPC and subnet, select T cloud hosts as candidate cloud hosts from those belonging to the same physical computing node. Divide the candidate cloud hosts into two groups, which are used as probe sources and destinations respectively to generate probe tasks in pairs, where T is a positive integer. For cloud hosts located in the same VPC but across subnets, cloud hosts in the same subnet are grouped according to their physical computing nodes. Within each group, T cloud hosts are selected as candidate cloud hosts. Different candidate cloud hosts across subnets are paired as probe sources and destinations to generate probe tasks. For cloud hosts across VPCs, cloud hosts under the same VPC are grouped according to the physical computing node to which the cloud host belongs. In each group, T cloud hosts are selected as candidate cloud hosts. Different candidate cloud hosts across VPCs are paired as probe sources and destinations to generate probe tasks. The strategy for generating detection tasks in public network access scenarios includes at least one of the following: For cases where public network outbound access is used and the public IP is bound to a cloud host, the bound cloud host address is used as the probe source and the external public IP is used as the destination to generate a probe task. For public network outbound access and public IP bound to source network address translation (SNAT), all cloud hosts covered by SNAT are grouped according to their physical computing nodes. T cloud hosts are selected as candidate cloud hosts in each group. A probe task is constructed with the candidate cloud hosts as the probe source and the public IP outside the cloud as the destination, where T is a positive integer. For public network inbound access, a probe task is generated using a cloud host bound to a public IP address in the target resource pool as the probe source and an address providing public network services as the destination. The target resource pool is different from the resource pool involved in the public IP instance ordered by the user. The strategy for generating detection tasks in dedicated line access scenarios includes at least one of the following: For the case of accessing the cloud dedicated line, the cloud hosts covered by the cloud dedicated line instance are grouped according to the physical computing node to which they belong. In each group, T cloud hosts are selected as candidate cloud hosts. The candidate cloud hosts are used as the probe source, and the remote local address of the cloud dedicated line access is used as the destination to generate a probe task. For the case of cloud-to-cloud private line interconnection, the cloud hosts covered at both ends of the cloud-to-cloud private line interconnection are grouped according to their respective physical computing nodes. In each group, T cloud hosts are selected as candidate cloud hosts. The candidate cloud hosts at both ends of the interconnection are paired as the probe source and the probe destination to generate probe tasks.

2. The method according to claim 1, characterized in that, The step of constructing the user resource topology for each traffic access scenario in the cloud network based on the business instance data includes: Based on the business instance data and the pre-built resource model for each traffic access scenario in the cloud network, a user resource topology is constructed for each traffic access scenario. The resource model is used to characterize the inter-resource relationships of the cloud network under the traffic access scenario.

3. The method according to claim 2, characterized in that, The traffic access scenarios include east-west access scenarios between cloud hosts. The resource model for the east-west access scenarios between cloud hosts includes the resource relationships between resources under a Virtual Private Cloud (VPC) and the cloud host relationships across VPCs. Based on the business instance data and the pre-built resource model for each traffic access scenario in the cloud network, the user resource topology for each traffic access scenario is constructed, including at least one of the following: Based on the resource relationships within the VPC and the business instance data, the user resource topology of the VPC instance in the east-west access scenario between cloud hosts is obtained. The user resource topology of the VPC instance includes at least one of the following: relationships between cloud hosts in the same subnet, relationships between cloud hosts across subnets, and mapping relationships between cloud hosts and physical computing nodes. Based on the association between cloud hosts across VPCs and the business instance data, the user resource topology of VPC peering connection instances in the east-west access scenario between cloud hosts is obtained. The user resource topology of VPC peering connection instances includes the relationship between cloud hosts across VPCs and subnets.

4. The method according to claim 2, characterized in that, The traffic access scenarios include public network access scenarios, and the resource model of the public network access scenarios includes the relationship between public Internet Protocol (IP) addresses and associated resources; the step of constructing the user resource topology for each traffic access scenario based on the business instance data and the pre-built resource model for each traffic access scenario in the cloud network includes: Based on the relationship between public Internet Protocol (IP) addresses and associated resources and the business instance data, obtain the user resource topology of public IP instances in the public network access scenario; the user resource topology of public IP instances includes at least one of the following: public network access inbound / outbound relationship, range of cloud hosts that can access the public network, and service addresses that provide public network services.

5. The method according to claim 2, characterized in that, The traffic access scenarios include dedicated line access scenarios, and the resource model of the dedicated line access scenarios includes resource relationships under dedicated line access to the cloud and resource relationships under cloud-to-cloud dedicated line interconnection; the step of constructing the user resource topology under each traffic access scenario in the cloud network based on the business instance data includes at least one of the following: Based on the resource relationships under dedicated line access to the cloud and the business instance data, the user resource topology of the dedicated line instance in the dedicated line access scenario is obtained. The user resource topology of the dedicated line instance includes the address relationship between the cloud host in the cloud network associated with the dedicated line instance and the private network segment of the Internet Data Center (IDC). Based on the resource relationships under the cloud-to-cloud dedicated line interconnection and the business instance data, the user resource topology of the cloud interconnection instance under the dedicated line access scenario is obtained. The user resource topology of the cloud interconnection instance includes the correspondence between cloud hosts across resource pools associated with the cloud interconnection instance.

6. The method according to claim 1, characterized in that, The method further includes: The number of candidate cloud hosts in the detection task generation strategy is determined based on the user level.

7. The method according to claim 1, characterized in that, The step of generating detection tasks for each traffic access scenario based on the user resource topology and a preset detection task generation strategy for each traffic access scenario includes: The probe source and destination indicated by the probe task generation strategy are obtained from the user resource topology using a graph database, and a probe task is generated under the traffic access scenario.

8. The method according to claim 1, characterized in that, After generating the detection task for each traffic access scenario based on the user resource topology and the preset detection task generation strategy for each traffic access scenario, the method further includes: Based on the business instance data obtained within the time window, determine the update scope of the probe task; Update the detection missions within the update range.

9. The method according to claim 8, characterized in that, The step of determining the update scope of the probe task based on the business instance data obtained within the time window includes: Business instance data acquired within the time window is grouped and processed according to resource identifiers; For the business instance data within the group, the graph database is queried based on the resource identifier to determine the update scope of the probe task. The update scope includes the target resource instances affected by the business instance data within the group. The graph database stores the business instance data acquired before the time window.

10. The method according to claim 9, characterized in that, The business instance data within the group is further grouped according to user identifiers. The process of querying the graph database based on resource identifiers to determine the update scope of the probe task for the business instance data within the group includes: For business instance data within a group, the graph database is queried in parallel based on user identifiers and resource identifiers to determine the update scope of the probe task.

11. A network reconnaissance task generation device, characterized in that, The device includes: The acquisition module is used to acquire data on service instances that users have subscribed to for the cloud network. The construction module is used to construct the user resource topology for each traffic access scenario in the cloud network based on the business instance data. The user resource topology can represent the user's access intention to the cloud network. The generation module is used to generate a detection task for each traffic access scenario based on the user resource topology and the preset detection task generation strategy for each traffic access scenario. The detection task is used to perform network detection between user service access resources in the cloud network. The strategy for generating detection tasks for east-west access scenarios between cloud hosts includes at least one of the following: For cloud hosts located in the same VPC and under the same physical computing node, the cloud hosts are divided into two groups, which are used as probe sources and destinations respectively to generate probe tasks in pairs; For cloud hosts located in the same VPC and subnet, select T cloud hosts as candidate cloud hosts from those belonging to the same physical computing node. Divide the candidate cloud hosts into two groups, which are used as probe sources and destinations respectively to generate probe tasks in pairs, where T is a positive integer. For cloud hosts located in the same VPC but across subnets, cloud hosts in the same subnet are grouped according to their physical computing nodes. Within each group, T cloud hosts are selected as candidate cloud hosts. Different candidate cloud hosts across subnets are paired as probe sources and destinations to generate probe tasks. For cloud hosts across VPCs, cloud hosts under the same VPC are grouped according to the physical computing node to which the cloud host belongs. In each group, T cloud hosts are selected as candidate cloud hosts. Different candidate cloud hosts across VPCs are paired as probe sources and destinations to generate probe tasks. The strategy for generating detection tasks in public network access scenarios includes at least one of the following: For cases where public network outbound access is used and the public IP is bound to a cloud host, the bound cloud host address is used as the probe source and the external public IP is used as the destination to generate a probe task. For public network outbound access and public IP bound to source network address translation (SNAT), all cloud hosts covered by SNAT are grouped according to their physical computing nodes. T cloud hosts are selected as candidate cloud hosts in each group. A probe task is constructed with the candidate cloud hosts as the probe source and the public IP outside the cloud as the destination, where T is a positive integer. For public network inbound access, a probe task is generated using a cloud host bound to a public IP address in the target resource pool as the probe source and an address providing public network services as the destination. The target resource pool is different from the resource pool involved in the public IP instance ordered by the user. The strategy for generating detection tasks in dedicated line access scenarios includes at least one of the following: For the case of accessing the cloud dedicated line, the cloud hosts covered by the cloud dedicated line instance are grouped according to the physical computing node to which they belong. In each group, T cloud hosts are selected as candidate cloud hosts. The candidate cloud hosts are used as the probe source, and the remote local address of the cloud dedicated line access is used as the destination to generate a probe task. For the case of cloud-to-cloud private line interconnection, the cloud hosts covered at both ends of the cloud-to-cloud private line interconnection are grouped according to their respective physical computing nodes. In each group, T cloud hosts are selected as candidate cloud hosts. The candidate cloud hosts at both ends of the interconnection are paired as the probe source and the probe destination to generate probe tasks.

12. An electronic device, characterized in that, The electronic device includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the network reconnaissance task generation method as described in any one of claims 1 to 10.

13. A readable storage medium, characterized in that, The readable storage medium stores a computer program that, when executed by a processor, implements the steps of the network reconnaissance task generation method as described in any one of claims 1 to 10.

14. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the steps of the network reconnaissance task generation method as described in any one of claims 1 to 10.

Images