Data access method and device in multi-tenant environment, equipment and storage medium

Abstract

The invention discloses a data access method and device in a multi-tenant environment, equipment and a storage medium, and belongs to the technical field of computer networks. The method comprises the following steps: acquiring configuration information of message-oriented middleware from custom resources; the custom resource is a data source instance for defining the message middleware in the function service platform; the configuration information comprises a tenant identifier; allocating a virtual address to a real address of the message-oriented middleware according to the tenant identifier to obtain address mapping information; the address mapping information comprises tenant identifiers of different message middleware and a mapping relationship between the tenant identifiers and virtual addresses, and different tenant identifiers correspond to different virtual addresses; and in response to a data access request of a tenant, forwarding the data access request through the cross-private cloud channel according to the address mapping information, so as to realize cross-private cloud access of the tenant to the message-oriented middleware. According to the method and the device, the problems of communication failure, data isolation failure and the like caused by possible conflicts of internet protocol addresses in a multi-tenant environment can be solved.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of computer networks, and particularly relates to a data access method and device in a multi-tenant environment, equipment and a storage medium. BACKGROUND

[0002] With the explosive growth of virtual cloud services, people have higher and higher requirements for the data security strategy of service providers. Each tenant hopes that its own data can be isolated from other tenants in a virtual private cloud (VPC), and build a secure, reliable, configurable and manageable virtual network environment to prevent data leakage risks. At the same time, in the cloud native architecture, computing resources and storage resources are split into different VPCs. In the scenario where the client and the server in communication are not in the same VPC network, additional network technology is needed to realize communication, that is, the networks between the VPCs of different tenants need to be interconnected to realize cross-VPC data access.

[0003] However, since the tenant VPCs are independent of each other, the same service of different tenants may be configured with the same Internet Protocol (IP) address, which may cause IP address conflicts and further cause communication failure, data isolation failure and other problems. SUMMARY

[0004] The purpose of the embodiments of the present application is to provide a data access method, device, equipment and storage medium in a multi-tenant environment, which can solve the problem of IP address conflicts in a multi-tenant environment, and further cause communication failure, data isolation failure and other problems.

[0005] To solve the above technical problems, the present application is implemented as follows: In a first aspect, the embodiments of the present application provide a data access method in a multi-tenant environment, which comprises: obtaining configuration information of a message middleware from a custom resource; the custom resource is a data source instance of the message middleware defined in a function service platform; the configuration information comprises a tenant identifier; allocating a virtual address for a real address of the message middleware according to the tenant identifier, to obtain address mapping information; the address mapping information comprises tenant identifiers of different message middlewares and a mapping relationship between the tenant identifiers and the virtual addresses, and different tenant identifiers correspond to different virtual addresses; In response to a data access request of a tenant, forwarding the data access request through a cross-private cloud channel according to the address mapping information, to realize cross-private cloud access of the tenant to the message middleware.

[0006] Secondly, embodiments of this application provide a data access device in a multi-tenant environment, the device comprising: The configuration acquisition module is used to obtain the configuration information of the message middleware from a custom resource; the custom resource is a data source instance that defines the message middleware in the function service platform; the configuration information includes a tenant identifier; The address allocation module is used to allocate a virtual address to the real address of the message middleware according to the tenant identifier, and obtain address mapping information; the address mapping information includes the tenant identifiers of different message middlewares and the mapping relationship between the tenant identifiers and the virtual addresses, with different tenant identifiers corresponding to different virtual addresses; The cross-cloud access module is used to respond to a tenant's data access request by forwarding the data access request through a cross-private cloud channel based on the address mapping information, so as to enable the tenant to access the message middleware across private clouds.

[0007] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0008] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0009] In this embodiment, in a multi-tenant environment with cross-private cloud access, a dedicated virtual address is assigned to each tenant's real address. By isolating traffic from different tenants through virtual address ranges, address conflicts can be avoided, resolving communication failures and data isolation failures caused by address conflicts. Furthermore, tenants can configure the message middleware through custom resources on the function service platform, eliminating the need for manual configuration of cross-private cloud channels or modification of existing message middleware, thus reducing access costs. Attached Figure Description

[0010] Figure 1 This is a flowchart of a data access method in a multi-tenant environment provided in an embodiment of this application.

[0011] Figure 2 This is a flowchart illustrating the specific steps of a data access method in a multi-tenant environment provided in this application embodiment.

[0012] Figure 3 This is a schematic diagram of a data access process in a multi-tenant environment provided in an embodiment of this application.

[0013] Figure 4 This is a block diagram of a data access device in a multi-tenant environment provided in an embodiment of this application.

[0014] Figure 5 This is a block diagram of an electronic device provided in an embodiment of this application.

[0015] Figure 6 This is a block diagram of another electronic device provided in the embodiments of this application. Detailed Implementation

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

[0017] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0018] Serverless Cloud Function (SCF) is a serverless computing service that allows developers to run code without managing servers. Developers only need to write the core code and set the trigger conditions, and the cloud function can be executed elastically and securely in the cloud.

