Processing method and system for tenant data isolation and sharing of multi-service system

Abstract

The application relates to a processing method and system for tenant data isolation and sharing of a multi-service system, and belongs to the technical field of service data processing. The method comprises the following steps: obtaining a historical resource average occupancy rate of a tenant, screening an initial core tenant and a shared tenant, assigning an initial exclusive physical node to the initial core tenant, and assigning an initial shared physical node to the initial shared tenant; an initial slice mapping table of the initial shared physical node is constructed, and a tenant ID is bound; the tenant activity of the initial exclusive physical node and the shared physical node and the slice utilization of the shared physical node are monitored; according to the tenant activity, the core tenant and the shared tenant are updated, and the exclusive physical node and the shared physical node are updated; the current resource occupancy rate of the shared tenant on a new shared physical node is collected, and the slice mapping table of the new shared physical node is updated in combination with the slice utilization. The application has the beneficial effects of improving resource utilization and adapting to dynamic changes of services.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of business data processing, in particular to a processing method and system for tenant data isolation and sharing for multi-business systems. BACKGROUND

[0002] With the rapid development of cloud computing technology, the SaaS (Software as a Service) mode is widely used in enterprise software service field due to its advantages of resource sharing, low cost, easy maintenance, etc. As the core architecture of the SaaS mode, the multi-tenant system requires a set of code to serve multiple tenants at the same time, while ensuring the security, independence and business isolation of each tenant's data, that is, each tenant has an independent data space and can only operate its own data. Under this background, how to balance between resource sharing and data isolation has become a key challenge in the design of multi-tenant systems, especially to meet the stringent requirements of data privacy and compliance in different industries (such as finance, medical care).

[0003] In related technologies, multi-tenant data isolation schemes are mainly divided into three categories: independent database, shared database independent Schema, and shared data table distinguishing tenants by fields. Among them, the shared database independent Schema scheme is widely adopted, which realizes data isolation by allocating independent database Schema (logical namespace) for each tenant, and uses multi-tenant plug-ins of MyBatis-Plus and other tools to automatically add tenant ID filtering conditions during SQL execution to ensure the accuracy of data access. For example, a SaaS enterprise provides independent Schema for tenants through this scheme, while supporting custom fields and modular plug-ins to meet basic customization needs. In addition, some systems combine physical node division and statically classify tenants into core tenants (such as large customers) and non-core tenants (such as small and medium-sized customers), and deploy them in exclusive servers and shared server clusters, respectively.

[0004] The existing isolation scheme based on static classification has the following significant defects:

[0005] Low resource utilization and waste: static division of core / non-core tenants leads to fixed resource allocation, and core tenants may idle for a long time, while non-core tenants sharing physical nodes are prone to resource contention due to business fluctuations, and cannot realize dynamic elastic scheduling.

[0006] Unable to adapt to business dynamics: tenant activity and resource demand change over time (such as promotion activities leading to a surge in resource demand for non-core tenants), and static classification cannot adjust resource allocation strategies in real time, which may lead to a decline in service quality for high-priority tenants or resource idling for low-priority tenants. SUMMARY

[0007] In order to improve resource utilization and adapt to business dynamic changes, the application provides a processing method and system for tenant data isolation and sharing of multi-service system.

[0008] In the first aspect, the application provides a processing method for tenant data isolation and sharing of multi-service system, which adopts the following technical scheme:

[0009] A processing method for tenant data isolation and sharing of multi-service system comprises:

[0010] Obtaining the historical average resource occupancy rate of each tenant;

[0011] According to the historical average resource occupancy rate, screening initial core tenants and initial shared tenants, and allocating initial exclusive physical nodes to the initial core tenants and initial shared physical nodes to the initial shared tenants;

[0012] Constructing an initial slice mapping table corresponding to the initial shared physical nodes and binding it with the corresponding shared tenant ID;

[0013] Real-time monitoring of tenant activity of the initial exclusive physical nodes and the initial shared physical nodes and slice utilization rate of the initial shared physical nodes;

[0014] According to the tenant activity, updating core tenants and shared tenants, and updating exclusive physical nodes and shared physical nodes;

[0015] Collecting the current resource occupancy rate of shared tenants on a new shared physical node;

[0016] According to the slice utilization rate and the current resource occupancy rate, dynamically updating the slice mapping table of the new shared physical node.

[0017] By adopting the above technical scheme, by collecting the historical average resource occupancy rate of tenants, and according to this, dividing the tenants into initial core tenants and non-core tenants (initial shared tenants), and deploying them on initial exclusive physical nodes and initial shared physical nodes respectively, resource waste can be effectively avoided. Core tenants obtain exclusive resources to guarantee their service quality, and non-core tenants share resources to improve overall utilization. By binding the tenant ID with the slice mapping table of the shared physical node, the isolation of tenant data at the physical layer is realized; at the same time, the shared physical node supports resource sharing between shared tenants, taking into account efficiency and security. By real-time monitoring of tenant activity, dynamically adjusting its core or non-core identity, and adjusting its resource allocation strategy accordingly, high-activity tenants can obtain priority resource response. By monitoring the slice utilization rate of the shared physical node, dynamically adjusting the slice mapping table, dynamic rebalancing and load optimization of resources are realized.

[0018] Optionally, the step of constructing an initial slice mapping table corresponding to the initial shared physical node includes:

[0019] receiving an initial shared physical node cluster and a physical resource type set;

[0020] obtaining a shared physical node load of each shared physical node in the initial shared physical node cluster;

