A service access method, device, equipment and computer storage medium

Abstract

The embodiment of the present application provides a service access method, device, equipment and computer storage medium, the method comprising: determining the configuration parameters of the target access service, the configuration parameters including the Overlay network address; determining the Underlay network address from the preset Underlay network address resource pool, and forming a mapping relationship between the Overlay network address and the Underlay network address; based on the mapping relationship, performing access policy configuration processing on the target access service to determine the target access policy; the target access policy is used to implement the target access service through the Overlay network and the Underlay network. In this way, by mapping the Overlay network address to the Underlay network address, the mutual access between the Overlay network and the Underlay network can be flexibly implemented, which improves the convenience and security of accessing the service.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a service access method, device, equipment and computer storage medium. Background Art

[0002] Software Defined Network (SDN) is a new solution for large data centers to achieve network virtualization. Its core idea is to separate the data plane from the control plane. For data centers that adopt the SDN architecture, the basic forwarding architecture is implemented through the Underlay network, and the Overlay network on the Underlay network provides network services for upper-layer applications.

[0003] However, in the related art, the interconnection between the Overlay network and the Underlay network requires operation and maintenance personnel to manually configure equipment and publish routing policies, which makes it impossible to quickly open some access services. Summary of the invention

[0004] The present application provides a service access method, apparatus, device and computer storage medium, which flexibly realizes mutual access between the Overlay network and the Underlay network by mapping the Overlay network address to the Underlay network address, thereby improving the convenience and security of accessing services.

[0005] The technical solution of this application is implemented as follows:

[0006] In a first aspect, an embodiment of the present application provides a service access method, which is applied to a service access system, and the SDN system includes an Overlay network and an Underlay network, and the method includes:

[0007] Determine the configuration parameters of the target access service, and the configuration parameters include the Overlay network address;

[0008] Determine the Underlay network address from the preset Underlay network address resource pool, and form a mapping relationship between the Overlay network address and the Underlay network address;

[0009] Based on the mapping relationship between the Overlay network address and the Underlay network address, the target access service is configured with an access policy to determine the target access policy; wherein the target access policy is used to implement the target access service through the Overlay network and the Underlay network.

[0010] In a second aspect, an embodiment of the present application provides a service access device, which is applied to a service access system, and the SDN system includes an Overlay network and an Underlay network. The service access device includes a determination unit, a mapping unit, and a configuration unit; wherein,

[0011] A determination unit configured to determine configuration parameters of a target access service, wherein the configuration parameters include an Overlay network address;

[0012] A mapping unit, configured to determine an Underlay network address from a preset Underlay network address resource pool, and form a mapping relationship between the Overlay network address and the Underlay network address;

[0013] The configuration unit is configured to perform access policy configuration processing on the target access service based on the mapping relationship between the Overlay network address and the Underlay network address to determine the target access policy; wherein the target access policy is used to implement the target access service through the Overlay network and the Underlay network.

[0014] In a third aspect, an embodiment of the present application provides an electronic device, the electronic device comprising a memory and a processor; wherein:

[0015] A memory for storing computer programs that can be run on the processor;

[0016] A processor is used to execute the steps of the method of the first aspect when running a computer program.

[0017] In a fourth aspect, an embodiment of the present application provides a computer storage medium, which stores a computer program, and when the computer program is executed, the steps of the method of the first aspect are implemented.

[0018] The embodiment of the present application provides a service access method, device, equipment and computer storage medium, the method is applied to a service access system, and the service access system includes an Overlay network and an Underlay network, determines the configuration parameters of the target access service, and the configuration parameters include the Overlay network address; determines the Underlay network address from a preset Underlay network address resource pool, and forms a mapping relationship between the Overlay network address and the Underlay network address; based on the mapping relationship between the Overlay network address and the Underlay network address, performs access policy configuration processing on the target access service to determine the target access policy; wherein the target access policy is used to implement the target access service through the Overlay network and the Underlay network. In this way, by mapping the Overlay network address to the Underlay network address, the mutual access between the Overlay network and the Underlay network is flexibly implemented, thereby realizing the connection between the cloud tenants in the Overlay network and the business system of the Underlay network at the network policy level, improving the flexibility and convenience of business configuration; at the same time, business access can be implemented through the configuration of the network policy layer, ensuring the isolation of cloud tenants from other cloud tenants and other Underlay network nodes, and improving the security of the overall network. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 A schematic diagram of an application architecture of a service access method provided for related technologies;

[0020] Figure 2 A flowchart of a service access method provided in an embodiment of the present application;

[0021] Figure 3 A schematic diagram of an application architecture of a service access method provided in an embodiment of the present application;

[0022] Figure 4 A flowchart of another service access method provided in an embodiment of the present application;

[0023] Figure 5 A schematic diagram of the structure of a service access device provided in an embodiment of the present application;

[0024] Figure 6 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application;

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

[0026] The following will be combined with the accompanying drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. It is understood that the specific embodiments described herein are only used to explain the related applications, rather than to limit the applications. It should also be noted that, for the convenience of description, only the parts related to the related applications are shown in the accompanying drawings.

[0027] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0028] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0029] It should be pointed out that the terms "first\second\third" involved in the embodiments of the present application are only used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0030] Before further describing the embodiments of the present application in detail, the professional terms involved in the embodiments of the present application are first explained:

[0031] Software Defined Network (SDN): It is a network solution for large data centers to achieve network virtualization. The key components are SDN controller and SDN gateway.

[0032] Virtual Switch (VSW): This device can be managed by the SDN controller through a southbound interface (such as OpenFlow) protocol.

[0033] Top of Rack (TOR): This device can be managed by the SDN controller through a virtual private network protocol (such as the EVPN protocol).

[0034] Virtual Machine (VM): A virtual cloud resource subscribed by a cloud tenant that can be used to deploy customer services.

[0035] Virtual Firewall (VFW): A virtual firewall is a distributed wall that is sunk to the VSW location to provide security protection for cloud tenant services.

[0036] Network Address Translation (NAT): used to convert intranet addresses into public network addresses.

[0037] Port address Translation (PAT): A type of NAT technology that implements address translation through port translation, that is, all hosts in the internal network can share a legal external IP address to access the public network.

[0038] Internet Protocol (IP) address: a unified network address format.

[0039] It is understandable that in a complete data center SDN environment, there are virtual switches or TORs, aggregation switches, SDN gateways, etc. For the interconnection between SDN-based overlay networks and underlay networks, there is no unified automation solution in the industry, and operation and maintenance personnel are usually required to manually configure devices and publish routes.

[0040] See also Figure 1 , which shows a schematic diagram of an access process provided by a related technology. In the network architecture provided by the related technology, it includes: Internet, egress router (CMnet), Internet firewall, SDN NAT gateway, SDN external gateway, SDN internal gateway, north-south convergence switch, intranet firewall, general container group and public container group. Among them, the container group can be represented by POD, which is the smallest deployable unit in the cloud framework. Here, a POD contains an application container (in some cases, multiple containers), storage resources, a unique network IP address, and some options to determine how the container should run. In other words, POD represents an independent application running instance, which may consist of a single container or several tightly coupled containers.