[0019] In cloud function computing scenarios, the function computing service deploys its workloads and provides services based on an open-source container orchestration system (Kubernetes) cluster. Kubernetes, or K8s for short, is an open-source system used to manage containerized applications across multiple hosts on a cloud platform. The function computing cluster resides within an independent VPC. Furthermore, in cloud-native architectures, compute and storage resources are split across different VPCs. When the client and server are not on the same VPC network, additional network technologies are needed for communication. This means interconnecting the networks of different tenant VPCs to enable cross-VPC data access. The function cluster VPC needs to establish connections with multiple tenant VPCs to ensure functions can access private resources within each tenant. Functions from different tenants also run within the function cluster and need to access other resources within their respective tenant VPCs, such as Kafka, RocketMQ, and databases. Therefore, the VPC network hosting the function cluster must be able to access the tenant VPC networks simultaneously, making the function cluster network inherently a multi-tenant network environment.

[0020] Taking accessing Kafka services as an example, Function Compute's Kafka trigger functionality is used to trigger the execution of associated functions. These functions allow for customized processing of messages published to Kafka triggers. This Kafka trigger functionality requires subscribing to Kafka topics within each tenant's VPC and consuming their messages before passing them to the tenant's function. However, since tenant VPCs are independent, different tenants' Kafka services may be configured with the same IP address, potentially leading to IP address conflicts and indistinguishability. For example, if tenant A and tenant B's Kafka store-and-forward nodes (brokers) both use the IP address 192.168.1.100, when a function attempts to access 192.168.1.100, the network layer cannot determine whether to route to tenant A's or tenant B's VPC. This could result in connection timeouts or rejections, messages being sent to the wrong tenant, or tenant A's function potentially consuming messages from tenant B.

[0021] Furthermore, distributed message queue systems like Kafka need to handle a large amount of node coordination, metadata management, and partition load balancing. In other words, a centralized service is needed to handle these complexities. Therefore, in scenarios such as scaling up and down the target Kafka, load balancing, and fault migration, the IP address of the actual message storage and forwarding node (broker) consumed by the client is not the same as the IP address of the centralized metadata service (ZooKeeper) of the centralized service. The problem of IP address conflict cannot be solved by a fixed mapping relationship.

[0022] To address the aforementioned issues, this application provides a data access method, apparatus, device, and storage medium in a multi-tenant environment. The data access method in a multi-tenant environment provided by this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0023] Figure 1 This is a flowchart of a data access method in a multi-tenant environment provided in an embodiment of this application. See also... Figure 1 The method includes the following steps.

[0024] Step 101: Obtain the configuration information of the message middleware from the custom resources.

[0025] In this embodiment of the application, the Custom Resource Definition (CRD) is a data source instance that defines the message middleware in the function service platform.

[0026] In practical applications, operations and maintenance developers can use CRDs to define the application programming interface (API) resources they need to configure the message middleware.

[0027] In some embodiments, the message middleware is a distributed message middleware, such as Kafka, RocketMQ, etc.; custom resources include KafkaSourceCRD, RocketMQCRD, etc.

[0028] In some embodiments, custom resources are used to describe the configuration information of the message middleware. For example, if the message middleware is Kafka, KafkasourceCRD is obtained by encapsulating the connection information of the Kafka service, Topic subscription rules, etc. into Kubernetes, and is used to create, modify, and delete it via kubectl or the Kubernetes API.

[0029] In some embodiments, configuration information may include a Virtual Private Cloud Identity document (VPC ID), a Subnet Identity document (SubnetID), an Additional Access IP (IPS) list, and a Tenant ID. The VPC ID represents the tenant's unique VPC identifier; the Subnet ID represents the unique identifier of a subnet, which is a subdivided network unit within a VPC and belongs to a subset of the VPC; and the Additional Access IP list represents the set of IP addresses for accessing the core node across VPCs.

[0030] Understandably, when Function Compute accesses a tenant's message middleware, it first locates the tenant's private network using the VPC ID, then narrows it down to the specific subnet using the Subnet ID, and finally locks the node to be accessed using the IPS.

[0031] It should be noted that the execution entity of the data access method in a multi-tenant environment provided in this application embodiment can be a function service platform, a computing cluster on the function service platform, or a specific component in the function service platform.

[0032] In some embodiments, the function service platform may be a cloud function platform where the Kubernetes cluster resides. For example, the function service platform may be a Function as a Service (FaaS) platform.

[0033] Step 102: Assign a virtual address based on the tenant identifier as the real address of the message middleware to obtain address mapping information.

[0034] In this embodiment, the address mapping information includes tenant identifiers of different message middleware and the mapping relationship between tenant identifiers and virtual addresses. Different tenant identifiers correspond to different virtual addresses; that is, each tenant identifier corresponds to a unique virtual address.

[0035] In some embodiments, the real address of the message middleware is included in the configuration information, which contains the unique identifier (ID) of the message middleware. Based on the unique identifier (ID), a corresponding virtual address is assigned to the message middleware to obtain address mapping information.

[0036] In some embodiments, the address mapping information may also include the actual address of the message middleware.

[0037] For example, both tenant A and tenant B's Kafka Brokers use 192.168.1.100. A unique FakeIP is assigned to each tenant A's and tenant B's Kafka services. Tenant A's Kafka FakeIP is 10.20.0.1, and tenant B's Kafka FakeIP is 10.20.0.2. The mapping relationship between the Fake IP, the real IP, and the tenant identifier is stored. When a function accesses Kafka through the Fake IP, the network proxy forwards the traffic to the target tenant's VPC according to the mapping rules.