[0021] generating a slice rule according to the shared physical node load and a historical resource average occupancy rate of each shared tenant;

[0022] constructing an initial slice mapping table corresponding to the initial shared physical node according to the slice rule.

[0023] By adopting the above technical solution, the initial shared physical node cluster and the physical resource type set are received, and comprehensive basic information is provided for resource slicing. The slice rule is generated according to the node load of each shared physical node and the historical resource average occupancy rate of each shared tenant, which helps to divide the physical resources according to the actual carrying capacity of the nodes and the real demand of the tenants, avoids the blindness of resource allocation, and thus improves the rationality of resource allocation. For shared tenants, their resource demand is relatively not so urgent and critical, and the use of shared physical nodes is itself to improve resource utilization. The initial slice mapping table constructed through the above steps can allocate the resources of the shared physical nodes to each shared tenant more finely, reduce the idling and waste of resources, and further improve the resource utilization of the shared physical nodes. The node load of each shared physical node is considered when generating the slice rule, which means that when constructing the initial slice mapping table, the resource demand of the tenant will be allocated to the node with relatively low load or sufficient carrying capacity, thereby helping to balance the load of the entire shared physical node cluster, avoiding performance bottlenecks or failures of some nodes due to high load, and ensuring the overall stability of the system.

[0024] Optionally, the step of updating the core tenant and the shared tenant, and updating the exclusive physical node and the shared physical node according to the tenant activity includes:

[0025] determining whether the tenant activity is continuously greater than a set activity threshold in a preset sliding window;

[0026] if yes, updating the core tenant and the shared tenant according to the tenant activity;

[0027] collecting a current resource occupancy rate of the core tenant;

[0028] obtaining an independent node load of the exclusive physical node;

[0029] According to the current resource occupancy and the independent node load, a core tenant is re-assigned an exclusive physical node, and a shared tenant is assigned a shared physical node.

[0030] By using the above technical solution, whether the tenant activity is continuously higher than the threshold value in the preset sliding window is monitored, false judgments caused by short-term fluctuations are avoided, and the identification accuracy of the core tenant is ensured; in combination with the current resource occupancy of the active tenant and the independent node load, the node resources are re-assigned, the service degradation of the core tenant caused by insufficient resources is avoided, and excessive occupation of the shared physical node resources by the shared tenant is prevented. After the core tenant is re-assigned to the exclusive physical node, resource competition with other tenants is avoided, and low latency and high availability of critical businesses (such as financial transactions and real-time data analysis) are ensured. The whole process from activity monitoring to node allocation does not require manual intervention, and the workload of the operation and maintenance personnel is reduced.

[0031] Optionally, the step of judging whether the tenant activity is continuously greater than the set activity threshold value in the preset sliding window further includes:

[0032] If not, the number of times and the interval duration that each tenant serves as a core tenant are obtained;

[0033] According to the number of times and the interval duration, the tenants are classified according to importance;

[0034] According to the tenant activity and the importance level to which the tenant belongs, the core tenant and the shared tenant are updated.

[0035] By using the above technical solution, the combination of historical data and real-time activity is used to avoid decision bias caused by a single indicator. For example, although a certain tenant has a small number of core times (1 time), the recent activity has increased sharply and the interval duration is short (2 months), the potential of the tenant can be identified through importance classification, and the core resources are preferentially assigned.

[0036] Optionally, the step of dynamically updating the slice mapping table of the new shared physical node according to the slice utilization and the current resource occupancy includes:

[0037] It is judged whether the slice utilization corresponding to the new shared physical node is less than the set utilization;

[0038] If not, according to the current resource occupancy, an idle slice is retrieved from the shared resource pool;

[0039] According to the idle slice, the slice of the corresponding shared tenant is expanded, and the slice mapping table is updated;

[0040] If yes, part of the slice of the corresponding shared tenant is recovered to the shared resource pool;

[0041] It is judged whether the remaining slice resources meet the current resource occupancy.

[0042] If not, the number of slices is adjusted according to the current resource occupancy, and the slice mapping table is updated.

[0043] By adopting the technical scheme, whether the slice utilization rate is less than the set threshold value is judged, idle slice resources in a low load state can be actively found and recycled, and waste caused by long-term idling of resources is avoided. For example, when a certain shared tenant business is in a trough period, the utilization rate of part of the slices occupied by the business significantly decreases, and the system can automatically release the excess slices to the shared resource pool for use by other tenants. After recycling the slices, whether the remaining slice resources meet the current resource occupancy is checked to ensure that the core business of the tenant is not affected. If the remaining slices cannot support the current load, the number of slices is dynamically increased according to the actual resource occupancy; if the slice utilization rate is not less than the set value but the resource demand of the tenant increases, the system can directly call idle slices for expansion to realize real-time matching of resource supply and business demand. Before recycling the slices, the constraint condition of “whether the remaining slices meet the current resource occupancy” can prevent the performance of the tenant business from decreasing due to blind recycling of resources, and ensure that the shared tenant can still obtain stable resource support in the shared mode. Through the double-index adjustment mechanism of “utilization rate triggering recycling + occupancy rate driving expansion”, the system can quickly call idle slices for expansion when the traffic of the tenant business suddenly increases, shorten the resource response delay, and improve the tenant experience. The recycling and redistribution of idle slices form an internal circulation mechanism of resources, so that the physical resources (such as computing, storage, and bandwidth) of the shared physical node can be efficiently circulated among multiple tenants, maximize the resource reuse rate, and reduce the overall infrastructure cost.