[0041] for Figure 1 The architecture shown in the figure is used when the following business requirements arise: the virtual devices or subsystems deployed by cloud tenants on the general POD (Overlay network) need to access the cloud services deployed by the public cloud vendor on the shared POD (Underlay network). The existing solutions are as follows, Figure 1 As shown in the figure, an east-west aggregation switch needs to be added to the network architecture. The cloud tenant needs to bind an east-west network card (network card at the Underlay network level) to the virtual device to be accessed. The network card can access the cloud service of the shared POD through the east-west aggregation switch. The specific access path is: customer VM-virtual switch-east-west aggregation switch-business subsystem.

[0042] In this solution, the east-west network card is at the underlay level, and the SDN controller cannot automatically configure network policies for it. Therefore, the only access policy is to "open all east-west network card IPs to all service IPs of the shared POD on the access switch and the east-west aggregation switch" to avoid cloud tenants being unable to use the shared POD service immediately after subscribing to it.

[0043] That is to say, in the related technology, it is necessary to use an east-west aggregation switch and create an east-west virtual network card separately on the cloud host VM to realize the east-west business needs of cloud tenants in the Overlay network and business nodes in the Underlay network. However, the related technology has the following defects. On the one hand, it is necessary to add an additional east-west aggregation switch, which increases the cost of hardware equipment; on the other hand, cloud tenants need to create additional east-west network cards, which has a poor user experience and consumes additional server resources, increasing costs; on the other hand, access through the east-west network card is a pure Underlay path, which requires the configuration of network policies in advance, and cannot be controlled by the SDN controller and cannot be linked with the cloud platform; on the other hand, in order to meet the requirements of users to open access in real time, the pre-configured network policy must be global, resulting in the network policy level between users not being isolated, and there are security risks.

[0044] Based on this, an embodiment of the present application provides a service access method, which is applied to a service access system, and the service access system includes an Overlay network and an Underlay network. The basic idea of ​​the method is: determine the configuration parameters of the target access service, and the configuration parameters include the Overlay network address; determine the Underlay network address from a preset Underlay network address resource pool, and form a mapping relationship between the Overlay network address and the Underlay network address; based on the mapping relationship between the Overlay network address and the Underlay network address, perform access policy configuration processing on the target access service to determine the target access policy; wherein the target access policy is used to implement the target access service through the Overlay network and the Underlay network. In this way, by mapping the Overlay network address to the Underlay network address, the mutual access between the Overlay network and the Underlay network is flexibly implemented, thereby realizing the connection between the cloud tenants in the Overlay network and the business system of the Underlay network at the network policy level, improving the flexibility and convenience of business configuration; at the same time, business access can be achieved through the configuration of the network policy layer, ensuring the isolation of cloud tenants from other cloud tenants and other Underlay network nodes, and improving the security of the overall network.

[0045] The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0046] In one embodiment of the present application, see Figure 2 , which shows a flow chart of a service access method provided by an embodiment of the present application. Figure 2 As shown, the method may include:

[0047] S101: Determine configuration parameters of a target access service, where the configuration parameters include an Overlay network address.

[0048] It should be noted that the service access method provided in the embodiment of the present application is applied to the hardware device in the service access system. The hardware device may include various types, such as electronic devices with computing capabilities, which is not limited in the embodiment of the present application.

[0049] It should also be noted that the service access system may include an underlay network and an overlay network. In practical applications, the service access system may generally adopt an SDN architecture, and the subsequent embodiments will refer to the service access system as an SDN system for explanation.

[0050] Here, SDN is a network with separate control plane and data plane. The Underlay network carries the physical forwarding and transmission of the underlying information. The Overlay network is a virtual network built on the Underlay network to provide users with various network services. In addition, the core management device of the SDN network is the SDN controller, which can control the accessibility of any node in the Overlay network, so that users can access the specified node, realizing dynamic configuration and flexible adjustment of the network.

[0051] The following takes the service access system using the SDN network architecture as an example to explain the service access method. In addition, although the nodes in the Overlay network can be virtual devices or service nodes, the nodes in the Underlay network also have two possibilities, but for the convenience of explanation, the nodes in the Overlay network are considered to be virtual devices, and the nodes in the Underlay network are considered to be service nodes, but this does not constitute a limitation on the embodiments of the present application.

[0052] There are multiple cloud tenants and multiple cloud services in the service access system. Through the management of the cloud platform, cloud users can subscribe to different cloud services. If a cloud tenant subscribes to a new cloud service, the cloud platform will use the SDN controller to control the connection between the network node corresponding to the cloud tenant and the network node where the service is located. Specifically, virtual devices of different users have different Overlay network addresses. The SDN controller can flexibly provide services to different users by controlling the accessibility of different Overlay network addresses to other nodes. However, the SDN network has a north-south architecture. If the cloud service is set in the Underlay network or in another Overlay network, it is necessary to use a method that relies on physical connections to achieve connectivity between cloud tenants and cloud services. However, doing so not only wastes physical device resources, but also affects the security of the entire network because the physical connection cannot be managed by the SDN controller.

[0053] It should also be noted that the embodiment of the present application develops an SDN orchestrator (or simply called an orchestrator) in the north direction of the SDN controller. Through the SDN orchestrator, the conversion of Overlay network addresses and Underlay network addresses can be realized to achieve mutual access between the Overlay network and the Underlay network. Since the SDN controller can manage the step of converting the Overlay network address and the Underlay network address, the security of the entire network is not affected.

[0054] Therefore, in some embodiments, determining the configuration parameters of the target access service may include:

[0055] Receive service access requests through the orchestrator’s northbound interface;

[0056] Determine the configuration parameters of the target access service according to the service access request.

[0057] It should be noted that the service access method provided in the embodiment of the present application is specifically applied to the orchestrator in the SDN system, and the user can call the northbound interface of the orchestrator to upload an access request, and then the orchestrator will determine the configuration parameters of the target access service according to the access request. Among them, the configuration parameters are used to indicate the relevant information of the target access service, such as request end information, destination end information, access direction, access protocol, application user information, etc.

[0058] Here, for access services that do not involve mutual access between the Underlay network and the Overlay network, they can be directly implemented by the SDN controller or other devices. Therefore, the target access service submitted to the SDN orchestrator must involve mutual access between the Underlay network and the Overlay network, such as a virtual device in the Overlay network requesting access to a service node in the Underlay network, or a service node in the Underlay network requesting access to a virtual device in the Overlay network, or a virtual device in the Overlay network requesting access to a virtual device node in another Overlay network. In particular, different Overlay networks need to rely on the Underlay network connection, so an Overlay network accessing another Overlay network will also involve access between Overlay and Underlay.