[0038] In this embodiment of the application, the real address of the message middleware refers to the real IP address, and the virtual address is the fake IP address.

[0039] It should be noted that a virtual address is not a real IP address that is routed on the public network or physical network; it is an address that is only meaningful within the Function Compute cluster.

[0040] In some embodiments, address mapping information is stored in a preset storage medium, which may be a distributed key-value database or an annotation field of a function container. For example, address mapping information is stored in a ConfigMap of the Kubernetes cluster, where ConfigMap is an API object that container groups (Pods) can use as environment variables, command-line arguments, or configuration files in storage volumes.

[0041] In some embodiments, the function service platform calls the Get Fake IP interface of the address management service (faas-ipam) to assign unique virtual addresses to the IPs corresponding to the initial bootstrap server list (BootstrapServers) for Kafka clients connecting to the cluster, and to the centralized metadata service (zookeeper) of the centralized service. Here, BootstrapServers is the bootstrap address list of the store-and-forward nodes (Broker), and includes one or more Broker IP addresses.

[0042] For example, assign FakeIP10.0.0.1 to tenant A's real Kafka IP 192.168.1.100 and FakeIP10.0.0.2 to ZooKeeper IP 192.168.1.101; call faas-ipam to store the mapping relationship between FakeIP and real IP in etcd or Redis, and record the tenant identifier to ensure isolation.

[0043] Step 103: In response to the tenant's data access request, the data access request is forwarded through the cross-private cloud channel based on the address mapping information to enable the tenant to access the message middleware across private clouds.

[0044] In this embodiment, the tenant's data access request is used to send data generated by the message middleware cluster within the tenant's VPC to the function service platform, so that the data can be processed by functions on the function service platform.

[0045] In some embodiments, after a tenant's message middleware trigger is started, it sends a data access request to the function service platform according to the configured virtual address.

[0046] In some embodiments, a tenant's data access request includes a Kafka service access request or a RocketMQ service access request. For example, a tenant's data access request may be a data pull request initiated by a Kafka trigger within the tenant to the Kafka cluster.

[0047] In some embodiments, in response to a data access request, the real address corresponding to the data access request is obtained based on the virtual address and address mapping information; the data access request is forwarded to the real address through a cross-private cloud channel to enable tenants to access the message middleware across private clouds.

[0048] In summary, in this embodiment of the application, in a multi-tenant environment with cross-private cloud access, assigning a dedicated virtual address to each tenant's real address and isolating traffic from different tenants through virtual address segments avoids address conflicts and solves problems such as communication failures and data isolation failures caused by address conflicts. Furthermore, tenants can configure the message middleware through custom resources on the function service platform, eliminating the need for manual configuration of cross-private cloud channels or modification of existing message middleware, thus reducing access costs.

[0049] Figure 2 This is a flowchart illustrating the specific steps of a data access method in a multi-tenant environment provided in this application embodiment. See also... Figure 2 The method includes the following steps.

[0050] Step 201: In response to the function service platform listening for the change event of the custom resource, obtain the configuration parameters of the message middleware after the change.

[0051] In this embodiment of the application, the change event of the custom resource may include the creation event, modification event or deletion event of the custom resource.

[0052] For example, a user creates a custom KafkaSource resource, configuring key information including: the tenant's actual BootstrapServers for Kafka, VPCID, SubnetID, ZooKeepe, and additional Broker IPs. The FaaS platform listens for the KafkaSource creation event through Informer to obtain the above configuration.

[0053] In some embodiments, Informer listens for events and retrieves the complete object data of a new KafkaSource when it is created or updated. The object data is parsed to extract target information and obtain the changed configuration parameters. In this way, Informer continuously listens to the Kubernetes API Server, and when a custom resource is created, updated, or deleted, it receives an immediate notification and triggers the corresponding event handling function. This avoids the inefficient method of polling the API Server, making the entire system real-time and efficient.

[0054] For example, when a new KafkaSource is created or updated, a Go struct is used to map the KafkaSource's YAML / JSON structure, and then the struct's fields are accessed directly to obtain the vpcspec and bootstrapServers.

[0055] In some embodiments, the extracted target information is assembled into a new configuration format and then updated on the target resource. The new configuration format includes a JSON string, and the target resource includes annotations for the function's Pod or Deployment.

[0056] Step 202: Encapsulate the changed configuration parameters as annotation fields of a function container and update them in the function container of the message trigger of the message middleware.

[0057] In some embodiments, the message trigger of the message middleware can be a Kafka trigger or a RocketMQ trigger.

[0058] In some embodiments, the annotation field of a function container can be PodAnnotation.

[0059] For example, the annotation field of the encapsulated function container could be `infra.faas.ctyun.cn / ip-mapping:'[{"fake_ip":"10.0.0.1","real_ip":"192.168.1.100","vpc_connection_id":"xxx"}]'`, indicating that when the function container attempts to access the address 10.0.0.1, it should forward the request to 192.168.1.100 and use the cross-VPC channel 'xxx' to complete the forwarding. The FaaS platform writes this annotation field into the PodAnnotation of the function corresponding to the Kafka trigger. In this way, the function Pod itself is unaware of the existence of the custom resource; it only needs to read its own annotation to obtain the cluster's network configuration. Furthermore, the configuration is not hardcoded when the Pod starts but can be dynamically updated during Pod runtime, improving the flexibility of configuration parameters.