[0044] Optionally, after collecting the current resource occupancy of the initial shared tenant, the step of dynamically updating the slice mapping table of the new shared physical node before the slice mapping table of the new shared physical node is updated according to the slice utilization rate and the current resource occupancy includes:

[0045] Obtaining an over-limit number of the current resource occupancy exceeding an occupancy threshold value;

[0046] Determining whether the over-limit number is greater than an over-limit threshold value;

[0047] If yes, an over-limit deviation value is obtained, the over-limit deviation value being a difference between the current resource occupancy and the occupancy threshold value;

[0048] Migrating shared tenant data with the over-limit deviation value less than a deviation threshold value to a standby shared physical node;

[0049] Dynamically updating the slice mapping table of the new shared physical node according to the slice utilization rate and the current resource occupancy of the remaining shared tenant.

[0050] By adopting the technical scheme, the resource bottleneck of the shared physical node can be quickly located by collecting the current resource occupancy rate and calculating the "over-limit quantity" (the number of tenants exceeding the occupancy rate threshold), and the overall collapse of the node caused by excessive resource occupation of a single tenant is avoided. Through the secondary judgment of "whether the over-limit quantity is greater than the over-limit threshold", the accidental over-limit and the systematic overload are distinguished, the invalid intervention is reduced, and the resource management efficiency is improved. Only the tenants with "over-limit deviation value less than deviation threshold" are migrated to the backup node, the influence of "one-size-fits-all" migration on high-priority non-core tenants is avoided, and the service continuity of most shared tenants is ensured. Through the backup shared physical node, the overload tenants are shunted, the dynamic redistribution of physical resources is realized, and it is ensured that the loads of the original shared physical node and the backup node are within the safety threshold.

[0051] Optionally, the step of judging whether the over-limit quantity is greater than the over-limit threshold further includes:

[0052] If not, from the historical slice mapping library, a first historical slice utilization rate and a first historical resource occupancy rate matching the slice utilization rate and the current resource occupancy rate are found;

[0053] The historical slice mapping set matching the first historical slice utilization rate and the first historical resource occupancy rate is called;

[0054] It is judged whether there is a similar first historical slice mapping table in the historical slice mapping set;

[0055] If yes, the slice mapping table of the new shared physical node is dynamically updated according to the first historical slice mapping table.

[0056] By adopting the technical scheme, by finding matching data from the historical slice mapping library, if there is a similar historical slice mapping table, it is directly reused or adjusted, which avoids a large amount of calculation overhead of generating a new mapping table from scratch each time, significantly shortens the decision-making time, and thus improves the response speed and overall operation efficiency of the system. Through reasonable slice mapping, it is ensured that different slice businesses can obtain the required resources.

[0057] Optionally, the step of judging whether there is a similar first historical slice mapping table in the historical slice mapping set further includes:

[0058] If not, the average slice utilization rate and the average resource occupancy rate of the historical slice mapping set are calculated;

[0059] From the historical slice mapping set, a second historical slice utilization rate and a second historical resource occupancy rate similar to the average slice utilization rate and the average resource occupancy rate are selected;

[0060] retrieve a second historical slice mapping table matched with the second historical slice utilization and the second historical resource occupancy rate;

[0061] According to the second historical slice mapping table, a slice mapping table of a new shared physical node is dynamically updated.

[0062] By using the above technical solution, the existing mapping set is used for rapid adaptation and incremental update, the generation frequency of a new mapping table and the case of full amount reconfiguration are reduced, the service interruption risk and the related business migration overhead caused by frequent switching of the mapping strategy are significantly reduced, the continuity and stability of network service are ensured. Through the matching and average value screening of historical data, the current resource demand can be more accurately predicted and matched, the over allocation or insufficient allocation of resources is avoided, the utilization rate of physical node resources is improved, unnecessary resource waste is reduced, and the network operation cost is reduced as a whole.

[0063] In a second aspect, the application provides a processing system for tenant data isolation and sharing of a multi-service system, which adopts the following technical solution:

[0064] A processing system for tenant data isolation and sharing of a multi-service system, comprising:

[0065] A data acquisition module is configured to acquire historical resource average occupancy rate of each tenant and collect current resource occupancy rate of shared tenants on a new shared physical node;

[0066] A node allocation module is configured to screen initial core tenants and initial shared tenants according to the historical resource average occupancy rate, and allocate initial exclusive physical nodes to the initial core tenants and initial shared physical nodes to the initial shared tenants;

[0067] A slice mapping module is configured to construct an initial slice mapping table corresponding to the initial shared physical nodes and bind with corresponding shared tenant IDs;

[0068] A monitoring module is configured to monitor tenant activity of the initial exclusive physical nodes and the initial shared physical nodes and slice utilization rate of the initial shared physical nodes in real time;

[0069] A node update module is configured to update core tenants and shared tenants and update exclusive physical nodes and shared physical nodes according to the tenant activity;

[0070] A slice mapping update module is configured to dynamically update a slice mapping table of a new shared physical node according to the slice utilization rate and the current resource occupancy rate.

[0071] In summary, the application has at least the following beneficial effects:

[0072] By collecting the historical average resource occupancy of tenants, and dividing the tenants into initial core tenants and non-core tenants (initial shared tenants) according to the historical average resource occupancy, the initial core tenants and the initial shared tenants are respectively deployed on the initial exclusive physical nodes and the initial shared physical nodes, so that resource waste can be effectively avoided. The core tenants obtain exclusive resources to guarantee the quality of service, and the shared tenants share resources to improve the overall utilization rate. By binding the tenant ID and the slice mapping table of the shared physical node, the isolation of tenant data at the physical layer is realized; at the same time, the shared physical node supports resource sharing between shared tenants, and efficiency and safety are taken into account. By monitoring the tenant activity in real time, the tenant is dynamically adjusted to be a core or non-core identity, and the resource allocation strategy is adjusted accordingly to ensure that high-activity tenants obtain priority resource response. By monitoring the slice utilization rate of the shared physical node, the slice mapping table is dynamically adjusted to realize dynamic rebalancing and load optimization of resources. BRIEF DESCRIPTION OF DRAWINGS

[0073] Figure 1 is a first flowchart of the method embodiment of the present application;

[0074] Figure 2 is a second flowchart of the method embodiment of the present application;

[0075] Figure 3 is a third flowchart of the method embodiment of the present application;

[0076] Figure 4 is a fourth flowchart of the method embodiment of the present application;

[0077] Figure 5 is a fifth flowchart of the method embodiment of the present application;

[0078] Figure 6 is a sixth flowchart of the method embodiment of the present application. DETAILED DESCRIPTION

[0079] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the following will combine the accompanying drawings of the embodiments of the present application to clearly and completely describe the technical solutions of the embodiments of the present application. Obviously, the described embodiments are some, but not all of the embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application. Figure 1 -attached Figure 6 , the technical solutions in the embodiments of the present application are clearly and completely described. Obviously, the described embodiments are some, but not all of the embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0080] The first embodiment of the present application discloses a processing method for tenant data isolation and sharing of a multi-service system. Referring to Figure 1 , the processing method can include S110-S170:

[0081] S110, obtain the historical average resource occupancy of each tenant;

[0082] S120, screen the initial core tenants and the initial shared tenants according to the historical average resource occupancy, and allocate initial exclusive physical nodes to the initial core tenants and initial shared physical nodes to the initial shared tenants;

[0083] S130, construct an initial slice mapping table corresponding to the initial shared physical nodes and bind the initial slice mapping table with the corresponding shared tenant ID;

[0084] S140, monitor the tenant activity of the initial exclusive physical nodes and the initial shared physical nodes and the slice utilization of the initial shared physical nodes in real time;

[0085] S150, update the core tenants and the shared tenants and update the exclusive physical nodes and the shared physical nodes according to the tenant activity;

[0086] S160, collect the current resource occupancy of the shared tenants on the new shared physical nodes;

[0087] S170, dynamically update the slice mapping table of the new shared physical nodes according to the slice utilization and the current resource occupancy.

[0088] Specifically, for S110-S120, the monitoring system (such as Prometheus, Zabbix, Telegraf, etc.) can be used to collect the resource usage data of each tenant in a period of time (such as the past 30 days), including CPU, memory, disk I / O, network bandwidth, etc. The time series aggregation calculation is performed on the collected data to obtain the average resource occupancy of each tenant in each dimension.

[0089] The threshold (such as CPU average occupancy > 70% or memory average occupancy > 60%) is set as the core tenant screening standard. For the tenants exceeding the threshold, they are determined as “initial core tenants” and are preferentially allocated exclusive physical nodes; the remaining tenants are classified as “initial shared tenants” and are uniformly allocated to the shared physical node pool and are isolated by virtualization technology (such as KVM, Docker).

[0090] Referring to Figure 2 For S130, the steps of constructing the initial slice mapping table corresponding to the initial shared physical nodes include S210-S240:

[0091] S210, receive the initial shared physical node cluster and the physical resource type set;

[0092] S220, obtain the shared physical node load of each shared physical node in the initial shared physical node cluster;

[0093] S230, generating a slice rule according to the shared physical node load and the historical average resource occupancy of each shared tenant;

[0094] S240, constructing an initial slice mapping table corresponding to the initial shared physical node according to the slice rule.

[0095] Specifically, the shared physical node cluster information can be obtained in batches through a cluster management system API (such as a Kubernetes API, an OpenStack Nova API), including node ID, IP address, hardware configuration (CPU core number, memory capacity, disk type and size, network bandwidth) and other metadata. The physical node can be understood as a server. At the same time, the physical resource type set is defined as a standardized dimension, such as {CPU, memory, disk IOPS, network throughput}, and the units of each type (such as CPU core number, GB memory, IOPS / second, Gbps bandwidth) are preset through a configuration file or a database. A node-level monitoring agent (such as Prometheus Node Exporter, Telegraf) is deployed to collect real-time load data, including CPU usage (%), memory usage (%), disk IO usage (%), and network bandwidth usage (%); the collected nearly 1-hour data is averaged by sliding window to obtain the current average load value of each node; the normalized load index is calculated in combination with the node hardware configuration, for example: load index = (CPU usage x weight 1 + memory usage x weight 2 +...) / total weight, the weight can be configured according to the business priority (such as CPU-intensive task CPU weight set to 0.4). The nodes with a load index lower than a threshold (such as 60%) are preferentially selected as slice targets to avoid overload nodes participating in allocation; based on the historical average occupancy rate of the tenant obtained in S110, a basic slice quota is allocated to each tenant, for example, the historical CPU average occupancy of tenant A is 0.5 cores, and the basic quota is set to 0.6 cores (20% buffer is reserved); a dynamic step slice strategy is adopted, for example, CPU takes 0.1 core as the minimum slice unit, and memory takes 256MB as the unit, the step can be defined by slice(start=0, stop=node total resource, step=minimum unit), the resource allocation accuracy is controlled by referring to the step parameter in the Python slicing operation. The total slice quota of all tenants on the same node does not exceed 80% of the available resources of the node (20% elastic space is reserved). The slice mapping table adopts a two-dimensional dictionary structure, the mapping table is serialized and stored in a distributed database (such as etcd, MongoDB), and is bound with the ID of the corresponding shared tenant; and version control (such as timestamp + node ID) is used to ensure idempotency.

