Service scaling migration system based on data popularity

Abstract

According to the service scaling migration system based on the data popularity, scaling migration is carried out on services in the system by starting from the data used by the services and taking the data popularity as a monitoring index, so that the overall performance of the system is improved; the problem that the CPU utilization rate, the memory utilization rate, the network flow, the disk I / O and the connection number cannot fully reflect the logic level relevance of the resources occupied by the service in the system is solved.

Description

Technical Field

[0001] The present invention relates to the field of distributed systems and microservice technologies, and in particular to a service scaling and migration system based on data popularity. Background Art

[0002] Service scaling and migration are crucial concepts in cloud computing and server management. They are important for ensuring the stability, scalability, and cost-effectiveness of services. The following is a detailed explanation of these two concepts:

[0003] Service scaling definition: Service scaling refers to the ability of the system to dynamically adjust resources according to actual demand. This includes increasing or decreasing computing resources (such as CPU, memory, storage, etc.) to cope with changes in business traffic.

[0004] Service scaling type:

[0005] Automatic scaling: The system automatically adjusts the number of nodes or resource configuration in the cluster according to preset thresholds and rules to adapt to business changes. This method can respond to demand changes in real time and improve resource utilization.

[0006] Manual scaling: Administrators manually add or remove nodes or adjust resource configurations based on business needs. This method has low flexibility but is easy to control and manage.

[0007] Service migration definition: Service migration refers to the process of migrating services from one environment or platform to another. This can be due to a variety of reasons such as changes in business requirements, technology upgrades, cost considerations, etc.

[0008] Service Migration Type:

[0009] Data migration: Migrate business data from one storage system to another.

[0010] Application migration: Migrate an application from one platform to another, such as from a physical server to a virtual machine, or from a virtual machine to a cloud server.

[0011] The prior art implementation method is "Method, system and device for automatic scaling and migration scheduling of containerized microservices" (CN106330576A), which provides a method, system and device for automatic scaling and migration scheduling of containerized microservices. The method includes: receiving warning data generated by containers and / or microservices after fault location; and / or automatic scaling task plan data sent by a third-party platform carrying containers and / or microservices; triggering automatic scaling of containers or fault scheduling transfer.

[0012] Service scaling monitoring indicators are key data used to measure and decide whether cloud service resources should be automatically expanded or reduced to ensure stable application performance and maximize cost-effectiveness. These monitoring indicators usually include the following aspects:

[0013] 1. CPU usage

[0014] Definition: CPU usage reflects the usage of server processing capacity.

[0015] Calculation formula: The total CPU utilization of all CVMs in the scaling group divided by the total number of CPU cores of all CVMs in the scaling group.

[0016] Significance: High CPU utilization may mean that more server resources need to be added to meet demand.

[0017] 2. Memory usage

[0018] Definition: Memory usage reflects the usage of server memory.

[0019] Calculation formula: Calculated by comparing the ratio of used memory to total memory.

[0020] Significance: Excessive memory usage may cause slow system response or failure.

[0021] 3. Network traffic

[0022] Definition: Network traffic indicators monitor the network input and output of the server, including the total amount of inbound and outbound data.

[0023] Significance: It helps to identify network bottlenecks and optimize network configuration, and is important for determining whether computing resources need to be increased or decreased.

[0024] 4. Disk I / O

[0025] Definition: Disk I / O monitors the frequency and volume of disk read and write operations.

[0026] Significance: May affect the performance of disk-intensive applications such as databases.

[0027] 5. Number of connections

[0028] Definition: The connections metric shows the number of active network connections to the server.

[0029] Significance: Helps identify if too many connections are straining system resources.

[0030] These monitoring indicators provide the system with a detailed view of resource usage by collecting and analyzing data in real time. When certain indicators reach preset thresholds, the system can automatically trigger scaling operations, such as increasing or decreasing server instances, to match changes in workload. This automatic scaling mechanism helps optimize resource allocation, improve resource utilization, and ensure business continuity and optimal performance.