[0060] In some embodiments, all the network context required for cross-VPC access can be configured via custom resources to enable cross-VPC access.

[0061] The above technical solution allocates a dedicated virtual address pool to each tenant, isolating the address spaces of different tenants and preventing IP conflicts that could occur when message middleware from different tenants uses the same private IP network segment for direct cross-cloud access. Furthermore, when the platform needs to support new types of message middleware, it only needs to identify the storage-forwarding nodes and metadata nodes of the new middleware, without modifying the address pool allocation and virtual address allocation logic; when adding a new tenant, it only needs to allocate a new dedicated address pool for the new tenant, without reconstructing the overall architecture, demonstrating extremely high scalability.

[0062] Step 203: Obtain the configuration information of the message middleware from the custom resources.

[0063] The method for this step has been explained in step 101 above, and will not be repeated here.

[0064] Step 204: Determine the virtual address pool of the message middleware based on the tenant identifier.

[0065] In this embodiment, the virtual address pool is a dedicated address range corresponding to the tenant identifier within the function service platform. All virtual addresses allocated to the Kafka cluster of the tenant corresponding to the tenant identifier must be selected from this dedicated address range.

[0066] In some embodiments, the function service platform allocates exclusive virtual address ranges as virtual address pools for different tenants. For example, tenant A's address pool is 172.16.0.0 / 24, tenant B's address pool is 172.16.1.0 / 24, and tenant C's address pool is 172.16.2.0 / 24. The platform can query the corresponding virtual address pool of 172.16.1.0 / 24 through the tenant identifier.

[0067] For example, the platform controller sends a virtual address pool query request to the address management service. In response to the virtual address pool query request, the address management service queries and returns the result based on a mapping table between tenant identifiers and virtual address pools that it maintains.

[0068] Step 205: Call the first data interface of the address management service to allocate a corresponding virtual address for each real address of the message middleware in the virtual address pool.

[0069] In this embodiment, the real address includes the storage and forwarding node address of the message middleware and the metadata service node address.

[0070] In this embodiment of the application, faas-ipam is a deployment type workload, mainly responsible for the allocation and management of virtual IPs, and provides Get Fake IP and Release Fake IP interfaces as an HTTP service.

[0071] In some embodiments, it is not necessary to assign a corresponding virtual address to each real address of the message middleware. Instead, the first data interface is called to assign a corresponding virtual address only to the service to be accessed, thus obtaining the mapping relationship. The service to be accessed may include Kafka, RocketMQ, etc.

[0072] In one possible implementation, the first data interface is called to obtain the unique identifier (ID) of the Kafka instance, and a corresponding virtual address is assigned to the unique identifier to obtain the mapping relationship. For example, the identifier (ID) may include the tenant's ID, the KafkaSource's ID, a function's ID, etc.

[0073] In some embodiments, the first data interface may be the GetFakeIP interface of faas-ipam. The GetFakeIP interface is idempotent, meaning that the result is the same regardless of how many operations are performed.

[0074] In some embodiments, the address management service processes the list of real addresses of the message middleware in a loop. For each real address, an address allocation operation is performed once.

[0075] Step 206: Generate address mapping information based on the tenant identifier, the real address, and the mapping relationship between the tenant identifier and the virtual address.

[0076] In some embodiments, the address mapping information includes a tenant identifier, a physical address, and the correspondence between the tenant identifier and the three.

[0077] In some embodiments, address mapping information is stored in a distributed key-value database or an annotation field of a function container. For example, address mapping information is stored in a ConfigMap of a Kubernetes cluster.

[0078] In some embodiments, after step 206, the data access method in a multi-tenant environment described above may further include: Sub-step A1: If the custom resource is deleted, call the second data interface of the address management service to delete the address mapping information; Sub-step A2 releases the virtual addresses included in the address mapping information back to the virtual address pool.

[0079] In one possible implementation, when the message middleware trigger is not needed, the deletion operation is performed on the custom resource on the function service platform.

[0080] In one possible implementation, a controller in a function service platform is used to listen for changes in custom resources.

[0081] In one possible implementation, the second data interface could be the faas-ipam Release Fake IP interface. Calling the second data interface deletes the address mapping information and notifies the address management service to reclaim all virtual addresses associated with the address mapping information. After deleting or marking the mapping relationship, the address management service releases all virtual addresses associated with the address mapping information back to their respective address pools so that they can be reassigned to other real addresses in the future.

[0082] In one possible implementation, after sub-step A2, the data access method in the multi-tenant environment described above may further include: the address management service updates the status of the address pool, changing the status of all virtual addresses associated with the address mapping information from Allocated to Available.

[0083] The above technical solution employs an automated virtual address recycling mechanism, ensuring the efficient recycling of virtual address resources, avoiding the waste of virtual addresses, and also guaranteeing that the virtual addresses occupied by a custom resource will not conflict with newly created custom resources after the custom resource is deleted.

[0084] Step 207: In response to the data access request, determine the tenant identity credentials and virtual address carried in the data access request.

[0085] In some embodiments, in response to a data access request, the tenant identity credentials and virtual address carried in the data access request are determined.