[0096] For S140, real-time monitoring components (such as Grafana + Prometheus + Node Exporter) can be deployed to collect tenant activity (such as request number, online time, API call frequency) and resource usage data; for shared physical nodes, the actual resource usage of each slice (CPU usage, memory occupation, etc.) is monitored, and the slice utilization rate = (slice actual resource occupation amount / slice allocated resource amount) x 100%.

[0097] Referring to Figure 3 For S150, according to the tenant activity, the steps of updating the core tenants and shared tenants, and updating the exclusive physical nodes and shared physical nodes include S310-S380:

[0098] S310, determining whether the tenant activity is greater than a preset activity threshold in a preset sliding window;

[0099] S320, if yes, updating the core tenants and shared tenants according to the tenant activity;

[0100] S330, if no, obtaining the number of times and interval duration that each tenant is a core tenant;

[0101] S340, classifying the importance of the tenant according to the number of times and interval duration;

[0102] S350, updating the core tenants and shared tenants according to the tenant activity and the importance level to which the tenant belongs;

[0103] S360, collecting the current resource occupation rate of the core tenant;

[0104] S370, obtaining the independent node load of the exclusive physical node;

[0105] S380, according to the current resource occupation rate and the independent node load, re-allocating the exclusive physical nodes for the core tenants and the shared physical nodes for the shared tenants.

[0106] Specifically, a time sliding window algorithm (such as Sliding Window Log or Fixed Window Counter) can be used to count the request frequency, API call times or business operation times of each tenant within a specified time window (such as 5 minutes). The activity threshold can be set to the number of requests per minute > N, N being a threshold set according to historical data or business requirements. A real-time stream processing system (such as Flink, Kafka Streams or Spark Streaming) is introduced to calculate the activity index in real time. A rule engine (such as Drools, Easy Rules) or a machine learning classification model (such as SVM, XGBoost) is used to classify tenants. The classification criteria include: activity, historical resource usage trend, SLA level, payment level, etc. A dynamic label mechanism is adopted, and tenants that meet the conditions are labeled as "core tenants", and the rest are labeled as "shared tenants". Core tenants are preferentially allocated to low-load, high-performance and high-availability physical node clusters, and shared tenants use shared resource pool mechanism and are scheduled to nodes with moderate load and high resource utilization.

[0107] When it is determined that the tenant activity is less than or equal to the set activity threshold in the preset sliding window, the tenant's historical scheduling information recorded in the database is called, and time series analysis logic is introduced to calculate the frequency (such as the number of occurrences per month) and interval period (such as the time interval of the last time being a core tenant) of the tenant becoming a core tenant. A tenant importance scoring model is built, and the formula can be:

[0108] Importance score = a * (number of core scheduling times / total scheduling times) + b * (reciprocal of the latest scheduling interval), where a and b are weight coefficients that can be adjusted. A grading strategy is used for the importance score to divide tenants into: S-level (very important), A-level (important), B-level (general), and C-level (low priority). Then, according to the tenant activity and the importance level of the tenant, the core tenants and shared tenants are updated, for example, according to a decision tree or a rule engine, for example: if the activity is high and the importance is high → core tenant; if the activity is high and the importance is low → temporarily promoted to a shared tenant, and the subsequent performance is observed; if the activity is low but the importance is high → keep as a shared tenant and evaluate regularly.

[0109] Referring to Figure 4 For S170, according to the slice utilization rate and the current resource occupancy rate, the steps of dynamically updating the slice mapping table of the new shared physical node include S410-S470:

[0110] S410, determine whether the slice utilization rate corresponding to the new shared physical node is less than the set utilization rate;

[0111] S420, if not, according to the current resource occupancy rate, an idle slice is retrieved from the shared resource pool;

[0112] S430, according to the idle slice, expanding the slice corresponding to the shared tenant, and updating the slice mapping table;

[0113] S440, if yes, then recycling part of the slice corresponding to the shared tenant to the shared resource pool;

[0114] S450, judging whether the remaining slice resource meets the current resource occupancy rate;

[0115] S460, if no, then adjusting the number of slices according to the current resource occupancy rate, and updating the slice mapping table;

[0116] S470, if yes, then updating the slice mapping table according to the remaining slice resource.

[0117] Specifically, if the slice utilization rate is greater than the set utilization rate, it indicates that the current resource of the shared physical node is tight, so the resource pool management module can be called to query the available slice resource list, and the appropriate idle slice is matched according to the tenant priority, QoS level and slice type; Then use the API interface to obtain the slice resource information (such as slice ID, resource configuration, available state, etc.) from the shared resource pool. The obtained idle slice is allocated to the corresponding shared tenant, and the slice resource quota is updated; the slice is instantiated and deployed to the target node by using the virtualization orchestrator (such as Kubernetes or NFV Orchestrator), and the slice mapping table is updated to record the information of the belonging tenant, the physical node, the start time, etc.