[0059] That is to say, the configuration parameters of the target access service submitted to the SDN orchestrator must include the Overlay network address, but the Overlay network address may be the address of the requesting end (the Overlay network requests access to the Underlay network) or the address of the destination end (the Underlay network requests access to the Overlay network). Moreover, the configuration parameters may also include both the Overlay network address of the requesting end and the Overlay network address of the destination end (the Overlay network requests access to another Overlay network).

[0060] Furthermore, in some embodiments, after determining the configuration parameters of the target access service, the method may further include:

[0061] Authenticate the target access service;

[0062] If the authorization authentication is successful, determine whether the target access service meets the quota management rules;

[0063] In the case where the target access service meets the quota management rules, determining whether there is a policy group corresponding to the target access service in the service access system;

[0064] In the case where a policy group corresponding to the target access service exists in the service access system, determining whether the format of the configuration parameter is correct;

[0065] When the format of the configuration parameter is correct, the step of determining the Underlay network address from the preset Underlay network address resource pool is performed.

[0066] It should be noted that after the SDN orchestrator receives the configuration parameters of the target access service, it is still necessary to make some prior judgments on the target access service, such as authority identification, quota management judgment, whether a policy group exists, and whether the parameter type is correct.

[0067] Among them, the quota management rules limit the maximum number of access policies that each user is allowed to configure. If the quota is exceeded, the SDN orchestrator will refuse to perform this operation. The policy group corresponding to the target access request is a file used to subsequently write the target access rules corresponding to the target access request. Generally speaking, each user will have a policy group for writing all the access policies of the user. In other words, the policy corresponding to the target access request actually refers to the policy group of the user who sent the target access request. If the user does not have a policy group, you need to create a policy group for the user; if the user has a policy group, you can directly perform subsequent operations.

[0068] In this way, after the SDN orchestrator receives the configuration parameters of the target access service, it performs subsequent policy configuration according to the configuration parameters, thereby realizing the access service through the Overlay network and the Underlay network.

[0069] S102: Determine an Underlay network address from a preset Underlay network address resource pool, and form a mapping relationship between the Overlay network address and the Underlay network address.

[0070] It should be noted that, in the SDN system of the embodiment of the present application, there is a preset Underlay network address resource pool, which contains some available addresses in the Underlay network. In other words, the Underlay network addresses in the preset Underlay network address resource pool and the service nodes deployed in the Underlay network (whose network addresses are actually also Underlay network addresses) belong to the same private network segment.

[0071] After receiving the configuration parameters of the target access service, the SDN orchestrator will randomly determine an Underlay network address from the preset Underlay network address resource pool, and then form a mapping relationship between the Overlay network address and the Underlay network address. In particular, if there are two Overlay network addresses in the configuration parameters, the SDN orchestrator will also determine two Underlay network addresses from the preset Underlay network address resource pool, and a mapping relationship will be formed between one Underlay network address and one Overlay network address.

[0072] Specifically, in some embodiments, determining the Underlay network address from a preset Underlay network address resource pool may include:

[0073] An Underlay network address is obtained by randomly selecting from a preset Underlay network address resource pool.

[0074] It should be noted that when determining the Underlay network address, a random selection may be performed from a preset Underlay network address resource pool.

[0075] In addition, in some embodiments, determining the Underlay network address from a preset Underlay network address resource pool may further include:

[0076] Determine the business scenario corresponding to the target access service based on the configuration parameters;

[0077] Based on the service scenario, an underlay network address is determined from a preset underlay network address resource pool.

[0078] It should be noted that, in actual applications, there are one-to-one mapping technologies (such as static NAT technology) and one-to-many mapping technologies (such as PAT technology) for mapping network addresses, that is, one Underlay network address can be bound to one virtual device (that is, one Underlay network address forms a mapping relationship with one Overlay network address), or one Underlay network address can be used by multiple virtual devices (that is, one Underlay network address forms a mapping relationship with multiple Overlay network addresses) to improve the utilization efficiency of the Underlay network address.

[0079] Therefore, according to the configuration parameters of the target access service, the service scenario of the Underlay network address can be clarified, and different mapping technologies can be used for different service scenarios, thereby saving Underlay network addresses. The following is a specific description based on three access scenarios.

[0080] Access scenario 1: One-way access from the overlay network to the underlay network.

[0081] In the SDN system, access scenario 1 is the most frequent scenario, for example, a cloud tenant subscribes to a database placed on the Underlay network by a cloud vendor. In order to save Underlay network address resources and improve the speed of policy orchestration, access scenario 1 can use a one-to-many mapping technology. Therefore, in some embodiments, the determination of the Underlay network address in the preset Underlay network address resource pool based on the business scenario may include:

[0082] In the case where the service scenario is unidirectional access from the Overlay network to the Underlay network, based on the service scenario, determining the Underlay network address from the first Underlay network address resource pool;

[0083] Each Underlay network address in the first Underlay network address resource pool is used to form a mapping relationship with a plurality of Overlay network addresses.

[0084] It should be noted that for access scenario 1, a one-to-many mapping technology (such as PAT technology) is adopted. Specifically, one or more Underlay network address resources are selected in advance in the preset Underlay network address resource pool to form a first Underlay network address resource pool, and each Underlay network address resource can simultaneously form a mapping relationship with multiple Overlay network addresses. For example, virtual device 1 (Overlay network address 1), virtual device 2 (Overlay network address 2), and virtual device 3 (Overlay network address 3) all apply for access to the Underlay network (the specific destinations may be different), then virtual device 1 (Overlay network address 1), virtual device 2 (Overlay network address 2), and virtual device 3 (Overlay network address 3) can all use the same Underlay network address for access. Taking PAT technology as an example, in the specific access process, virtual device 1 (Overlay network address 1), virtual device 2 (Overlay network address 2), and virtual device 3 (Overlay network address 3) send data to the destination through different ports of the same Underlay network address and receive data sent back by the destination. However, this technology is only applicable to one-way access, that is, virtual device 1 will be randomly assigned an access port in a specific access process, but if virtual device 1 is disconnected, the port may be assigned to other devices, so the destination cannot achieve connection with virtual device 1 through reverse addressing.

[0085] In addition, in access scenario one, the Underlay network address may be randomly selected from the first Underlay network address resource pool.

[0086] Access scenario 2: Unidirectional or bidirectional access from the Underlay network to the Overlay network.

[0087] Except for access scenario 1, the frequency of other access scenarios is not high, and the use of one-to-many mapping technology will lead to unstable network architecture. Therefore, the method of determining the Underlay network address in the preset Underlay network address resource pool based on the business scenario also includes:

[0088] In the case where the service scenario is unidirectional access from the Underlay network to the Overlay network, or the service scenario is bidirectional access from the Underlay network to the Overlay network, determining the Underlay network address from a second preset Underlay network address resource pool;