[0086] In some embodiments, after a tenant's message middleware trigger starts, it sends a data access request to the function service platform based on the configured virtual address. For example, a tenant's data access request may be a data pull request initiated by a Kafka trigger within the tenant to the Kafka cluster.

[0087] In some embodiments, the tenant identity credentials and virtual address carried in the data access request are extracted through the gateway or trigger of the function service platform. The tenant identity credentials are the authentication token (JWT Token) injected from the platform when the trigger is started, and the virtual address represents the destination address of the request.

[0088] Step 208: If the consistency verification between the tenant identity credentials and the tenant identifier in the configuration information passes, obtain the real address corresponding to the data access request based on the virtual address and address mapping information.

[0089] In some embodiments, the tenant identity credential (JWT Token) is parsed to extract the bound tenant identifier; the configuration information corresponding to the tenant is queried from the custom resource, and the tenant identifier in the tenant identity credential is compared with the tenant identifier in the configuration information; if they match, the consistency check is passed; if they do not match, the data access request is rejected and an insufficient permission message is returned to the tenant.

[0090] In some embodiments, if the consistency verification between the tenant identity credential and the tenant identifier in the configuration information passes, the stored address mapping information is matched with the virtual address as the retrieval condition to obtain the real address and tenant identifier corresponding to the data access request.

[0091] In some embodiments, if a unique corresponding real address is found, the cross-private cloud channel ID associated with the real address is obtained.

[0092] Step 209: Forward the data access request to the real address through the cross-private cloud channel to enable tenants to access the message middleware across private clouds.

[0093] Through the above technical solution, virtual addresses are associated with real addresses through mapping relationships, which solves the problem of IP conflicts among multi-tenants; for tenants, only virtual addresses need to be configured to achieve cross-cloud access, simplifying the data access process.

[0094] In some embodiments, step 209 may include: Sub-step 2091: Determine the private cloud parameter information associated with the real address based on the real address and tenant identifier; Sub-step 2092: Based on the private cloud parameter information, query the cross-private cloud channel configuration in the function service platform to obtain the private cloud connection identifier; Sub-step 2093: Generate forwarding rules based on the private cloud connection identifier, virtual address, and real address; Sub-step 2094: According to the forwarding rules, the data access request is forwarded to the message middleware node corresponding to the real address through the cross-private cloud channel.

[0095] In this embodiment, the private cloud connection identifier is the identifier used by the function service platform to configure a cross-private cloud channel for cross-cloud access of each private cloud.

[0096] In one possible implementation, the function service platform uses VPC peering connections to configure cross-private cloud channels and channel identifiers for each tenant's private cloud.

[0097] In one possible implementation, the function service platform stores a table linking tenant identifiers, real addresses, and private clouds for different tenants. This table records the binding relationship between each tenant's IP address and private cloud information. The linking table can be entered synchronously when a tenant creates a custom resource.

[0098] In one possible implementation, the system queries a related table using the real address and tenant identifier as search criteria to obtain private cloud parameter information. This private cloud parameter information includes the VPC ID, subnet ID, and security group ID.

[0099] In one possible implementation, the cross-cloud channel management module of the function service platform initiates a channel configuration query request based on the private cloud parameter information; matches the cross-private cloud channel configuration corresponding to the VPC ID, and extracts the private cloud connection identifier, which is the identifier of the peer connection channel between the tenant's private cloud and the platform's private cloud.

[0100] In this application embodiment, the forwarding rules include port forwarding rules or Destination Network Address Translation (DNAT) rules.

[0101] Understandably, the private cloud connection identifier is used to indicate the channel for traffic forwarding, the virtual address represents the source and destination addresses of the function request, and the real address represents the node address of the message middleware to be accessed.

[0102] In one possible implementation, sub-step 2094 may include: forwarding the data access request to the message middleware node corresponding to the real address via a cross-private cloud channel through a network coloring component, according to forwarding rules. The network coloring component, also known as a "cluster coloring component" or simply a "coloring component," includes network proxies, IPtables managers, etc.

[0103] For example, a data access request initiated by a function (destination address 10.0.3.20:9876) arrives at the platform network gateway and is intercepted by the network coloring component. The network coloring component loads DNAT forwarding rules, replacing the destination IP of the data access request from 10.0.3.20 to 192.168.5.20, while keeping the destination port unchanged at 9876. According to the channel configuration corresponding to the private cloud connection identifier, the request is sent through the cross-private cloud peering connection channel, enabling the data access request to cross the boundary between the platform VPC and the tenant's private cloud VPC, and finally arrive at the message broker node corresponding to the real address 192.168.5.20:9876.

[0104] In one possible implementation, after sub-step 2094, the data access method in the multi-tenant environment described above may further include: generating response data according to the data access request through a message middleware node; receiving the response data returned by the message middleware node and replacing the source address in the response data from the real address to the virtual address according to the address mapping information; and returning the response data to the tenant along the original channel through a coloring component.

[0105] In some embodiments, after step 209, the data access method in a multi-tenant environment described above may further include: Sub-step 209: Listen to the metadata of the message middleware through the message trigger of the message middleware; Sub-step 210: In the event that the real address of the metadata representation message middleware changes, the first data interface of the address management service is called to reallocate a new virtual address for the changed real address. Sub-step 211: Update the address mapping information and send the new virtual address to the message middleware.