[0118] If the utilization rate is not greater than the set utilization rate, it indicates that there is resource waste in the shared physical node, so the load prediction model (such as time series prediction or machine learning model) can be used to evaluate the future resource demand and identify the recyclable slice; select the slice with low priority, low QoS requirement or idle state for recycling. Call the slice destruction interface to release the occupied physical resources, mark the slice state as "idle", and add it to the shared resource pool for other shared tenants to call as needed.

[0119] Calculate the remaining carrying capacity (such as remaining CPU capacity, memory bandwidth, etc.) of the node after recycling part of the slice, and judge whether the remaining slice resource meets the current resource occupancy rate; if yes, perform the slice mapping table updating operation, clean up the invalid slice record, and update the ownership relationship and resource allocation of the new slice; if no, the resource scheduling algorithm (such as proportional distribution, priority scheduling, weighted fair queue) can be used to reallocate resources, dynamically increase the number of slices of high-priority tenants, or reduce the number of slices of low-priority tenants, to update the slice mapping table and meet the current resource occupancy rate.

[0120] In addition, with reference to Figure 5 andFigure 6 The steps between S160 and S170 can include S510-S630.

[0121] S510, obtaining an over-limit number of current resource occupancy exceeding an occupancy threshold value;

[0122] S520, determining whether the over-limit number is greater than an over-limit threshold value;

[0123] S530, if yes, obtaining an over-limit deviation value, the over-limit deviation value being a difference between the current resource occupancy and the occupancy threshold value;

[0124] S540, migrating shared tenant data with an over-limit deviation value less than a deviation threshold value to a backup shared physical node;

[0125] S550, dynamically updating a slice mapping table of a new shared physical node according to a slice utilization rate of a remaining shared tenant and the current resource occupancy;

[0126] S560, if no, searching, from a historical slice mapping library, a first historical slice utilization rate and a first historical resource occupancy rate matching the slice utilization rate and the current resource occupancy;

[0127] S570, calling a historical slice mapping set matching the first historical utilization rate and the first historical resource occupancy rate;

[0128] S580, determining whether there is a similar first historical slice mapping table in the historical slice mapping set;

[0129] S590, if yes, dynamically updating the slice mapping table of the new shared physical node according to the first historical slice mapping table;

[0130] S600, if no, calculating an average slice utilization rate and an average resource occupancy rate of the historical slice mapping set;

[0131] S610, screening, from the historical slice mapping set, a second historical slice utilization rate and a second historical resource occupancy rate similar to the average slice utilization rate and the average resource occupancy rate;

[0132] S620, calling a second historical slice mapping table matching the second historical slice utilization rate and the second historical resource occupancy rate;

[0133] S630, dynamically updating the slice mapping table of the new shared physical node according to the second historical slice mapping table.

[0134] If there is no second historical slice utilization rate and second historical resource occupancy rate similar to the average slice utilization rate and the average resource occupancy rate, S170 is executed.

[0135] Specifically, if the resource usage of a tenant exceeds the threshold (e.g., CPU usage > 85%), it is counted as an "overrun event". The number of all overrun events is counted as "overrun number"; the threshold can be dynamically adjusted based on historical load analysis. By judging whether the "overrun number" exceeds the overrun threshold in the statistical period, it is determined whether to enter the resource optimization process. For example, if the overrun number > 3, a further processing process (S530) is triggered; otherwise, a historical matching process (S560) is entered. For S530, the comprehensive overrun deviation value is weighted and calculated for different resource dimensions. For tenants with an overrun deviation value less than the overrun threshold, a lightweight migration operation is performed, for example: using the Pod scheduling mechanism of Kubernetes or virtual machine migration tools (such as vMotion) to migrate the containers or virtual machines of the tenant to the standby node, and using the load balancer (such as Nginx or HAProxy) to perform traffic switching during the migration process.

[0136] For S560, in the historical database, an index model of slice utilization and resource occupancy is established, and a similarity matching algorithm (such as cosine similarity, Euclidean distance) is used to find the historical record closest to the current system state. More specifically, the slice utilization and resource occupancy of the current system are extracted; the records in the historical mapping library are traversed, and the similarity is calculated; the record with the highest similarity is selected as the "first historical matching item". The slice mapping table corresponding to the "first historical matching item" found is taken out from the historical mapping library to form a historical mapping set; the mapping table can include the mapping relationship between the slice and the physical node, the resource allocation strategy, the scheduling rule, etc. The slice mapping table in the historical mapping set taken out is subjected to cluster analysis or similarity comparison to determine whether there is a mapping table with highly similar structure and resource allocation strategy. More specifically, the hash value of the slice mapping structure is used for comparison, the mapping table content is subjected to structured vectorization processing, and a clustering algorithm (such as K-Means) is used for classification; if the similarity is higher than the set threshold, it is considered that "there is a similar mapping table". The matched historical slice mapping table is used as a template, combined with the current system state (such as the addition of physical nodes, changes in resource capacity), and a policy engine (Policy Engine) is used for fine-tuning to generate a new mapping table.

[0137] If there is no similar first historical slice mapping table, the slice utilization rate and resource occupancy rate of all records in the historical mapping set are weightedly averaged as the "average slice utilization rate" and "average resource occupancy rate", and the weights can be set based on time freshness, stability of historical utilization rate, etc. Using K-Nearest Neighbor (KNN) or a similarity-based filtering mechanism, records similar to the average slice utilization rate and the average resource occupancy rate are selected from the historical mapping set. More specifically, the difference between each record and the average value is calculated, and a similarity threshold (such as a difference < 5%) is set; records that meet the condition are selected as "second historical matching items". From the "second historical matching items", the most matching slice mapping table is selected as the basis for updating the current system mapping, for example, the historical record with the closest time is selected first, or the historical record with the same resource scheduling strategy as the current system is selected first. The selected second historical slice mapping table is fused with the current system state to generate a slice mapping table that adapts to the current physical node resource state.