[0031] However, in a production environment, the above indicators cannot fully reflect the logical level correlation of resources occupied by services in the system. Therefore, the present invention starts with the data used by the services, uses data heat as a monitoring indicator, and performs scaling and migration of services in the system to improve the overall performance of the system. Summary of the invention

[0032] The purpose of the technical solution of the present invention is to speed up the response time and processing time of service scaling when an abnormality occurs in a microservice, thereby relieving the heavy workload handled by operation and maintenance personnel.

[0033] The technical solution of the present invention provides a service scaling migration system based on data popularity, including:

[0034] A data heat monitoring module monitors data heat and provides corresponding data heat indicators to the service scaling module and the service migration module;

[0035] The service scaling module dynamically scales the expected number of container replicas based on the data heat index and the service scaling algorithm. The service scaling algorithm formula is as follows:

[0036] DesiredReplicas=CurrentReplicas*(svc_freq / svc_norm)

[0037] DesirdReplicas represents the expected number of replicas, CurrentReplicas represents the current number of replicas, svc_freq represents the heat value of the current data heat index, and svc_norm represents the heat threshold. When svc_freq exceeds the threshold, the expected number of replicas increases according to the ratio of svc_freq exceeding the threshold, triggering horizontal expansion. When svc_freq is less than the threshold, the expected number of replicas decreases according to the ratio of svc_freq less than the threshold, triggering horizontal contraction.

[0038] The service migration module evaluates the IO load of related nodes according to the service migration algorithm based on the data heat index to decide whether to perform service migration. The service migration algorithm includes:

[0039] If the heat value of the current data heat index is less than the heat threshold, the node IO load is small and no processing is performed;

[0040] If the heat value of the current data heat index is greater than the heat threshold, whether to migrate the service is determined based on whether the ratio of the heat value of the current data heat index exceeding the heat threshold is greater than the upper limit of the excess ratio;

[0041] If the heat value of the current data heat index exceeds the heat threshold by a ratio that exceeds the upper limit of the excess ratio, the node IO is determined to be overloaded and service migration is triggered;

[0042] If it is less than the upper limit of the excess ratio, the node IO load fluctuation is within the warning range, and only logs need to be recorded without migrating services.

[0043] Preferably, the data heat monitoring module relies on a resource monitoring tool to monitor the data heat. The resource monitoring tool sorts the collected heat data in a time series manner, and filters it in combination with a label set, abstracting a monotonically increasing metric indicator, and monitoring the number of times the storage system object is requested based on the metric indicator, and taking the slope of the number of times the storage system object is requested to time as the data heat indicator.

[0044] Preferably, the time series is named by an indicator name and a set of label sets, each point in the time series is taken as a sample, the sample consists of an indicator, a timestamp and a sample value, the indicator is described by the indicator name and the label set, and the samples with the same indicator name are filtered by the label set.

[0045] Preferably, the metrics include meter metrics, instrument metrics, histogram metrics and total metrics.

[0046] Preferably, the data heat index is tagged with a label of the disk and container application of the corresponding placement group, and the hot disks and services are determined based on label aggregation, and the aggregation results are named disk_freq and svc_freq.

[0047] Preferably, the horizontal expansion and the horizontal contraction are implemented by a telescoping controller.

[0048] Preferably, the service migration module container migration trigger points include hardware upgrade or failure, data center change, and outdated operating system.

[0049] The technical solution of the present invention proposes a service scaling and migration system based on data heat. Starting from the data used by the service and taking data heat as a monitoring indicator, the services in the system are scaled and migrated to improve the overall performance of the system, solving the problem that CPU utilization, memory utilization, network traffic, disk I / O and number of connections cannot fully reflect the logical level correlation of resources occupied by services in the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1A schematic diagram of a service scaling and migration system based on data popularity provided by an embodiment of the present invention;

[0051] Figure 2 A schematic diagram of a resource monitoring tool provided by an embodiment of the present invention;