[0089] Each Underlay network address in the second Underlay network address resource pool is only used to form a mapping relationship with one Overlay network address.

[0090] It should be noted that the part of the preset Underlay network address resource pool except the first Underlay network address resource pool is called the second Underlay network address resource pool, and the Underlay network address in the second Underlay network address resource pool can only form a mapping relationship with one Overlay network address.

[0091] In other words, if a service node in an Underlay network wants to access a virtual device in an Overlay network, it needs to randomly select from the second Underlay network address resource pool and uniquely bind the selected Underlay network address to the virtual device, that is, the Underlay network address cannot be bound to other devices before unbinding. At this time, the service node can establish a connection relationship with the Underlay network address. This method not only supports one-way access between the service node and the virtual device, but also supports two-way access between the service node and the virtual device.

[0092] Access scenario 3: One-way access from the Overlay network to the Overlay network.

[0093] In access scenario 3, there are actually two Overlay network addresses, namely, the request end Overlay network address and the destination end Overlay network address. Therefore, in some embodiments, the determining of the Underlay network address in the preset Underlay network address resource pool based on the service scenario may also include:

[0094] In the case where the service scenario is unidirectional access from the Overlay network to the Overlay network, a first Underlay network address is determined from the first Underlay network address resource pool, and the first Underlay network address is used to form a mapping relationship with the request end Overlay network address;

[0095] A second Underlay network address is determined from a second preset Underlay network address resource pool, and the second Underlay network address is used to form a mapping relationship with a destination Overlay network address.

[0096] It should be noted that in the scenario of accessing the Overlay network from the Overlay network, first, the second Underlay network address is determined in the second preset Underlay network address resource pool, and the destination Overlay network address is uniquely mapped to the second Underlay network address. At this time, the essence of the access scenario becomes "accessing the second Underlay network address from the requesting end Overlay network address", that is, the access scenario essentially becomes scenario one, so for the requesting end Overlay network address, the same one-to-many mapping technology can be used, that is, the requesting end can use the Underlay network address in the first Underlay resource pool to apply for access, thereby saving Underlay network resources.

[0097] It should also be noted that due to technical implementation reasons, this scenario is generally limited to the scenario of the Overlay network accessing the Overlay network unidirectionally. For the scenario of the Overlay network accessing the Overlay network bidirectionally, it can be split into two target access services. However, the above is only a specific implementation method and does not constitute a limitation on this application.

[0098] In this way, by converting the Overlay network address into the Underlay network address, the Overlay network and the Underlay network can access each other, so that the aforementioned target access service can be achieved through the Overlay network and the Underlay network.

[0099] S103: Based on the mapping relationship between the Overlay network address and the Underlay network address, perform access policy configuration processing on the target access service to determine the target access policy.

[0100] The target access policy is used to implement target access services through the Overlay network and the Underlay network.

[0101] It should be noted that the Underlay network address enables the intercommunication between the Overlay network and the Underlay network. Therefore, the SDN orchestrator can perform policy orchestration on the target access service on this basis to obtain the target access policy. The target access policy is used to indicate the network path between the request end and the destination end in the service to be accessed, and the Overlay network address has been replaced by the Underlay network address.

[0102] For the convenience of explanation, the Underlay network address in the preset Underlay network address resource pool is called a Dummy Fip address, the Overlay address of the virtual device in the Overlay network is called a virtual device Overlay network address, and the Underlay network address of the service node in the Underlay network is called a service Underlay network address.

[0103] For example, when the Overlay network accesses the Underlay network, the requesting end is the virtual device Overlay network address, and the destination end is the service Underlay network address. Since the virtual device Overlay network address has formed a mapping relationship with the DummyFip address, the target access policy actually refers to the access path from the Dummy Fip address to the service Underlay network address.

[0104] For another example, when the Underlay network accesses the Overlay network, the requesting end is the service Underlay network address, and the destination end is the virtual device Overlay network address; since the virtual device Overlay network address has formed a mapping relationship with the DummyFip address, the target access policy actually refers to the access path from the service Underlay network address to the Dummy Fip address.

[0105] For another example, when the Underlay network accesses the Overlay network, the requesting end is the virtual device Overlay network address, and the destination end is another virtual device Overlay network address; since the virtual device Overlay network address of the requesting end is mapped to the Dummy Fip address of the requesting end, and the virtual device Overlay network address of the destination end is mapped to the Dummy Fip address of the destination end, the target access policy actually refers to the access path from the Dummy Fip address of the requesting end to the Dummy Fip address of the destination end.

[0106] Further, in some embodiments, performing access policy configuration processing on the target access service based on the mapping relationship between the Overlay network address and the Underlay network address to determine the target access policy may include:

[0107] In the case where the service scenario is bidirectional access from the Underlay network to the Overlay network, the target access service is split into a first direction access service and a second direction access service;

[0108] Based on the mapping relationship between the Underlay network address and the Overlay network address, access policy configuration processing is performed on the first direction access service and the second direction access service respectively to obtain a first access policy and a second access policy;

[0109] The first access policy and the second access policy are determined as target access policies.

[0110] It should be noted that, based on the above content, business scenario 2 can be further divided into two scenarios: scenario 2-1: unidirectional access from the Underlay network to the Overlay network; scenario 2-2: bidirectional access from the Underlay network to the Overlay network.

[0111] For scenario 2-1, continue to execute subsequent policy orchestration processing.

[0112] For scenario 2-2, the target access service needs to be split into a first direction access service and a second direction access service, and then an access policy is configured for each access service to obtain a first access policy and a second access policy.

[0113] For example, in the case where the Underlay network bidirectionally accesses the Overlay network, there is a virtual device Overlay network address and a service Underlay network address. According to the above content, the virtual device Overlay network address has been converted into a Dummy Fip address. At this time, the target access service can be divided into "the service of unidirectional access to the service Underlay network address by the Dummy Fip address" and "the service of unidirectional access to the Dummy Fip address by the service Underlay network address".

[0114] In this way, by converting the Overlay network address into the Underlay network address, it is possible to support mutual access between the Overlay network and the Underlay network, thereby obtaining a target access policy corresponding to the target access service.

[0115] It should also be noted that the target access policy may include access control list (ACL) parameters; wherein the ACL parameters include at least one of the following: source IP address, destination IP address, source port, destination port, and protocol number. Therefore, in some embodiments, the method may further include:

[0116] The target access policy is sent to the controller through the orchestrator, and the target access policy is sent to the preset access control list through the controller to implement the target access service through the Overlay network and the Underlay network.

[0117] It should be noted that SDN networks generally manage the forwarding function of the entire network through SDN controllers. Therefore, after the SDN orchestrator obtains the target access policy, it is also necessary to send the target access policy to the preset control access list (or flow table, VSW flow table) of the entire network system through the SDN controller to achieve the target access service through the Underlay network and Overlay network.