[0106] In one possible implementation, when the message middleware is scaling up or down, load balancing, or failover, a change in the broker IP will also change the message middleware's metadata.

[0107] For example, when a new Broker node is added to a Kafka cluster, the node information, such as the new node's IP address, port, and partition allocation, is automatically updated in the metadata service (ZooKeeper), resulting in a change in the cluster metadata. Kafka triggers listen for these metadata changes and initiate a new request for a FakeIP. The FaaS platform updates the mapping configuration in PodAnnotations (infra.faas.ctyun.cn, ip-mapping), and the coloring component synchronously updates its forwarding rules. Functions can then access the changed Kafka node using the new FakeIP without needing to be restarted.

[0108] In one possible implementation, the annotation configuration of the function container is updated to inject new virtual address mapping information into the container for loading by the network coloring component.

[0109] In one possible implementation, a virtual address update notification is sent to the message middleware to configure the new virtual address into the cluster's list of client-accessible addresses, or to update the address configuration of the corresponding Broker in ZooKeeper.

[0110] In one possible implementation, the network coloring component listens for changes in container annotations and automatically generates new forwarding rules.

[0111] Through the above technical solutions, the monitoring of metadata can promptly detect changes in the real address, allocate a dedicated virtual address to the new real address, and ensure multi-tenant isolation. At the same time, by updating the mapping relationship and forwarding rules, the new address can be made available quickly, enabling the function service platform to seamlessly adapt to the dynamic changes of the message middleware without manual intervention, thus ensuring the high availability and stability of the service.

[0112] In summary, in this embodiment, firstly, the function Pod itself is unaware of the existence of custom resources and only needs to read its own annotations to obtain the cluster's network configuration; secondly, the configuration is not hard-coded when the Pod starts but can be dynamically updated during Pod runtime, improving the flexibility of configuration parameters; thirdly, a dedicated virtual address pool is allocated to each tenant, isolating the address spaces of different tenants and preventing message middleware from using the same private IP network segment, which could lead to IP conflicts when accessing directly across clouds; finally, by updating mapping relationships and forwarding rules, new addresses are made available quickly, enabling the function service platform to seamlessly adapt to the dynamic changes of message middleware without manual intervention, ensuring high availability and stability of the service.

[0113] Figure 3 This is a schematic diagram illustrating a data access process in a multi-tenant environment according to an embodiment of this application. See also... Figure 3This data access process is applied in a function service platform, which includes an open-source container orchestration system (Kubernetes) cluster. It uses triggers to implement the core process of tenants accessing the message middleware cluster across VPCs.

[0114] In some embodiments, the Address Management Service (IPAM) is responsible for assigning virtual addresses (FakeIPs) to tenants' Kafka real addresses and maintaining the mapping relationship between virtual addresses, real addresses, and tenants.

[0115] In some embodiments, a Custom Resource (CRD) is used by a tenant to declare the configuration information of its Kafka cluster and serves as the entry point for the platform to become aware of the tenant's Kafka resources.

[0116] In some embodiments, the trigger is a message middleware trigger container of the Function Compute platform, such as a Kafka trigger, which is responsible for listening to Kafka messages, triggering function execution, and updating the address mapping information between virtual addresses and real addresses through annotations.

[0117] In some embodiments, the coloring component is a network proxy or traffic forwarding component that generates cross-VPC forwarding rules based on the POD annotation configuration, forwarding traffic destined for virtual addresses to the real Kafka addresses within the tenant's VPC.

[0118] In some embodiments, the Kafka clusters of different tenants are deployed in their respective private VPCs, isolated from the Function Compute platform's VPC network. For example, KafkaA, KafkaB, and KafkaC are deployed on VPC1, VPC2, and VPC3, respectively.

[0119] In some embodiments, after the Kubernetes cluster detects the creation event of a KafkaSource, faas-ipam assigns a dedicated virtual address to the real address of the Kafka based on the tenant identifier. Faas-ipam then injects the mapping relationship between the virtual address, the real address, and the tenant into the Kafka trigger POD in the form of annotations. For example, infra.faas.ctyun.cn / ip-mapping: '[{"fake_ip":"10.0.0.1","real_ip":"192.168.1.100","vpc_id":"vpc-xxx"}]').

[0120] In some embodiments, the coloring component listens for annotation changes in Kafka trigger PODs, parses the virtual address mapping information, and generates cross-VPC forwarding rules. When a Kafka trigger needs to pull Kafka messages, it directly accesses the virtual address without needing to know the real address or cross-VPC details. The coloring component intercepts traffic destined for the virtual address, replaces the destination address with the real address according to the forwarding rules, and forwards the traffic to the Kafka cluster within the tenant VPC through the corresponding cross-VPC channel. The Kafka cluster receives the request and returns a message. After receiving the message, the Kafka trigger triggers the associated function to perform business processing.

[0121] The above technical solution uses IPAM service to assign a cluster-unique fake IP to the IPs of different VPCs, and then resolves the IP conflict problem between different VPCs through mapping. At the same time, in order to address the problem that fixed mapping cannot cope with dynamic changes in Kafka broker IPs, the trigger component additionally listens for changes in the metadata of the target instance to update the mapping in real time, thus solving the dynamic IP problem.