[0052] Figure 3 A schematic diagram of a service scaling module provided in an embodiment of the present invention;

[0053] Figure 4 A schematic diagram of container migration provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0054] The present invention will be further described below in conjunction with specific embodiments. It should be understood that these embodiments are only used to illustrate the present invention and are not intended to limit the scope of the present invention. In addition, it should be understood that after reading the content taught by the present invention, those skilled in the art can make various changes or modifications to the present invention, and these equivalent forms fall within the scope limited by the appended claims of the application equally.

[0055] like Figure 1 As shown, an embodiment of the present invention provides a service scaling and migration system based on data heat, including three modules: a data heat monitoring module, a service scaling module, and a service migration module. Among them, the data heat monitoring module monitors data heat and provides the corresponding data heat index to the service scaling module and the service migration module. The service scaling module calculates the expected number of container replicas dynamically based on the index according to the service scaling algorithm, and the service migration module evaluates the IO load of the relevant nodes according to the service migration algorithm based on the index to decide whether to perform service migration. The modules are specifically as follows:

[0056] The data heat monitoring module mainly relies on the resource monitoring tool to monitor the corresponding data heat, and saves the collected heat data in the memory database in the form of time series, and saves it to the hard disk at regular intervals. Each time series is named by the indicator name and a set of label sets. The sample consists of three parts: indicator, timestamp and sample value. The indicator is described by the indicator name and a set of optional label sets. The label set can further filter the samples with the same indicator name. The resource monitoring tool abstracts the meter's metric indicators to help developers extract the key indicators of the application. The meter indicator is a metric indicator that can only increase monotonically and cannot decrease. Once the application sets such an indicator, the indicator will continue to increase the count unless the application is restarted. The resource monitoring tool meter type metric indicator can monitor the number of requests for storage system objects. The slope of the calculation number of times to time is the number of requests per second for the object obj_qps. This indicator is used to confirm the hot data of the storage system and provide a basis for subsequent service scaling and migration decisions.

[0057] like Figure 2 As shown in the figure, the core function of the resource monitoring tool is to save the collected sample data in the memory database in the form of time series, and save it to the hard disk at a fixed time. A time series is a set of values ​​stored in the order of timestamps and values, also known as a vector. Each time series is named by the indicator name and a set of label sets. Each point in the time series is called a sample, and the sample consists of three parts: indicator, timestamp, and sample value. The indicator is described by the indicator name and a set of optional label sets. The label set can be used to further filter samples with the same indicator name. The timestamp is a millisecond precision data, and the sample value is a float64 type value.

[0058] Resource monitoring tools abstract four core metrics to help developers extract the key metrics of applications, namely meters, gauges, histograms, and totals. A meter is a metric that can only increase monotonically and cannot decrease. Once an application sets such a metric, the metric will continue to increase unless the application is restarted. For example, the number of requests for data access should be increased by 1 for each request. Meter-type metrics can be increased or decreased. For example, the CPU, memory, IO and other resources consumed by an application will show an upward and downward trend as the application workload changes. The current state of the application can be reflected through the meter metrics. Histograms and totals can group metric data according to values, which is equivalent to placing the results in different buckets, so as to understand the distribution of monitoring samples. For example, for an application response time over a period of time, most of the time it may be less than 250ms, while the response time of individual requests may reach more than 3s. At this time, if the average response time of the application is counted, the overall response time will be increased because the response time of individual requests is too long. The two metrics, histograms and totals, will be grouped according to certain quantiles based on the response time. For example, the application response time quantile is 0.25, and these two indicators will count the number of requests with a response time between 0 and 250ms.

[0059] Data heat index, object access frequency obj_qps: the number of times an object is requested per second. The resource monitoring tool meter type metric can be used to monitor the number of times a storage system object is requested. The slope of the number of times to time is the number of times an object is requested per second. This metric is used to confirm the hot data of the storage system and provide a basis for subsequent service scaling and migration decisions. In addition, this metric can also be tagged with the placement group disk and container application. According to the corresponding tag aggregation, the hot disk and service can be determined, and the aggregation results are named disk_freq and svc_freq.