[0118] In summary, based on the existing capabilities under the two-layer NAT architecture of the SDN network, the embodiment of the present application develops an orchestrator in the northbound direction of the SDN controller. By using the orchestrator, flexible network policies are issued and implemented in the flow table (also called VSW flow table) through the SDN controller to achieve flexible network control of the virtual device service entry and exit.

[0119] See also Figure 3 , which shows a schematic diagram of the architecture of the service access method provided in the embodiment of the present application. Figure 3 As shown, compared with the prior art, the architecture adds a Dummy FIP functional layer, so that the SDN orchestrator (not shown in the figure) can uniquely map the Overlay network address to the Dummy FIP (essentially the Underlay network address), thereby achieving mutual access between the Overlay network and the Underlay network. The following takes the aforementioned business requirements as an example to specifically explain the service access method provided in the embodiment of the present application.

[0120] The business requirement is: the virtual devices or subsystems deployed by cloud tenants on general PODs need to access the cloud services deployed by public cloud vendors on shared PODs.

[0121] The specific solutions to this business requirement are as follows:

[0122] (1): A cloud tenant creates a virtual device (VM). At this time, the virtual device is assigned an Overlay network address (hereinafter referred to as Fixip). This address is valid and unique in the cloud tenant's Virtual Private Cloud (VPC). However, different tenants or different VPCs can reuse the Overlay network address. This address cannot be used to uniquely identify the virtual device outside the Overlay network.

[0123] (2): The orchestrator at the upper layer of SDN can provide an entry for cloud tenants through an open interface to convert the Fixip of the virtual device into a Dummy Fip. The Dummy Fip is randomly obtained from the pre-planned Dummy Fip Pool (equivalent to the preset Underlay network address resource pool).

[0124] (3): The SDN orchestrator can also open interfaces so that cloud tenants can automatically configure five-tuple access control lists (ACLs) policies so that the specified VM Dummy Fip can access the specified shared domain Underlay network address and thus access the specified destination.

[0125] It should be noted that the addresses of the Dummy Fip and the shared POD Underlay network belong to the same private network, so the virtual device and the shared POD service subsystem can access each other through the Dummy Fip.

[0126] like Figure 3 As shown, the specific access path can be: customer VM-virtual switch-north-south aggregation switch-SDN external gateway-Dummy FIP mapping-north-south aggregation switch-intranet firewall-business subsystem. In other words, Figure 3 The access path does not need to introduce east-west aggregation switches.

[0127] The embodiment of the present application provides a service access method, which is applied to a service access system, and the service access system includes an Overlay network and an Underlay network. By determining the configuration parameters of the target access service, and the configuration parameters include the Overlay network address; determining the Underlay network address from a preset Underlay network address resource pool, and forming a mapping relationship between the Overlay network address and the Underlay network address; based on the mapping relationship between the Overlay network address and the Underlay network address, performing access policy configuration processing on the target access service, and determining the target access policy; wherein the target access policy is used to implement the target access service through the Overlay network and the Underlay network. In this way, by mapping the Overlay network address to a unique Underlay network address, the Overlay network and the Underlay network can access each other, so that flexible access policy configuration can be performed for cloud tenants, and cloud tenants in the Overlay network can be connected to the business system of the Underlay network at the network policy level, thereby improving the flexibility of business configuration and enhancing user experience; at the same time, business access can be achieved only through the configuration of the network policy layer, without the need to introduce new hardware equipment, thus saving hardware resources; in addition, each cloud tenant is isolated from other cloud tenants and other Underlay network nodes, thereby improving the security of the overall network.

[0128] In another embodiment of the present application, see Figure 4 , which shows a flow chart of another service access method provided by an embodiment of the present application. Figure 4 As shown, the method may include:

[0129] S201: The cloud platform issues a service issuance notification.

[0130] The service access method provided in the embodiment of the present application is applied to an SDN system, and the SDN system has a two-layer architecture: an Overlay network and an Underlay network. The SDN system includes an SDN orchestrator and an SDN controller, which are used to implement the configuration and orchestration of access policies.

[0131] If there are new business requirements in the SDN system, users will submit access requirements through the cloud platform, and then the cloud platform will send a business delivery notification to the SDN orchestrator to request the configuration of access policies. Generally speaking, the business delivery notification includes information such as the ACL policy quintuple and access direction.

[0132] Exemplarily, the service delivery notification may include the following parameters: account information, local VPC information, local subnet information, peer service type, peer service IP and port, Internet Protocol version 4 (IPv4) / IPv6, access direction and access protocol.

[0133] In this way, according to the notification issued by the service, the SDN orchestrator can obtain the configuration parameters of the target access service (equivalent to the service).

[0134] S202: Perform authentication through the authentication interface to determine whether the authentication is successful.

[0135] Here, for step S202, if the judgment result is that the authentication is successful, step S203 is executed; if the judgment result is that the authentication fails, step S215 is executed.

[0136] It should be noted that the target access service is authenticated using the authentication interface. If the authentication is successful, the subsequent execution steps are entered; if the authentication fails, a business failure message is returned and the operation and maintenance personnel are asked to handle it.

[0137] S203: Query the quota usage through the quota management interface to determine whether to continue creating.

[0138] Here, for step S203, if the judgment result is yes, step S204 is executed; if the judgment result is no, step S215 is executed.

[0139] It should be noted that, considering the stability of the network architecture, different quotas are set for different virtual devices, that is, the SDN orchestrator will only configure a limited number of target access policies for each virtual device. Here, the number of quotas can be determined based on the actual application environment. At the same time, if a cloud tenant has indeed subscribed to a large number of services through a certain virtual device, the operation and maintenance personnel can manually expand the quota.

[0140] In summary, after querying the quota usage number, if the quota usage number is small, you can continue to create the policy and execute step S204; otherwise, a service failure message is returned and the operation and maintenance personnel are requested to handle it.

[0141] S204: Determine whether to create a policy group.

[0142] Here, for step S203, if the judgment result is yes, step S205 is executed; if the judgment result is no, step S206 is executed.

[0143] It should be noted that each virtual device will correspond to a policy group, which is used to write all access policies under the virtual device. Therefore, if the virtual device does not have a policy group, you need to create a policy group corresponding to the virtual device; if the virtual device has a policy group, you can directly create policies in the policy group.

[0144] S205: Calling a policy group creation interface.

[0145] It should be noted that, when the virtual device has no policy group, a new policy group is created using the policy group creation interface.

[0146] S206: Determine whether the port identifier is empty.

[0147] Here, for step S206, if the judgment result is yes, step S207 is executed; if the judgment result is no, step S208 is executed.