[0122] Figure 4 This is a block diagram of a data access device in a multi-tenant environment provided in an embodiment of this application, such as... Figure 4 As shown, the data access device 400 in this multi-tenant environment includes the following modules.

[0123] The configuration acquisition module 401 is used to obtain the configuration information of the message middleware from the custom resource; the custom resource is the data source instance that defines the message middleware in the function service platform; the configuration information includes the tenant identifier; Address allocation module 402 is used to allocate virtual addresses to the real addresses of message middleware based on tenant identifiers to obtain address mapping information; the address mapping information includes the tenant identifiers of different message middlewares and the mapping relationship between the tenant identifiers and virtual addresses, with different tenant identifiers corresponding to different virtual addresses; The cross-cloud access module 403 is used to respond to the tenant's data access request by forwarding the data access request through the cross-private cloud channel based on the address mapping information, so as to enable the tenant to access the message middleware across private clouds.

[0124] Optionally, the address mapping information also includes the actual address of the message middleware. The address allocation module 402 includes: The address pool determination submodule is used to determine the virtual address pool of the message middleware based on the tenant identifier; the virtual address pool is the exclusive address range corresponding to the tenant identifier within the function service platform; The address allocation submodule is used to call the first data interface of the address management service to allocate a corresponding virtual address to each real address of the message middleware in the virtual address pool; the real addresses include the store-and-forward node address and the metadata service node address of the message middleware. The information generation submodule is used to generate address mapping information based on the tenant identifier, the real address, and the mapping relationship between the tenant identifier and the virtual address.

[0125] Optionally, the data access device 400 also includes: The mapping deletion submodule is used to call the second data interface of the address management service to delete the address mapping information when a custom resource is deleted. The address release submodule is used to release the virtual addresses included in the address mapping information back to the virtual address pool.

[0126] Optional, cross-cloud access module 403 includes: The first determination submodule is used to determine the tenant identity credentials and virtual address carried in the data access request in response to the data access request. The second determination submodule is used to obtain the real address corresponding to the data access request based on the virtual address and address mapping information, provided that the consistency verification between the tenant identity credential and the tenant identifier in the configuration information passes. The data forwarding submodule is used to forward data access requests to the real address through a cross-private cloud channel, so as to enable tenants to access the message middleware across private clouds.

[0127] Optional, the data forwarding submodule includes: The first determining unit is used to determine the private cloud parameter information associated with the real address based on the real address and the tenant identifier; The second determining unit is used to query the cross-private cloud channel configuration in the function service platform based on the private cloud parameter information to obtain the private cloud connection identifier; the private cloud connection identifier is the identifier of the cross-private cloud channel configured by the function service platform for each private cloud cross-cloud access. The rule generation unit is used to generate forwarding rules based on the private cloud connection identifier, virtual address, and real address; the forwarding rules include port forwarding rules or destination address translation rules; The data forwarding unit is used to forward data access requests to the message middleware node corresponding to the real address through a cross-private cloud channel, according to the forwarding rules.

[0128] Optionally, the data access device 400 also includes: The listening module is used to listen to the metadata of the message middleware through the message trigger of the message middleware; The calling module is used to call the first data interface of the address management service to reallocate a new virtual address for the changed real address when the real address of the metadata representation message middleware changes. The first update module is used to update the address mapping information and send the new virtual address to the message middleware.

[0129] Optionally, the data access device 400 also includes: The acquisition module is used to respond to changes in custom resources detected by the function service platform and to obtain the configuration parameters of the message middleware after the changes. The second update module is used to encapsulate the changed configuration parameters as annotation fields of a function container and update them in the function container of the message trigger of the message middleware.

[0130] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0131] Optionally, such as Figure 5 As shown, this application embodiment also provides an electronic device 500, including a processor 501 and a memory 502. The memory 502 stores a program or instructions that can run on the processor 501. When the program or instructions are executed by the processor 501, they implement the various steps of the data access method embodiment in the multi-tenant environment described above and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0132] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0133] Figure 6 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application.

[0134] The electronic device 600 includes, but is not limited to, components such as: radio frequency unit 601, network module 602, audio output unit 603, input unit 604, sensor 605, display unit 606, user input unit 607, interface unit 608, memory 609, and processor 610.

[0135] Those skilled in the art will understand that the electronic device 600 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 610 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 6 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0136] The processor 610 is used to implement the data access method in the multi-tenant environment described above.

[0137] It should be understood that, in this embodiment, the input unit 604 may include a graphics processing unit (GPU) 6041 and a microphone 6042. The GPU 6041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 606 may include a display panel 6061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 607 includes at least one of a touch panel 6071 and other input devices 6072. The touch panel 6071 is also called a touch screen. The touch panel 6071 may include a touch detection device and a touch store-and-forward node. Other input devices 6072 may include, but are not limited to, a physical keyboard, function keys (such as volume control buttons, power buttons, etc.), a trackball, a mouse, and a joystick, which will not be described in detail here.

[0138] The memory 609 can be used to store software programs and various data. The memory 609 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs, or instructions required for functions (such as sound playback functions, image playback functions, etc.). Furthermore, the memory 609 may include volatile memory or non-volatile memory, or it may include both volatile and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), 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 linked dynamic random access memory (Synchlink DRAM, SLDRAM), and direct memory bus RAM (DRRAM). The memory 609 in this embodiment includes, but is not limited to, these and any other suitable types of memory.