[0060] like Figure 3As shown in the figure, the service scaling module is designed based on the service level automatic scaling mechanism of the container scheduling framework, which mainly includes scaling controller, data heat monitoring, resource monitoring tool and resource monitoring tool agent. Horizontal scaling represents the change in the size of nodes or services. When the container scheduling framework container corresponding to the application usage load changes greatly, there needs to be a way to automatically add and remove container copies. The scaling controller is the method of automatically scaling containers provided by the container scheduling framework, which will automatically scale the number according to the application load. The scaling controller is useful for both stateless and stateful application workloads. The scaling controller is managed by the container scheduling framework control manager and runs in a control loop. In each loop detection, the control manager will compare the actual resource usage with each indicator definition. The scaling controller uses the data heat indicator to determine dynamic scaling.

[0061] The design of the service scaling module is based on the container horizontal automatic scaling mechanism of the container scheduling framework. The focus of onboard applications is different. The use of the automatic scaling v1 version of the scaling controller cannot meet the QOS of the application. Custom indicators must be used, that is, the automatic scaling v2 version of the scaling controller is used. The service scaling module mainly includes the scaling controller module, the data heat monitoring module, the resource monitoring tool module and the resource monitoring tool agent module.

[0062] Horizontal scaling refers to changes in the size of nodes or services. When the load of the container corresponding to the application in the container scheduling framework changes significantly, there needs to be a way to automatically add and remove container copies. The scaling controller is a method for automatically scaling containers provided by the container scheduling framework. Once the scaling controller is configured, the container service will automatically scale up or down in number according to the application load.

[0063] The scaling controller is useful for both stateless and stateful application workloads. The scaling controller is managed by the container scheduling framework control manager and runs in a control loop. The control manager provides a flag to specify the period of the scaling controller assembly cycle, which is synchronized every 15 seconds by default. For each cycle detection, the control manager compares the actual resource usage with the indicator definition configured for each scaling controller. The scaling controller uses indicators to determine automatic scaling, as shown below:

[0064] 1. For resource indicators, you can set a target utilization value or a fixed target.

[0065] 2. For custom indicators, only raw values ​​are supported and target utilization cannot be defined.

[0066] 3. For both object metrics and external metrics, scaling is based on a single metric obtained from the object, which is compared to the target value to produce a utilization ratio.

[0067] By setting an appropriate threshold svc_norm based on the service indicator svc_freq returned by the data heat monitoring module, service scaling based on threshold control can be achieved. The service scaling algorithm formula is as follows:

[0068] DesiredReplicas=CurrentReplicas*(svc_freq / svc_norm)

[0069] DesirdReplicas represents the expected number of replicas, CurrentReplicas represents the current number of replicas, svc_freq represents the current heat value, and svc_norm represents the heat threshold. If svc_freq exceeds the threshold, the expected number of replicas will increase according to the ratio of svc_freq exceeding the threshold, triggering the scaling controller to scale out horizontally. If svc_freq is less than the threshold, the expected number of replicas will decrease according to the ratio of svc_freq less than the threshold, triggering the scaling controller to scale out horizontally.

[0070] The service migration module mainly evaluates the IO load of related nodes according to the service migration algorithm based on the data heat index to decide whether to perform service migration. Container service migration is inevitable in many cases. Hardware upgrades or failures, data center changes, outdated operating systems, all of these may become triggers for migration. Container migration is usually part of a migration task. Common methods for migrating containers from an existing server to another server mainly include exporting and importing containers, container image migration, saving and loading images, and other methods.

[0071] Container migration is inevitable in many cases. Hardware upgrades or failures, data center changes, outdated operating systems, all of these can be triggers for migration. Container migration is often part of a migration task, such as Figure 4 As shown, the following describes different ways to migrate containers from an existing server to another server.