[0148] It should be noted that the port identifier (Portid) in the target access service parameter is correct. Because the cloud platform may ignore the Portid parameter, but the port identifier (Portid) is a necessary parameter for subsequent policy configuration. Specifically, determine whether the Portid parameter is empty. If the Portid parameter is empty, call the Portid query interface to obtain the Portid parameter; if the Portid parameter is not empty, execute the next step.

[0149] In particular, in some embodiments, after obtaining the Portid parameter, it is also necessary to determine whether the Portid parameter is correct.

[0150] S207: Call the Portid query interface.

[0151] It should be noted that, when the Portid parameter is empty, the Portid query interface is called to obtain the Portid parameter.

[0152] S208: Determine the business scenario.

[0153] Here, for step S206, if the business scenario is O to O (i.e. the aforementioned access scenario 1), execute step S207; if the business scenario is O to U (i.e. the aforementioned access scenario 2), execute step S211; if the business scenario is Oto U (i.e. the aforementioned access scenario 3), execute step S214.

[0154] It should be noted that, according to different business scenarios corresponding to the target access service and different access directions, access to the Underlay network can be achieved by binding a fixed Dummy Fip to the virtual device or by using a shared Dummy Fip. In particular, business scenarios can be divided into three categories, which are described in detail as follows.

[0155] (1) The business scenario is O to U, that is, the request end of the business scenario is an Overlay network address (i.e., the address of the virtual device), and the destination end is an Underlay network address (i.e., the address of the business node). Since the occurrence frequency of this business scenario is very high, one or more shared Dummy Fips are taken out in advance from the Dummy Pool, and the port address translation (PAT) technology is used to realize the reuse of these Dummy Fips to save address resources. In other words, for the O to U business scenario, there is no need to bind the Dummy Fip, but directly use the previously configured shared Dummy Fip for mapping and policy configuration.

[0156] In other words, multiple virtual devices can be mapped to the same Dummy Fip, and the Underlay network address of the destination can be accessed through different ports of this Dummy Fip.

[0157] (2) The business scenario is U to O, that is, the request end of the business scenario is an Underlay network address, and the destination end is an Overlay network address. In this case, a Dummy IP needs to be randomly selected from the Dummy Pool and bound one-to-one to the Overlay network address.

[0158] (3) The business scenario is O to O, that is, the requesting end and the destination end of the business scenario are both an Overlay network address. In this case, you need to randomly select a Dummy IP from the Dummy Pool and bind the Dummy IP one-to-one to the destination Overlay network address. For the requesting end Overlay network address, you can reuse the shared Dummy Fip in the "Business scenario is O to U".

[0159] S209: Call Dumm Fip to check the binding interface.

[0160] It should be noted that when the business scenario is O to O, the Dummfip binding interface is called to randomly determine a Dummy Fip in the DummyPool, and bind the Dummy Fip to the virtual device at the destination end, thereby forming a mapping relationship between the Dummy Fip and the Overlay network address of the destination end.

[0161] S210: Replace the destination IP.

[0162] It should be noted that the determined Dummy Fip replaces the destination IP (ie, the destination Overlay network address), and the requester Overlay network address can use the fixed Dummy Fip in the PAT path.

[0163] S211: Call Dummy Fip to check the binding interface.

[0164] It should be noted that when the business scenario is U to O, the Dummfip binding interface is called, a Dummy Fip is randomly determined in the DummyPool, and the Dummy Fip is bound to the virtual device at the destination end, thereby forming a mapping relationship between the Dummy Fip and the Overlay network address of the destination end.

[0165] S212: Determine whether it is bidirectional.

[0166] Here, for step S212, if the judgment result is yes, step S213 is executed; if the judgment result is no, step S214 is executed.

[0167] It should be noted that since the U to O scenarios include two categories, for the business scenario where the Overlay network accesses the Underlay network unidirectionally, the Dummy Fip can be bound to the destination Overlay network address, and then step S214 can be executed; for the business scenario where the Underlay network accesses the Overlay network bidirectionally, step S213 needs to be executed.

[0168] S213: Split into two rules: in / out.

[0169] It should be noted that, for a service scenario in which the Underlay network bidirectionally accesses the Overlay network, it needs to be split into two rules, and the details are described in the previous embodiment.

[0170] S214: Calling a policy rule creation interface.

[0171] It should be noted that, through the above steps, the Overlay network address in the target access service parameters has been converted into Dummy Fip, and then according to other parameters and Dummy Fip in the target access service, the target access policy is generated through the policy rule creation interface to implement the target access service through the Overlay network and the Underlay network. In a specific embodiment, the SDN orchestrator configures the ACL policy for the virtual device, clarifies the five-tuple of the policy, and the policy granularity is accurate to the port level, so as to implement the specified virtual device port and access the specified Underlay service port.

[0172] In particular, virtual devices that are not configured with policies through the orchestrator cannot access the underlay network. Therefore, the SDN orchestrator can dynamically manage the network policies of each virtual device and achieve isolation between different tenants and between tenants and services.

[0173] S215: Determine whether all services have been successfully delivered.

[0174] Here, for step S215, if the judgment result is yes, step S216 is executed; if the judgment result is no, step S217 is executed.

[0175] It should be noted that the target access policy is sent to the flow table through the SDN controller to implement the target access service, and different execution results are returned according to the service sending result.

[0176] S216: Return that the service has been successfully issued and end the process.

[0177] It should be noted that, when the service is successfully issued, a message "service is successfully issued" is returned and the process ends.

[0178] S217: Returning the business failed, notifying the rollback.

[0179] It should be noted that, in the case of a failure in delivering a service, a message "failed to deliver the service" is returned, and the service is notified to roll back.

[0180] S218: Notify the cloud platform that the operation and maintenance service has failed to be delivered and needs to be handled manually.

[0181] It should be noted that in the event of a business failure, the operation and maintenance personnel need to be notified to handle the issue.

[0182] In summary, the embodiments of the present application relate to the fields of cloud computing, SDN, OpenStack (a project in a cloud computing system), and data center networks. Specifically, it is an automated network policy configuration solution based on an SDN network, which realizes the interconnection between the SDN Overlay network and the Underlay network in the resource pool, and the network policies between tenants are isolated from each other.

[0183] That is to say, the technical solution of the embodiment of the present application is a complete orchestration technology based on SDN two-layer NAT; wherein, the orchestration technology can map the Overlay IP address of the virtual device to a unique Underlay IP; and the orchestration technology can also configure the ACL policy for the virtual device to access the specified Underlay service; and in the orchestration technology, its northbound is open to cloud tenants, and cloud tenants can automatically implement the above configuration functions through the northbound interface. In this way, through the orchestration technology, the cloud tenant's VM can be connected to the specified Underlay IP at the network policy level, and isolated from other VMs and other Underlay IPs.