[0138] The implementation principle of the embodiment is:

[0139] The historical resource average occupancy rate of each tenant is obtained, and the initial core tenants and the initial shared tenants are screened according to the historical resource average occupancy rate, and the initial core tenants are allocated initial exclusive physical nodes and the initial shared tenants are allocated initial shared physical nodes;

[0140] The initial shared physical node cluster and the physical resource type set are received, the shared physical node load of each shared physical node in the initial shared physical node cluster is obtained, the slice rule is generated according to the shared physical node load and the historical resource average occupancy rate of each shared tenant, and the initial slice mapping table corresponding to the initial shared physical node is constructed according to the slice rule, and the initial slice mapping table is bound with the corresponding shared tenant ID;

[0141] The tenant activity of the initial exclusive physical node and the initial shared physical node and the slice utilization rate of the initial shared physical node are monitored in real time;

[0142] It is judged whether the tenant activity is continuously greater than the set activity threshold in the preset sliding window, if yes, the core tenants and the shared tenants are re-screened according to the tenant activity; if not, the number of times and the interval duration that each tenant is taken as a core tenant are obtained, the tenants are classified according to the number of times and the interval duration, the core tenants and the shared tenants are updated according to the tenant activity and the importance level to which the tenant belongs; the current resource occupancy rate of the core tenants is collected, the independent node load of the exclusive physical node is obtained, and then the exclusive physical node is re-allocated to the core tenants and the shared physical node is allocated to the shared tenants according to the current resource occupancy rate and the independent node load;

[0143] The current resource occupancy of the shared tenants on the new shared physical node is collected, the number of over-limit is obtained when the current resource occupancy exceeds the occupancy threshold, it is judged whether the number of over-limit is greater than the over-limit threshold, if yes, the over-limit deviation value of the current resource occupancy and the occupancy threshold is obtained, and the shared tenant data with the over-limit deviation value less than the deviation threshold is migrated to the standby shared physical node, and the slice mapping table of the new shared physical node is dynamically updated according to the slice utilization rate and the current resource occupancy of the remaining shared tenants;

[0144] If no, the first historical slice utilization rate and the first historical resource occupancy rate matching the slice utilization rate and the current resource occupancy rate are searched from the historical slice mapping library, and then the historical slice mapping set matching the first historical utilization rate and the first historical resource occupancy rate is called. It is judged whether there is a similar first historical slice mapping table in the historical slice mapping set, if yes, the corresponding slice mapping table of the new shared physical node is dynamically updated according to the first historical slice mapping table, if no, the average slice utilization rate and the average resource occupancy rate of the historical slice mapping set are calculated. The second historical slice utilization rate and the second historical resource occupancy rate similar to the average slice utilization rate and the average resource occupancy rate are screened from the historical slice mapping set, and the second historical slice mapping table matching the second historical slice utilization rate and the second historical resource occupancy rate is called. The corresponding slice mapping table of the new shared physical node is dynamically updated according to the second historical slice mapping table. If there is no second historical slice utilization rate and second historical resource occupancy rate similar to the average slice utilization rate and the average resource occupancy rate, the slice mapping table of the new shared physical node is dynamically updated according to the slice utilization rate and the current resource occupancy.

[0145] Based on the above method embodiments, the second embodiment of the present application discloses a processing system for tenant data isolation and sharing of multi-service systems. The processing system for tenant data isolation and sharing of multi-service systems can implement any of the above processing methods for tenant data isolation and sharing of multi-service systems, and the specific working processes of each module in the processing system for tenant data isolation and sharing of multi-service systems can refer to the corresponding processes in the above method embodiments.

[0146] For ease of understanding, the following examples are given: a processing system for tenant data isolation and sharing of multi-service systems, comprising:

[0147] A data acquisition module is configured to collect the historical average resource occupancy of each tenant and the current resource occupancy of the shared tenants on the new shared physical node.

[0148] A node allocation module is configured to screen the initial core tenants and the initial shared tenants according to the historical average resource occupancy, and allocate the initial exclusive physical nodes to the initial core tenants and the initial shared physical nodes to the initial shared tenants.

[0149] a slice mapping module, configured to construct an initial slice mapping table corresponding to the initial shared physical node and bind the initial slice mapping table with a corresponding shared tenant ID;

[0150] a monitoring module, configured to monitor tenant activity of the initial exclusive physical node and the initial shared physical node and slice utilization of the initial shared physical node in real time;

[0151] a node updating module, configured to update core tenants and shared tenants and update exclusive physical nodes and shared physical nodes according to the tenant activity;

[0152] a slice mapping updating module, configured to dynamically update a slice mapping table of a new shared physical node according to the slice utilization and a current resource occupancy.

[0153] The above are preferred embodiments of the present application, and do not limit the protection scope of the present application in succession. Any feature disclosed in the specification (including the abstract and the drawings) can be replaced by other equivalent or similar features, unless specifically described. That is, each feature is only an example of a series of equivalent or similar features, unless specifically described.

Claims