[0072] 1. Export and import containers. The steps are as follows:

[0073] (1) Exporting a container means creating a compressed file from the container's file system. The exported file is saved as a "gzip" file.

[0074] (2) The compressed file is then copied to the new server via a file transfer tool such as scp or rsync. In the new server, this gzip file is then imported into a new container.

[0075] (3) You can use the container run command to access the new container created in the new server.

[0076] 2. Container image migration, the steps are as follows:

[0077] (1) First, use the container submission command to save its container image into a compressed file.

[0078] (2) The generated image will be compressed and uploaded to the new server, where a new container will be created using the container run command.

[0079] 3. Save and load the image. The steps are as follows:

[0080] (1) Use the container save command to compress the image and migrate it to the new server.

[0081] (2) On the new server, use the container load command to use the compressed image file to create a new image.

[0082] According to the service indicator disk_freq returned by the data heat monitoring module, an appropriate threshold disk_norm and abnormal ratio alert_rate are set, so that service migration that supports threshold control and abnormal handling can be achieved. The algorithm code is as follows:

[0083]

[0084] disk_freq represents the current heat value, disk_norm represents the heat threshold, out_rate represents the ratio of the current heat value exceeding the threshold, and alert_rate represents the upper limit of the excess ratio. If disk_freq is less than disk_norm, it means that the node IO load is small and does not affect the services running on this node, so no processing is performed. If disk_freq is greater than disk_norm, whether the service migration is determined based on whether the ratio of disk_freq exceeding disk_norm, out_rate, is greater than alert_rate. If out_rate exceeds alert_rate, the node IO is determined to be overloaded, which may affect the container service running on this node and trigger service migration. If it is less than alert_rate, it means that the node IO load fluctuation is within the warning range, and only logs need to be recorded without migrating services.

[0085] 1. The significance of data heat index for service scaling

[0086] Optimize resource allocation:

[0087] Data heat indexes can reflect the access frequency and importance of data. Based on these indicators, the system can automatically adjust resource allocation to ensure that high-heat data receives sufficient resource support while preventing low-heat data from occupying too many resources.

[0088] For example, for hot data with high access frequency and high importance, the system can increase storage and computing resources to ensure fast access and processing of data; while for cold data with low access frequency and low importance, resource allocation can be reduced to reduce costs.

[0089] Improve system performance:

[0090] Through the data heat index, the system can identify which data is frequently accessed and cache this data on high-performance storage devices to reduce access latency.

[0091] At the same time, the system can also adjust the allocation of computing resources based on data heat indicators to ensure that sufficient computing power can be provided during high-concurrency access, thereby avoiding system crashes or performance degradation.

[0092] Reduce costs:

[0093] The data heat index helps the system identify which data has not been accessed for a long time, so that the data can be migrated to low-cost storage devices to save storage costs.

[0094] In addition, by optimizing resource allocation, the system can also avoid unnecessary waste of resources and further reduce costs.

[0095] 2. The significance of data heat index for service migration

[0096] To guide data migration decisions:

[0097] The data heat index can serve as an important basis for data migration decisions. Based on the heat of the data, the system can decide which data needs to be migrated first, which data can be migrated later or left in place.

[0098] For example, for high-temperature data, the system can prioritize migrating it to high-performance, high-reliability storage devices; while for low-temperature data, it can be migrated to low-cost, low-reliability storage devices.

[0099] Optimize data migration strategy:

[0100] Data heat index can also help the system optimize data migration strategies. For example, for frequently accessed data, the system can use incremental migration to migrate only newly added or updated data; while for rarely accessed data, full migration can be used to migrate the data to the target device at one time.

[0101] Ensure data consistency:

[0102] During the data migration process, data heat indicators can also help the system identify which data is being accessed, thereby avoiding data inconsistency or loss during the migration process.

[0103] For example, when migrating hot data, the system can suspend access to the data or take other measures to ensure data consistency.