[0184] In this way, through the SDN orchestrator and SDN controller, by automatically configuring network policies for virtual devices, the network policy automation configuration of virtual devices in the resource pool to access business services in the Underlay network is realized, and the business configuration is flexible and the business between tenants is isolated. Specifically, for the technical solution of the embodiment of the present application, on the one hand, there is no need to add additional east-west aggregation switches, which reduces the cost of hardware equipment; on the other hand, cloud tenants do not need to create additional east-west network cards, which improves user experience and avoids consuming server resources; on the other hand, through the SDN orchestrator and SDN controller, network policies can be automatically configured and issued, cloud tenants can order independently, and activation can be achieved in seconds; on the other hand, network policies between cloud tenants are isolated from each other, and the security of business access is greatly improved.

[0185] Through the above embodiments, the specific implementation method of the aforementioned embodiments is explained in detail, from which it can be seen that by mapping the Overlay network address to the Underlay network address, the mutual access between the Overlay network and the Underlay network is flexibly achieved, thereby improving the convenience and security of accessing services.

[0186] In yet another embodiment of the present application, see Figure 5 , which shows a schematic diagram of the composition structure of a service access device 30 provided in an embodiment of the present application. Figure 5 As shown, the service access device 30 is applied to a service access system, and the service access system includes an Overlay network and an Underlay network. The service access device 30 includes a determining unit 301, a mapping unit 302 and a configuring unit 303, wherein:

[0187] The determining unit 301 is configured to determine configuration parameters of a target access service, wherein the configuration parameters include an Overlay network address;

[0188] A mapping unit 302 is configured to determine an Underlay network address from a preset Underlay network address resource pool, and form a mapping relationship between the Overlay network address and the Underlay network address;

[0189] The configuration unit 303 is configured to perform access policy configuration processing on the target access service based on the mapping relationship between the Overlay network address and the Underlay network address to determine the target access policy; wherein the target access policy is used to implement the target access service through the Overlay network and the Underlay network.

[0190] In some embodiments, the service access system further includes an orchestrator; accordingly, the determining unit 301 is further configured to receive a service access request through a northbound interface of the orchestrator; and determine configuration parameters of the target access service according to the service access request.

[0191] In some embodiments, the determination unit 301 is further configured to perform authority authentication on the target access service; if the authority authentication is successful, determine whether the target access service satisfies the quota management rules; if the target access service satisfies the quota management rules, determine whether there is a policy group corresponding to the target access request in the service access system; if there is a policy group corresponding to the target access request in the service access system, determine whether the format of the configuration parameter is correct; if the format of the configuration parameter is correct, execute the step of determining the Underlay network address from the preset Underlay network address resource pool.

[0192] In some embodiments, the mapping unit 302 is further configured to randomly select from a preset Underlay network address resource pool to obtain an Underlay network address.

[0193] In some embodiments, correspondingly, the mapping unit 302 is further configured to determine a service scenario corresponding to the target access service according to the configuration parameters; and determine the Underlay network address from a preset Underlay network address resource pool based on the service scenario.

[0194] In some embodiments, the preset Underlay network address resource pool includes a first Underlay network address resource pool, and the mapping unit 302 is further configured to determine the Underlay network address from the first Underlay network address resource pool when the business scenario is a business scenario in which the Overlay network unidirectionally accesses the Underlay network; wherein each Underlay network address in the first Underlay network address resource pool is used to form a mapping relationship with a plurality of Overlay network addresses.

[0195] In some embodiments, the preset Underlay network address resource pool also includes a second Underlay network address resource pool; accordingly, the mapping unit 302 is further configured to determine the Underlay network address from the second Underlay network address resource pool when the business scenario is unidirectional access to the Overlay network by the Underlay network, or bidirectional access to the Overlay network by the Underlay network; wherein each Underlay network address in the second Underlay network address resource pool is only used to form a mapping relationship with one Overlay network address.

[0196] In some embodiments, the Overlay network address includes a requesting-end Overlay network address and a destination Overlay network address; accordingly, the mapping unit 302 is further configured to, when the business scenario is a unidirectional access to the Overlay network by the Overlay network, determine a first Underlay network address from a first Underlay network address resource pool, and the first Underlay network address is used to form a mapping relationship with the requesting-end Overlay; determine a second Underlay network address from a second preset Underlay network address resource pool, and the second Underlay network address is used to form a mapping relationship with the destination Overlay.

[0197] In some embodiments, the target access policy includes access control list (ACL) parameters; wherein the ACL parameters include at least one of the following: source IP address, destination IP address, source port and destination port, and protocol number.

[0198] Furthermore, the service access system also includes a controller and a preset access control list; accordingly, the configuration unit 303 is also configured to send the target access policy to the controller through the orchestrator, and send the target access policy to the preset access control list through the controller to achieve the target access service through the Overlay network and the Underlay network.

[0199] It can be understood that in this embodiment, a "unit" can be a part of a circuit, a part of a processor, a part of a program or software, etc., and of course it can also be a module, or it can be non-modular. Moreover, the components in this embodiment can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional module.

[0200] If the integrated unit is implemented in the form of a software function module and is not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment is essentially or the part that contributes to the prior art or the whole or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) or a processor to perform all or part of the steps of the method of this embodiment. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc., various media that can store program codes.

[0201] Therefore, this embodiment provides a computer storage medium, which stores a computer program. When the computer program is executed by multiple processors, the steps of the method in any one of the above embodiments are implemented.

[0202] Based on the composition of the service access device 30 and the computer storage medium, see Figure 6 , which shows a hardware structure diagram of an electronic device 40 provided in an embodiment of the present application. Figure 6 As shown, the electronic device 40 may include: a communication interface 401, a memory 402 and a processor 403; each component is coupled together via a bus device 404. It is understood that the bus device 404 is used to realize the connection and communication between these components. In addition to the data bus, the bus device 404 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Figure 6 Various buses are labeled as bus devices 404. Among them, the communication interface 401 is used to receive and send signals during the process of sending and receiving information between other external network elements;

[0203] Memory 402, used to store computer programs that can be run on processor 403;

[0204] The processor 403 is used to execute, when running the computer program:

[0205] Determine the configuration parameters of the target access service, and the configuration parameters include the Overlay network address;

[0206] Determine the Underlay network address from the preset Underlay network address resource pool, and form a mapping relationship between the Overlay network address and the Underlay network address;

[0207] Based on the mapping relationship between the Overlay network address and the Underlay network address, the target access service is configured with an access policy to determine the target access policy; wherein the target access policy is used to implement the target access service through the Overlay network and the Underlay network.