[0139] Processor 610 may include one or more processing units; optionally, processor 610 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 610.

[0140] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the data access method embodiments in the multi-tenant environment described above and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0141] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0142] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described data access method embodiments in a multi-tenant environment, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0143] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0144] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0145] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0146] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for data access in a multi-tenant environment, the method comprising: The method comprises: obtaining configuration information of a message middleware from a custom resource; the custom resource is a data source instance of the message middleware defined in a function service platform; the configuration information comprises a tenant identifier; allocating a virtual address for a real address of the message middleware according to the tenant identifier to obtain address mapping information; the address mapping information comprises a mapping relationship between tenant identifiers of different message middlewares and the virtual addresses, and different tenant identifiers correspond to different virtual addresses; in response to a data access request of a tenant, forwarding the data access request according to the address mapping information through a cross-private cloud channel to realize cross-private cloud access of the tenant to the message middleware.

2. The method of claim 1, wherein, The address mapping information further comprises a real address of the message middleware, and the allocating a virtual address for a real address of the message middleware according to the tenant identifier to obtain address mapping information comprises: determining a virtual address pool of the message middleware according to the tenant identifier; the virtual address pool is a dedicated address segment corresponding to the tenant identifier in the function service platform; calling a first data interface of an address management service to allocate a corresponding virtual address for each real address of the message middleware in the virtual address pool; the real address comprises a storage forwarding node address and a metadata service node address of the message middleware; generating the address mapping information according to the tenant identifier, the real address, and the mapping relationship between the tenant identifier and the virtual address.

3. The method of claim 2, wherein, After the generating the address mapping information according to the tenant identifier and the mapping relationship between the tenant identifier and the virtual address, the method further comprises: in a case where the custom resource is deleted, calling a second data interface of the address management service to delete the address mapping information; releasing the virtual address included in the address mapping information back to the virtual address pool.

4. The method of claim 1, wherein, The forwarding the data access request according to the address mapping information through the cross-private cloud channel to realize cross-private cloud access of the tenant to the message middleware in response to the data access request of the tenant comprises: in response to the data access request, determining a tenant identity credential and a virtual address carried by the data access request; in a case where consistency verification of the tenant identity credential and the tenant identifier in the configuration information is passed, obtaining a real address corresponding to the data access request according to the virtual address and the address mapping information; forwarding the data access request to the real address through the cross-private cloud channel to realize cross-private cloud access of the tenant to the message middleware.

5. The method of claim 4, wherein, The forwarding the data access request to the real address through the cross-private cloud channel to realize cross-private cloud access of the tenant to the message middleware comprises: determining private cloud parameter information associated with the real address according to the real address and the tenant identifier; According to the private cloud parameter information, a cross-private cloud channel configuration in the function service platform is queried to obtain a private cloud connection identifier; the private cloud connection identifier is an identifier of a cross-private cloud channel configured by the function service platform for cross-cloud access of each private cloud; According to the private cloud connection identifier, the virtual address, and the real address, a forwarding rule is generated; the forwarding rule includes a port forwarding rule or a destination address conversion rule; According to the forwarding rule, the data access request is forwarded to the message middleware node corresponding to the real address through the cross-private cloud channel.

6. The method of claim 1, wherein, After the cross-private cloud channel access of the message middleware by the tenant is realized by forwarding the data access request according to the address mapping information through the cross-private cloud channel in response to the data access request of the tenant, the method further includes: The metadata of the message middleware is listened to through a message trigger of the message middleware; In a case where the metadata indicates that the real address of the message middleware is changed, a first data interface of an address management service is called to re-allocate a new virtual address for the changed real address; The address mapping information is updated and the new virtual address is sent to the message middleware.

7. The method of claim 1, wherein, Before the configuration information of the message middleware is obtained from the custom resource, the method further includes: In response to a change event of the custom resource listened to by the function service platform, the changed configuration parameter of the message middleware is obtained; The changed configuration parameter is encapsulated as an annotation field of a function container and is updated to the function container of the message trigger of the message middleware.

8. A data access apparatus in a multi-tenant environment, the apparatus comprising: The apparatus includes: A configuration obtaining module is configured to obtain configuration information of a message middleware from a custom resource; the custom resource is a data source instance of the message middleware defined in a function service platform; the configuration information includes a tenant identifier; An address allocation module is configured to allocate a virtual address for a real address of the message middleware according to the tenant identifier to obtain address mapping information; the address mapping information includes a mapping relationship between different tenant identifiers and the virtual addresses of the different tenant identifiers, and different tenant identifiers correspond to different virtual addresses; A cross-cloud access module is configured to forward a data access request of a tenant according to the address mapping information through a cross-private cloud channel to realize cross-private cloud access of the message middleware by the tenant.

9. An electronic device, comprising: The apparatus includes a processor, a memory, and a program or instruction stored on the memory and executable on the processor, and the program or instruction is executed by the processor to implement the steps of the data access method in the multi-tenant environment as claimed in claims 1-7.

10. A readable storage medium, characterized by, The program or instruction is stored on the readable storage medium and is executed by the processor to implement the steps of the data access method in the multi-tenant environment as claimed in claims 1-7.

Images