1. A processing method for tenant data isolation and sharing for multi-service system, characterized in that, The method comprises the following steps: acquiring historical average resource occupancy of each tenant; screening initial core tenants and initial shared tenants according to the historical average resource occupancy, and allocating initial exclusive physical nodes to the initial core tenants and initial shared physical nodes to the initial shared tenants; constructing an initial slice mapping table corresponding to the initial shared physical nodes and binding the initial slice mapping table with corresponding shared tenant IDs; monitoring tenant activity of the initial exclusive physical nodes and the initial shared physical nodes and slice utilization of the initial shared physical nodes in real time; updating core tenants and shared tenants and updating exclusive physical nodes and shared physical nodes according to the tenant activity; collecting current resource occupancy of shared tenants on a new shared physical node; dynamically updating a slice mapping table of the new shared physical node according to the slice utilization and the current resource occupancy. 2.The processing method of tenant data isolation and sharing for a multi-service system according to claim 1, wherein, The step of constructing an initial slice mapping table corresponding to the initial shared physical nodes comprises the following steps: receiving an initial shared physical node cluster and a physical resource type set; acquiring shared physical node load of each shared physical node in the initial shared physical node cluster; generating a slice rule according to the shared physical node load and historical average resource occupancy of each shared tenant; constructing an initial slice mapping table corresponding to the initial shared physical nodes according to the slice rule.

3. The processing method of claim 1, wherein, The step of updating core tenants and shared tenants and updating exclusive physical nodes and shared physical nodes according to the tenant activity comprises the following steps: determining whether the tenant activity is greater than a preset activity threshold continuously within a preset sliding window; if yes, updating core tenants and shared tenants according to the tenant activity; collecting current resource occupancy of core tenants; acquiring independent node load of exclusive physical nodes; allocating exclusive physical nodes to core tenants and shared physical nodes to shared tenants again according to the current resource occupancy and the independent node load.

4. The processing method of claim 3, wherein, The step of determining whether the tenant activity is greater than a preset activity threshold continuously within a preset sliding window further comprises the following steps: if no, acquiring the number of times and interval duration that each tenant is a core tenant; grading tenants according to the number of times and interval duration; updating core tenants and shared tenants according to the tenant activity and the importance level to which the tenants belong.

5. The processing method of claim 1, wherein, The step of dynamically updating a slice mapping table of the new shared physical node according to the slice utilization and the current resource occupancy comprises the following steps: determining whether the slice utilization corresponding to the new shared physical node is less than a preset utilization; if no, adjusting the number of slices according to the current resource occupancy and updating the slice mapping table; if yes, recycling part of slices of corresponding shared tenants to the shared resource pool; determining whether the remaining slice resources meet the current resource occupancy; if not, adjusting the number of slices according to the current resource occupancy and updating the slice mapping table. ​ 6. The processing method of tenant data isolation and sharing for a multi-service system according to claim 5, characterized in that, The step of dynamically updating the slice mapping table of the new shared physical node before the current resource occupancy of the initial shared tenant is collected comprises: acquiring an over-limit quantity of the current resource occupancy exceeding an occupancy threshold; determining whether the over-limit quantity is greater than an over-limit threshold; if yes, acquiring an over-limit deviation value, which is a difference between the current resource occupancy and the occupancy threshold; migrating shared tenant data with the over-limit deviation value less than a deviation threshold to a backup shared physical node; dynamically updating the slice mapping table of the new shared physical node according to the slice utilization and the current resource occupancy of the remaining shared tenant.

7. The processing method of tenant data isolation and sharing for multi-service system according to claim 6, characterized in that, The step of determining whether the over-limit quantity is greater than the over-limit threshold further comprises: if no, finding a first historical slice utilization and a first historical resource occupancy from a historical slice mapping library that match the slice utilization and the current resource occupancy; calling a historical slice mapping set that matches the first historical slice utilization and the first historical resource occupancy; determining whether a similar first historical slice mapping table exists in the historical slice mapping set; if yes, dynamically updating the slice mapping table of the new shared physical node according to the first historical slice mapping table.

8. The processing method of tenant data isolation and sharing for a multi-service system according to claim 7, characterized in that, The step of determining whether a similar first historical slice mapping table exists in the historical slice mapping set further comprises: if no, calculating an average slice utilization and an average resource occupancy of the historical slice mapping set; filtering a second historical slice utilization and a second historical resource occupancy from the historical slice mapping set that are similar to the average slice utilization and the average resource occupancy; calling a second historical slice mapping table that matches the second historical slice utilization and the second historical resource occupancy; dynamically updating the slice mapping table of the new shared physical node according to the second historical slice mapping table.

9. A processing system for tenant data isolation and sharing for multi-service system, characterized in that, The processing method for tenant data isolation and sharing in a multi-service system according to any one of claims 1-8 comprises: a data acquisition module configured to acquire a historical resource average occupancy of each tenant and collect a current resource occupancy of a shared tenant on a new shared physical node; a node allocation module configured to screen initial core tenants and initial shared tenants according to the historical resource average occupancy, and allocate an initial exclusive physical node to the initial core tenants and an initial shared physical node to the initial shared tenants; a slice mapping module configured to construct an initial slice mapping table corresponding to the initial shared physical node and bind the initial slice mapping table to a corresponding shared tenant ID; a monitoring module configured to monitor tenant activity of the initial exclusive physical node and the initial shared physical node and slice utilization of the initial shared physical node in real time; a node updating module configured to update core tenants and shared tenants and update exclusive physical nodes and shared physical nodes according to the tenant activity; a slice mapping updating module configured to dynamically update a slice mapping table of a new shared physical node according to the slice utilization and the current resource occupancy.

Images