[0208] It can be understood that the memory 402 in the embodiment of the present application can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM) and direct memory bus random access memory (DRRAM). The memory 402 of the apparatus and method described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0209] The processor 403 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit or software instructions in the processor 403. The above processor 403 may be a general processor, a digital signal processor (Digital Signal Processor, DSP), an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), a field programmable gate array (Field Programmable Gate Array, FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in the embodiments of the present application can be directly embodied as a hardware decoding processor to be executed, or the hardware and software modules in the decoding processor are combined and executed. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 402, and the processor 403 reads the information in the memory 402 and completes the steps of the above method in combination with its hardware.

[0210] It is understood that the embodiments described in the present application can be implemented by hardware, software, firmware, middleware, microcode or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions of the present application or a combination thereof.

[0211] For software implementation, the technology of the present application can be implemented by a module (e.g., a process, a function, etc.) that performs the functions of the present application. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or outside the processor.

[0212] Optionally, as another embodiment, the processor 403 is further configured to execute the steps of the method in any one of the aforementioned embodiments when running the computer program.

[0213] In yet another embodiment of the present application, based on the composition diagram of the service access device 30, see Figure 7 , which shows a schematic diagram of the composition structure of another electronic device 40 provided in an embodiment of the present application. Figure 7 As shown, the electronic device 40 at least includes the service access device 30 of any one of the aforementioned embodiments.

[0214] For the electronic device 40, since it includes the service access device 30, and the service access device 30 realizes mutual access between the Overlay network and the Underlay network by mapping the Overlay network address to the Underlay network address, and realizes the connection between the cloud tenants in the Overlay network and the business system of the Underlay network at the network policy level, thereby improving the flexibility and convenience of business configuration; at the same time, business access can be realized through the configuration of the network policy layer, ensuring the isolation of cloud tenants from other cloud tenants and other Underlay network nodes, thereby improving the security of the overall network.

[0215] The above are only preferred embodiments of the present application and are not intended to limit the protection scope of the present application.

[0216] It should be noted that, in this application, the terms "include", "comprises" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "includes a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0217] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0218] The methods disclosed in several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0219] The features disclosed in several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0220] The features disclosed in several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

[0221] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A service access method, characterized in that: Applied to a service access system, the service access system adopts an SDN architecture, and the service access system includes an Overlay network and an Underlay network, and the method includes: Determine the configuration parameters of the target access service, wherein the configuration parameters include the Overlay network address; Determine an Underlay network address from a preset Underlay network address resource pool, and form a mapping relationship between the Overlay network address and the Underlay network address; Based on the mapping relationship between the Overlay network address and the Underlay network address, the target access service is subjected to access policy configuration processing to determine the target access policy; wherein the target access policy is used to implement the target access service through the Overlay network and the Underlay network; wherein determining the Underlay network address from a preset Underlay network address resource pool includes: Determining, according to the configuration parameters, a business scenario corresponding to the target access service; Based on the service scenario, the Underlay network address is determined from the preset Underlay network address resource pool.

2. The service access method according to claim 1, characterized in that: The service access system also includes an orchestrator; the configuration parameters of the target access service are determined, including: receiving a service access request through a northbound interface of the orchestrator; Determine configuration parameters of the target access service according to the service access request.

3. The service access method according to claim 1, characterized in that: After determining the configuration parameters of the target access service, the method further includes: Performing authority authentication on the target access service; If the authority authentication is successful, determining whether the target access service satisfies the quota management rules; In the case where the target access service satisfies the quota management rule, determining whether there is a policy group corresponding to the target access service in the service access system; In the case where a policy group corresponding to the target access service exists in the service access system, determining whether the format of the configuration parameter is correct; When the format of the configuration parameter is correct, the step of determining the Underlay network address from the preset Underlay network address resource pool is performed.

4. The service access method according to claim 1, characterized in that: The determining of the Underlay network address from a preset Underlay network address resource pool includes: The Underlay network address is obtained by randomly selecting from the preset Underlay network address resource pool.

5. The service access method according to claim 1, characterized in that: The preset Underlay network address resource pool includes a first Underlay network address resource pool; Correspondingly, the determining the Underlay network address from the preset Underlay network address resource pool based on the service scenario further includes: In a case where the service scenario is that the Overlay network unidirectionally accesses the Underlay network, determining the Underlay network address from the first Underlay network address resource pool; Each Underlay network address in the first Underlay network address resource pool is used to form a mapping relationship with a plurality of Overlay network addresses.

6. The service access method according to claim 5, characterized in that: The preset Underlay network address resource pool also includes a second Underlay network address resource pool; Correspondingly, the determining the Underlay network address from a preset Underlay network address resource pool based on the service scenario further includes: In a case where the service scenario is that the Underlay network unidirectionally accesses the Overlay network, or the Underlay network bidirectionally accesses the Overlay network, determining the Underlay network address in the second Underlay network address resource pool; Each Underlay network address in the second Underlay network address resource pool is used to form a mapping relationship with an Overlay network address.

7. The service access method according to claim 6, characterized in that: The Overlay network address includes the request end Overlay network address and the destination end Overlay network address; Accordingly, the determining the Underlay network address from a preset Underlay network address resource pool based on the service scenario further includes: In the case where the service scenario is unidirectional access to the Overlay network by the Overlay network, determining a first Underlay network address from the first Underlay network address resource pool, and the first Underlay network address is used to form a mapping relationship with the request end Overlay network address; and A second Underlay network address is determined from the second Underlay network address resource pool, and the second Underlay network address is used to form a mapping relationship with the destination Overlay network address.

8. The service access method according to any one of claims 1 to 7, characterized in that: The target access policy includes access control list (ACL) parameters; wherein the ACL parameters include at least one of the following: source IP address, destination IP address, source port, destination port and protocol number.

9. The service access method according to claim 2, characterized in that: The service access system further includes a controller and a preset access control list; after determining the target access strategy, the method further includes: The target access policy is sent to the controller through the orchestrator, and the target access policy is sent to the preset access control list through the controller, so as to realize the target access service through the Overlay network and the Underlay network.

10. A service access device, characterized in that: Applied to a service access system, the service access system adopts an SDN architecture, and the service access system includes an Overlay network and an Underlay network, and the service access device includes a determination unit, a mapping unit and a configuration unit; wherein, The determining unit is configured to determine configuration parameters of the target access service; wherein the configuration parameters include an Overlay network address; The mapping unit is configured to determine an Underlay network address from a preset Underlay network address resource pool, and map the Overlay network address to the Underlay network address; The configuration unit is configured to perform access policy configuration processing on the target access service based on the mapping relationship between the Overlay network address and the Underlay network address to determine the target access policy; wherein the target access policy is used to implement the target access service through the Overlay network and the Underlay network; The mapping unit is configured to determine the business scenario corresponding to the target access service according to the configuration parameters; Based on the service scenario, the Underlay network address is determined from the preset Underlay network address resource pool.

11. An electronic device, characterized in that: The electronic device comprises a memory and a processor; wherein, The memory is used to store a computer program that can be run on the processor; The processor is configured to execute the steps of the method according to any one of claims 1 to 9 when running the computer program.

12. A computer storage medium, characterized in that: The computer storage medium stores a computer program, and when the computer program is executed, the steps of the method according to any one of claims 1 to 9 are implemented.

Images