[0104] In summary, data heat index is of great significance in service scaling and migration. It can not only help the system optimize resource allocation, improve system performance, and reduce costs, but also guide data migration decisions, optimize data migration strategies, and ensure data consistency. Therefore, when performing service scaling and migration, the impact of data heat index should be fully considered.

[0105] When an abnormality occurs in a microservice, the embodiment of the present invention speeds up the response time and processing time of service scaling, relieves the operation and maintenance personnel of the heavy workload, effectively controls the uncontrollable risks brought by manual processing of service scaling, reduces the operation and maintenance costs of the enterprise, and effectively speeds up the enterprise promotion of system containerized microservice transformation; it solves the limitations of the container shrinking strategy, expands the diversity and mechanism of containerized microservice scaling, accurately locates the real fault point through fault conduction analysis of the entire call chain, and achieves accurate scaling of containerized microservices.

Claims

1. A service scaling migration system based on data popularity, characterized in that: include: A data heat monitoring module monitors data heat and provides corresponding data heat indicators to the service scaling module and the service migration module; The service scaling module dynamically scales the expected number of container replicas based on the data heat index and the service scaling algorithm. The service scaling algorithm formula is as follows: DesiredReplicas=CurrentReplicas*(svc_freq / svc_norm) DesirdReplicas represents the expected number of replicas, CurrentReplicas represents the current number of replicas, svc_freq represents the heat value of the current data heat index, and svc_norm represents the heat threshold. When svc_freq exceeds the threshold, the expected number of replicas increases according to the ratio of svc_freq exceeding the threshold, triggering horizontal expansion. When svc_freq is less than the threshold, the expected number of replicas decreases according to the ratio of svc_freq less than the threshold, triggering horizontal contraction. The service migration module evaluates the IO load of related nodes according to the service migration algorithm based on the data heat index to decide whether to perform service migration. The service migration algorithm includes: If the heat value of the current data heat index is less than the heat threshold, the node IO load is small and no processing is performed; If the heat value of the current data heat index is greater than the heat threshold, whether to migrate the service is determined based on whether the ratio of the heat value of the current data heat index exceeding the heat threshold is greater than the upper limit of the excess ratio; If the heat value of the current data heat index exceeds the heat threshold by a ratio that exceeds the upper limit of the excess ratio, the node IO is determined to be overloaded and service migration is triggered; If it is less than the upper limit of the excess ratio, the node IO load fluctuation is within the warning range, and only logs need to be recorded without migrating services.

2. A service scaling migration system based on data popularity as claimed in claim 1, characterized in that: The data heat monitoring module relies on the resource monitoring tool to monitor the data heat. The resource monitoring tool sorts the collected heat data in a time series manner, and filters it in combination with the label set, abstracting a monotonically increasing metric indicator, and monitoring the number of times the storage system object is requested based on the metric indicator, and taking the slope of the number of times the storage system object is requested to time as the data heat indicator.

3. A service scaling migration system based on data popularity as claimed in claim 2, characterized in that: The time series is named by an indicator name and a set of label sets. Each point in the time series is taken as a sample. The sample consists of an indicator, a timestamp and a sample value. The indicator is described by the indicator name and the label set. The samples with the same indicator name are filtered by the label set.

4. A service scaling migration system based on data popularity as claimed in claim 2, characterized in that: The metrics include meter metrics, instrument metrics, histogram metrics and total metrics.

5. The service scaling migration system based on data popularity as claimed in claim 2, characterized in that: The data heat index is labeled with the disk of the placement group and the container application to which it belongs, and the hot disks and services are determined based on the label aggregation, and the aggregation results are named disk_freq and svc_freq.

6. The service scaling migration system based on data popularity as claimed in claim 1, characterized in that: The horizontal expansion and the horizontal contraction are implemented by a telescoping controller.

7. The service scaling migration system based on data popularity as claimed in claim 1, characterized in that: The service migration module container migration trigger points include hardware upgrade or failure, data center change, and outdated operating system.

Images