CN117667170A - Method and system for automatically upgrading Linux kernel perceived by server load - Google Patents

Method and system for automatically upgrading Linux kernel perceived by server load Download PDF

Info

Publication number
CN117667170A
CN117667170A CN202311634044.5A CN202311634044A CN117667170A CN 117667170 A CN117667170 A CN 117667170A CN 202311634044 A CN202311634044 A CN 202311634044A CN 117667170 A CN117667170 A CN 117667170A
Authority
CN
China
Prior art keywords
kernel
upgrade
linux
upgrading
probability
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311634044.5A
Other languages
Chinese (zh)
Inventor
彭青蓝
卢占勇
金勇�
徐锡峰
郑万波
夏云霓
周林
姚鸿泰
晏加元
邱倩
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Henan University
Original Assignee
Henan University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Henan University filed Critical Henan University
Priority to CN202311634044.5A priority Critical patent/CN117667170A/en
Publication of CN117667170A publication Critical patent/CN117667170A/en
Pending legal-status Critical Current

Links

Abstract

The invention discloses a method and a system for automatically upgrading a Linux kernel perceived by a server load, wherein the method comprises the following steps: integrating software package management commands of various Linux release versions: automatically detecting a kernel update at predetermined time intervals; if the software package management tool of the Linux release version detects that the kernel information of the new version is available, downloading the kernel information into a specific catalog; judging whether the load state of the current running environment is suitable for executing kernel upgrade or not by using a naive Bayes algorithm; and receiving a kernel upgrading instruction and executing kernel upgrading. If the invention succeeds in upgrading the kernel, the process context information dumped in the memory is restored and restored. In the case that the second kernel has a problem or the kernel upgrade fails, the system automatically rolls back to the first kernel, so that the time of the kernel upgrade is greatly shortened, and the kernel upgrade is performed without interrupting the user experience.

Description

Method and system for automatically upgrading Linux kernel perceived by server load
Technical Field
The invention relates to the technical field of computers, in particular to a method and a system for automatically upgrading a Linux kernel perceived by a server load.
Background
At present, with the gradual intellectualization of society, artificial intelligence is a hot topic in recent years, and deep learning is an important research field in the field of artificial intelligence. The Linux kernel is a core component of a Linux operating system and is responsible for managing hardware resources and providing operating system services. To cope with the continuously exposed Linux kernel security vulnerabilities, ensuring that a secure version of the Linux kernel is used is critical to the operating system. Meanwhile, as new hardware and software versions continue to evolve, the Linux kernel needs to remain compatible with other system components to avoid conflicts and instabilities. Therefore, periodic upgrades of the kernel are an important task.
Automated kernel upgrades are an advantageous function that can ease the burden on the system administrator and ensure that the system performs the kernel upgrade without interrupting the user experience. The automatic kernel upgrading system can automatically detect the kernel update of the Linux release version in the current running environment, download the kernel of the new version and execute the kernel upgrade of the new version in a proper time period. The new version kernels referred to herein are all the latest kernels of Linux release.
Although some automated kernel upgrade solutions already exist, they are only applicable to specific Linux releases and are not normally used for other releases. Even though some automated kernel upgrade solutions may work on multiple release versions, they lack consistency in implementation, operation, or functionality. The requirement of automatic kernel upgrading of different Linux release versions cannot be met. Furthermore, some existing solutions may interrupt the user experience or create a risk to system stability.
Performing kernel upgrades within the appropriate time period is a key factor in improving user satisfaction. According to CPU utilization rate, memory utilization rate and disk activity, the patent adopts a naive Bayesian algorithm to evaluate the current load state of the server and judges whether the server is in a low-load state suitable for kernel upgrade or not so as to minimize the influence on the load carried by the server.
Disclosure of Invention
The invention aims to provide a method and a system for automatically upgrading a Linux kernel perceived by a server load, which can be suitable for different Linux release versions, automatically detect and update the current Linux release version kernel, execute the kernel upgrade in a proper time period, ensure uninterrupted user experience and improve the stability and the safety of the system.
The invention adopts the technical scheme that:
a method and a system for automatically upgrading a Linux kernel perceived by a server load comprise the following steps:
s1, integrating software package management commands of each Linux distribution version: creating a universal interface for enabling operating systems of different Linux distribution versions to manage software packages using the same commands;
s2, automatically detecting kernel update at a preset time interval: firstly, determining the release version of a Linux operating system in a current running environment, recording attribute information of a current kernel, and then automatically executing kernel update detection at a preset time interval by using a software package management tool of the Linux release version;
s3, if the software package management tool of the Linux release version detects that the new version kernel information is available, downloading the new version kernel information to a specific catalog specifically comprises the following steps: the system will automatically download the new version kernel to a specific directory with an address of/home/kernel local_repo. The related information is recorded in a kernel_auto_config.yml file, and the identifiers of a plurality of kernel versions and the directory structures of corresponding kernels are managed, namely, the identifiers of different kernel versions and the directory structures of corresponding kernels are recorded in the kernel_auto_config.yml file;
s4, judging whether the load state of the current running environment is suitable for executing kernel upgrade or not by using a naive Bayes algorithm;
s5, receiving a kernel upgrading instruction and executing kernel upgrading.
The step S2 specifically comprises the following steps:
first a script is written, which uses the Linux distributed version of the software package management tool to detect if there are updates available in the kernel,
then automatically executing the script at preset time intervals by utilizing the Cron task; the Cron task is a tool used for automatically executing the planning task in Unix and Unix-like operating systems; cron is a time-based job scheduler that allows users to create and manage tasks according to a particular schedule in order to perform these tasks on a particular date or time in the future; a new Cron task needs to be added to the task table of Cron to run the script periodically.
The related information in the step S3 comprises a version number of the kernel, an issue date of the kernel, a download link of the kernel, an issue description of the kernel and a catalog of the kernel.
The step S3 specifically comprises the following steps:
recording the identification of different kernel versions in a kernel_auto_config.yml file, wherein a first kernel is required to be identified as a kernel_current, and the first kernel is a currently used kernel; identifying a second kernel as a kernel_new, wherein the second kernel is a target kernel to be upgraded;
marking the replaced kernel as kernel_previous after the kernel is successfully upgraded, and recording the related information of the three kernels; when a new version of kernel is updated, the new version of kernel needs to be downloaded to a designated directory and is identified as kernel_new; when the kernel_new identifier appears in the kernel_auto_config.yml configuration file, then the next step is entered.
The step S4 also comprises the following steps:
s41, collecting historical data: collecting system load state data under the conditions of performing kernel upgrade and not performing kernel upgrade, wherein the system load state data comprises CPU utilization rate, memory utilization rate and disk activity;
s42, data cleaning and preparation: cleaning and preparing the collected data, including processing missing values and abnormal data to ensure the quality and consistency of the data;
s43, extracting characteristics: extracting relevant features from the dataset, the features typically including CPU usage, memory usage, and disk activity; mapping the historical data of the features into corresponding load state labels for representing different system load states;
s44, calculating probability: the prior probability of performing the kernel upgrade and the prior probability of not performing the kernel upgrade, namely the probability of performing the kernel upgrade and the probability of not performing the kernel upgrade are calculated respectively by utilizing the data set; meanwhile, for each feature, calculating the probability of the feature under the conditions of performing kernel upgrade and not performing kernel upgrade respectively;
s45, judging the load state of the current running environment: according to the classification principle of the naive Bayes algorithm, whether the load state of the current running environment is suitable for executing kernel upgrading is judged by using the known characteristic probability and the prior probability.
The step S45 specifically includes the following steps:
step one, calculating the prior probability of performing the kernel upgrade and the prior probability of not performing the kernel upgrade respectively by utilizing a data set, namely the probability of performing the kernel upgrade and the probability of not performing the kernel upgrade;
step two, calculating the probability of each feature under the conditions of executing the kernel upgrade and not executing the kernel upgrade by utilizing the data set for the feature;
step three, the posterior probability of executing the kernel upgrade and the posterior probability of not executing the kernel upgrade are calculated respectively, namely, the probability of executing the kernel upgrade and the probability of not executing the kernel under the condition of known characteristics;
and step four, selecting whether the load state of the current running environment executes the kernel upgrade or not according to the highest posterior probability.
The step S5 specifically comprises the following steps:
s51: if the load state of the current running environment is judged to be suitable for executing the kernel upgrade, starting to load a second kernel into a specified continuous memory area, storing the process context of the current running environment into the specific memory area, and then performing kernel switching;
s52: once the kernel upgrade is successful, the dumped process context information in the memory is restored;
s53: if the kernel upgrade fails or the second kernel has safety and other problems, the system automatically rolls back to the first kernel; the process of kernel switching does not interrupt the operation of the system. The method greatly shortens the time of the kernel upgrade and executes the kernel upgrade without interrupting the user experience.
In the step S51, the kernel switching is to switch the first kernel to the second kernel: when a kernel upgrading instruction is received, the module firstly loads a second kernel into a continuous memory area, and simultaneously transmits a kernel starting parameter prepared in advance to the second kernel;
after the second kernel is loaded successfully, the module stores the process context of the current running environment into a specific memory area and executes kernel switching operation, namely the first kernel is switched to the second kernel; the switching to the second kernel is to jump to the memory location of the second kernel mirror image, the CPU executes the codes of the entries, and the new kernel starts to initialize the system, including loading the driver, setting the hardware and loading the root file system.
A server load-aware Linux kernel automatic upgrade system comprises:
the kernel information management module is used for integrating software package management commands of various Linux release versions, automatically detecting kernel update at preset time intervals, downloading new version kernels to specific catalogues, and simultaneously managing identifiers of a plurality of kernel versions and catalog structures of corresponding kernels;
the kernel upgrading decision module is used for judging whether the load state of the current running environment of the server is suitable for kernel upgrading or not by using a naive Bayesian algorithm after the new version kernel is stored;
the kernel upgrading module is used for receiving the kernel upgrading instruction and executing kernel upgrading.
The kernel information management module specifically comprises:
the role of the configuration and customization module is to allow the user to customize the behavior of the software package management operations;
the command mapping module is responsible for mapping software package management commands of different Linux release versions and mapping the software package management commands to a unified interface; this includes converting different commands and options so that they can use the same command on different Linux releases;
the software package information acquisition module is used for acquiring metadata and information of the software package and processing information returned by software package management tools of different Linux release versions so as to provide consistent data formats;
the kernel information automatic updating module is used for automatically updating the kernel information;
kernel version control module, which manages the versions of different kernels through one configuration file.
The invention integrates the software package management command of each Linux release. Then, the release version of the Linux operating system of the current running environment is detected, and the characteristics and the attributes of the first kernel are recorded. And automatically performing new version kernel availability information detection within a predetermined time interval. And then judging whether the load state of the current running environment is suitable for executing the kernel upgrade or not through a naive Bayesian algorithm. If so, loading the second kernel into the appointed continuous memory area, and storing the process context of the current running environment into the specific memory area. And finally, performing kernel switching and executing kernel upgrading operation. The kernel upgrade is successful, and the process context information dumped in the memory is restored. In the case that the second kernel has a problem or the kernel upgrade fails, the system automatically rolls back to the first kernel, so that the time of the kernel upgrade is greatly shortened, and the kernel upgrade is performed without interrupting the user experience.
Drawings
In order to more clearly illustrate the embodiments of the invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a flow chart of the present invention;
FIG. 2 is a schematic block diagram of a system according to the present invention;
fig. 3 is a block diagram of the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without any inventive effort, are intended to be within the scope of the invention.
It should be understood that when the terms "first," "second," and the like are used in the claims, specification, and drawings of this application, they are used merely for distinguishing between different objects and not for describing a particular sequential order. The terms "comprises" and "comprising," when used in the specification and claims of this application, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
In order to solve the problems existing in the prior art, the invention provides a method and a system for automatically upgrading a Linux kernel perceived by a server load, so that a user can obtain the safest environment and the best user experience when using different Linux release versions.
The method comprises the following steps:
s1, integrating software package management commands of each Linux distribution version: creating a universal interface for enabling operating systems of different Linux distribution versions to manage software packages using the same commands;
s2, automatically detecting kernel update at a preset time interval: firstly, determining the release version of a Linux operating system in a current running environment, recording attribute information of a current kernel, and then automatically executing kernel update detection at a preset time interval by using a software package management tool of the Linux release version; the step S2 specifically comprises the following steps:
first a script is written, which uses the Linux distributed version of the software package management tool to detect if there are updates available in the kernel,
then automatically executing the script at preset time intervals by utilizing the Cron task; the Cron task is a tool used for automatically executing the planning task in Unix and Unix-like operating systems; cron is a time-based job scheduler that allows users to create and manage tasks according to a particular schedule in order to perform these tasks on a particular date or time in the future; a new Cron task needs to be added to the task table of Cron to run the script periodically.
S3, if the software package management tool of the Linux release version detects that the new version kernel information is available, downloading the new version kernel information to a specific catalog specifically comprises the following steps: the system will automatically download the new version kernel to a specific directory with an address of/home/kernel local_repo. The related information is recorded in a kernel_auto_config.yml file, and the identifiers of a plurality of kernel versions and the directory structures of corresponding kernels are managed, namely, the identifiers of different kernel versions and the directory structures of corresponding kernels are recorded in the kernel_auto_config.yml file; the related information in the step S3 comprises a version number of the kernel, an issue date of the kernel, a download link of the kernel, an issue description of the kernel and a catalog of the kernel. The step S3 specifically comprises the following steps:
recording the identification of different kernel versions in a kernel_auto_config.yml file, wherein a first kernel is required to be identified as a kernel_current, and the first kernel is a currently used kernel; identifying a second kernel as a kernel_new, wherein the second kernel is a target kernel to be upgraded; marking the replaced kernel as kernel_previous after the kernel is successfully upgraded, and recording the related information of the three kernels; when a new version of kernel is updated, the new version of kernel needs to be downloaded to a designated directory and is identified as kernel_new; when the kernel_new identifier appears in the kernel_auto_config.yml configuration file, then the next step is entered.
S4, judging whether the load state of the current running environment is suitable for executing kernel upgrade or not by using a naive Bayes algorithm; the step S4 also comprises the following steps:
s41, collecting historical data: collecting system load state data under the conditions of performing kernel upgrade and not performing kernel upgrade, wherein the system load state data comprises CPU utilization rate, memory utilization rate and disk activity;
s42, data cleaning and preparation: cleaning and preparing the collected data, including processing missing values and abnormal data to ensure the quality and consistency of the data;
s43, extracting characteristics: extracting relevant features from the dataset, the features typically including CPU usage, memory usage, and disk activity; mapping the historical data of the features into corresponding load state labels for representing different system load states;
s44, calculating probability: the prior probability of performing the kernel upgrade and the prior probability of not performing the kernel upgrade, namely the probability of performing the kernel upgrade and the probability of not performing the kernel upgrade are calculated respectively by utilizing the data set; meanwhile, for each feature, calculating the probability of the feature under the conditions of performing kernel upgrade and not performing kernel upgrade respectively;
s45, judging the load state of the current running environment: according to the classification principle of the naive Bayes algorithm, whether the load state of the current running environment is suitable for executing kernel upgrading is judged by using the known characteristic probability and the prior probability. The step S45 specifically includes the following steps:
step one, calculating the prior probability of performing the kernel upgrade and the prior probability of not performing the kernel upgrade respectively by utilizing a data set, namely the probability of performing the kernel upgrade and the probability of not performing the kernel upgrade;
step two, calculating the probability of each feature under the conditions of executing the kernel upgrade and not executing the kernel upgrade by utilizing the data set for the feature;
step three, the posterior probability of executing the kernel upgrade and the posterior probability of not executing the kernel upgrade are calculated respectively, namely, the probability of executing the kernel upgrade and the probability of not executing the kernel under the condition of known characteristics;
and step four, selecting whether the load state of the current running environment executes the kernel upgrade or not according to the highest posterior probability.
S5, receiving a kernel upgrading instruction and executing kernel upgrading. The step S5 specifically comprises the following steps:
s51: if the load state of the current running environment is judged to be suitable for executing the kernel upgrade, loading the second kernel into the appointed continuous memory area, and simultaneously transmitting the kernel starting parameters prepared in advance to the second kernel. The kernel starting parameters comprise the size and starting address of the second kernel loaded into the continuous memory area, and the size and starting address of the process context stored into the specific memory area;
after the second kernel is loaded successfully, the process context of the current running environment is stored in a specific memory area, and kernel switching operation is performed, namely the first kernel is switched to the second kernel; the switching to the second kernel is to jump to the memory location of the second kernel mirror image, the CPU executes the codes of the entries, and the new kernel starts to initialize the system, including loading the driver, setting the hardware and loading the root file system.
S52: once the kernel upgrade is successful, the dumped process context information in the memory is restored;
s53: if the kernel upgrade fails or the second kernel has safety and other problems, the system automatically rolls back to the first kernel; the process of kernel switching does not interrupt the operation of the system. The method greatly shortens the time of the kernel upgrade and executes the kernel upgrade without interrupting the user experience.
The method comprises the steps of integrating software package management commands of each Linux release, then executing Linux release detection, recording the characteristics and the attributes of a first kernel, and automatically executing detection in a preset time interval to determine whether a new version kernel is available. If new kernel version information is detected to be available, the system automatically downloads the new version kernel to a specific directory and manages the identification of multiple kernel versions and the directory structure of the corresponding kernel versions. And then judging whether the load state of the current running environment is suitable for executing the kernel upgrade or not through a naive Bayesian algorithm. If the execution of the kernel upgrade is suitable at this time, the second kernel is loaded into the memory, and the process context of the current running environment is saved to a specific memory area. And finally, performing kernel switching and performing kernel upgrading operation. Once the kernel upgrade is successful, the process context information dumped in memory will be restored. Under the condition that the second kernel has a problem or the kernel upgrading fails, the system automatically rolls back to the first kernel, so that the efficient and quick upgrading can be completed.
As shown in fig. 2, a server load aware Linux kernel automatic upgrade system includes:
the kernel information management module is used for integrating software package management commands of various Linux release versions, automatically detecting kernel update at preset time intervals, downloading new version kernels to specific catalogues, and simultaneously managing identifiers of a plurality of kernel versions and catalog structures of corresponding kernels; the kernel information management module specifically comprises:
the role of the configuration and customization module is to allow the user to customize the behavior of the software package management operations;
the command mapping module is responsible for mapping software package management commands of different Linux release versions and mapping the software package management commands to a unified interface; this includes converting different commands and options so that they can use the same command on different Linux releases;
the software package information acquisition module is used for acquiring metadata and information of the software package and processing information returned by software package management tools of different Linux release versions so as to provide consistent data formats;
the kernel information automatic updating module is used for automatically updating the kernel information;
kernel version control module, which manages the versions of different kernels through one configuration file.
The kernel upgrading decision module is used for judging whether the load state of the current running environment of the server is suitable for kernel upgrading or not by using a naive Bayesian algorithm after the new version kernel is stored;
the kernel upgrading module is used for receiving the kernel upgrading instruction and executing kernel upgrading.
The following is a detailed description with specific examples, and the detailed explanation of the specific operation of each step of the server load-aware Linux kernel automatic upgrade method refers to the module division diagram of fig. 2:
and step 1, integrating software package management commands of each Linux distribution version.
As shown in fig. 3, step 1 corresponds to a software package management integrated module. The module is further divided into a configuration and self-definition module, a software package management command and information module.
The role of the configuration and customization module is to allow the user to customize the behavior of the software package management operations. Such as configuration of the software source, software package storage path, etc.
The software package management command and information module is further divided into a command mapping module and a software package information acquisition module.
The command mapping module is responsible for mapping software package management commands of different Linux release versions and mapping the software package management commands to a unified interface. This includes converting different commands and options so that they can use the same command on different Linux releases.
The software package information acquisition module is used for acquiring metadata and information of the software package, such as software package names, versions, dependency relationships and the like. This module can process the information returned by the software package management tools of different Linux releases to provide a consistent data format.
Finally, the module can manage different Linux release versions through the same command, can customize the configuration of a software package management tool, and returns information in the same format. This helps to simplify package management in a variety of Linux release environments and reduce the workload of administrators.
And step 2, automatically detecting the kernel update at a preset time interval, and downloading the new version of kernel information to a specific directory when the new version of kernel information is available.
As shown in fig. 3, step 2 corresponds to an automatic kernel information update module.
First, information of the current running environment is detected, and Linux release versions of the current running environment, such as Ubuntu, debian, fedora and the like, are determined, namely software package management tools used for determining the current release versions. And then recording the characteristic and attribute information of the first kernel, mainly comprising kernel version, configuration options and the like, archiving the information into a kernel_auto_config.yml file, and identifying the related information of the first kernel as kernel_current.
In order to automatically perform kernel update detection at predetermined time intervals, a script needs to be created first, and the script calls the kernel update detection module and the kernel download module specifically as follows: the available kernel updates are checked using a package management tool, such as apt, yum, dnf, etc., of the Linux-published version of the current running environment. For example, the Ubuntu operating system may use the apt-cache search linux-image command of the apt tool to check for available kernel updates. If the kernel of the new version exists, downloading the kernel of the new version to a specific directory by using an apt update command of an apt tool, identifying the kernel of the new version as kernel_new and recording the kernel of the new version in a kernel_auto_config. The script is automatically executed at predetermined time intervals by using the Cron task. The Cron task is a tool used in Unix and Unix-like operating systems to automatically perform planning tasks. Cron is a time-based job scheduler that allows users to create and manage tasks according to a particular schedule in order to perform these tasks on a particular date or time in the future. A new Cron task needs to be added to the task table of Cron to run the script periodically. And finally, automatically detecting the kernel update at preset time intervals, and downloading the new version of kernel information into a specific directory when the new version of kernel information is available.
And 3, managing the identification of the versions of the plurality of cores and the directory structure of the corresponding cores.
As shown in fig. 3, step 3 corresponds to a kernel version control module.
The module manages versions of different kernels through one configuration file. The kernel_auto_config.yml configuration file has three identifiers, namely kernel_ current, kernel _current and kernel_previous, which respectively identify the first kernel, the second kernel and the related information of the replaced kernel after the kernel is successfully upgraded.
After the kernel with the new version is downloaded to the specific directory, the kernel is identified as kernel_new, and the kernel upgrading scheduling module is utilized to call the kernel switching and rollback module at a preset time interval configured by a user, so that the first kernel is switched to the second kernel.
If the kernel upgrade is successful, the kernel upgrade planning and scheduling module deletes the kernel identified by the kernel_previous by using the kernel version comparison module, and identifies the first kernel as the kernel_previous and the second kernel as the kernel_current.
If the kernel upgrade fails or the second kernel has security and other problems, the first kernel is rolled back, the kernel marked by kernel_previous is not deleted, the first kernel is marked as kernel_current, and the kernel marked by kernel_new is deleted. And finally, the identification of a plurality of kernel versions and the directory structure of the corresponding kernel versions can be managed.
And step 4, judging whether the load state of the current running environment is suitable for executing the kernel upgrade or not by using a naive Bayesian algorithm.
As shown in fig. 3, step 4 corresponds to a kernel upgrade decision module.
First, load state data including CPU usage, memory usage, disk activity, etc. during execution and non-execution of kernel upgrades in historical data is collected by a data collection module.
The data is then cleaned and prepared using the data cleaning module.
Features are extracted from the data, and include CPU usage, memory usage, and disk activity. And converting the specific data into corresponding load state labels. If C represents CPU utilization, M represents memory utilization, and D represents disk activity. The load status tag is divided into: the CPU utilization of 0% -30% is low load, denoted by C1. The CPU usage rate of 30% -70% is the normal load, which is indicated by C2. The CPU usage of 70% -90% is medium load, indicated by C3. The CPU utilization of 90% or more is high load, denoted C4. Overload occurs when the CPU utilization is 100%.
In the same way, we divide memory usage and disk activity into the following five categories: low memory usage (denoted as M1), normal memory usage (denoted as M2), medium memory usage (denoted as M3), high memory usage (denoted as M4), memory starvation, low disk activity (denoted as D1), normal disk activity (denoted as D2), medium disk activity (denoted as D3), high disk activity (denoted as D4), disk busy. The following table is a data set of partial statistics.
And then, the decision module calculates the probability of whether to execute the kernel upgrade under different characteristics to judge whether the load state of the current running environment executes the kernel upgrade.
First, the prior probability of performing the kernel upgrade and the prior probability of not performing the kernel upgrade, that is, the probability of performing the kernel upgrade and the probability of not performing the kernel upgrade are calculated by using the data set, and are denoted as P (Y) and P (N). The formula for calculating P (Y) and P (N) is:
p (Y) =number of kernel upgrades performed/total number of rows of data set
P (N) =number of times no kernel upgrade is performed/total number of rows of data set
Second, the conditional probabilities are calculated using the collected data sets, and for each feature, the probabilities for that feature are calculated under the conditions of performing and not performing a kernel upgrade, respectively. The probability of each feature combining under execution of a kernel upgrade is denoted as P (C1, M1, D1|Y), P (C1, M2, D1|Y), P (C1, M3, D1|Y), P (C1, M4, D1|Y), etc. From these probabilities, the same calculation methods are listed below for the calculation of P (C1, M1, D1|Y) only:
P(C1、M1、D1|Y)=P(C1|Y)×P(M1|Y)×P(D1|Y)
the probability of each feature under the condition that the kernel upgrade is not executed is obtained by the same method:
P(C1、M1、D1|N)=P(C1|N)×P(M1|N)×P(D1|N)
thirdly, the posterior probability of performing the kernel upgrade and not performing the kernel upgrade is calculated by using the load state information in the current running environment, namely, the probability of performing the kernel upgrade and the probability of not performing the kernel under the condition of the known characteristics. If the load state of the current operating environment is characterized by C2, M2, and D2. The formulas for calculating P (y|c2, M2, D2) and P (n|c2, M2, D2) are as follows:
P(Y│C2、M2、D2)=(P(C2、M2、D2|Y)×P(Y))/(P(C2、M2、D2))
P(N│C2、M2、D2)=(P(C2、M2、D2|N)×P(N))/(P(C2、M2、D2))
fourth, by comparing whether P (Y|C2, M2, D2), P (N|C2, M2, D2) performs a kernel upgrade.
If P (Y|C2, M2, D2) is larger than P (N|C2, M2, D2), the kernel upgrade can be executed, and a kernel upgrade instruction is sent to the kernel switching and rollback module. Otherwise, the kernel upgrade is not executed, i.e. the kernel upgrade instruction is not sent to the kernel switching and rollback module.
And step 5, receiving a kernel upgrading instruction and executing kernel upgrading.
As shown in fig. 3, step 5 corresponds to a kernel switch and rollback module. And if a kernel upgrading instruction sent by the kernel upgrading decision is received, starting to call the kernel loading module.
First, the second kernel load identified by kernel_new designates a contiguous memory region that is not managed by the first kernel. When a second kernel is loaded, a kernel starting parameter prepared in advance is transmitted to the second kernel, wherein the kernel starting parameter comprises the size and starting address of the second kernel loaded in a continuous memory area and the size and starting address of a process context stored in a specific memory area;
and then, after the second kernel is loaded successfully, calling a context saving and restoring module to save the process context of the current running environment into a specific memory area. The process context information comprises memory images, file descriptors, network connection information and the like of the process;
and then, after the process context storage of the current running environment is finished, starting to execute the kernel switching module, namely switching the first kernel to the second kernel. The switching to the second kernel is to jump to the memory location where the second kernel mirror image is located, the CPU executes the codes of the entries of the second kernel, and the new kernel starts to initialize the system, including loading the driver, setting the hardware, loading the root file system and the like. The operation of the system is not interrupted in the kernel switching process;
finally, if the first kernel is successfully switched to the second kernel, the stored process context information is read from the specific memory area, and the process is recreated. If the security problem occurs in the case of unsuccessful switching from the first kernel to the second kernel or the second kernel, a kernel rollback module needs to be called to rollback to the first kernel. The method greatly shortens the time of the kernel upgrade and executes the kernel upgrade without interrupting the user experience.
The technical features of the above-described embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above-described embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.
It should be noted that the terms "comprises" and "comprising," along with any variations thereof, in the description and claims of the present application are intended to cover non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed or inherent to such process, method, article, or apparatus, but may include other steps or elements not expressly listed.
Note that the above is only a preferred embodiment of the present invention and uses technical principles. It will be understood by those skilled in the art that the present invention is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the invention. Therefore, while the present invention has been described in connection with the above embodiments, it is to be understood that the invention is not limited to the specific embodiments disclosed and that many other and equally effective embodiments may be devised without departing from the spirit of the invention, and the scope thereof is determined by the scope of the appended claims.

Claims (10)

1. A method and a system for automatically upgrading a Linux kernel perceived by a server load are characterized in that: the method comprises the following steps:
s1, integrating software package management commands of each Linux distribution version: creating a universal interface for enabling operating systems of different Linux distribution versions to manage software packages using the same commands;
s2, automatically detecting kernel update at a preset time interval: firstly, determining the release version of a Linux operating system in a current running environment, recording attribute information of a current kernel, and then automatically executing kernel update detection at a preset time interval by using a software package management tool of the Linux release version;
s3, if the software package management tool of the Linux release version detects that the new version kernel information is available, downloading the new version kernel information to a specific catalog specifically comprises the following steps: the system will automatically download the new version kernel to a specific directory with an address of/home/kernel local_repo. The related information is recorded in a kernel_auto_config.yml file, and the identifiers of a plurality of kernel versions and the directory structures of corresponding kernels are managed, namely, the identifiers of different kernel versions and the directory structures of corresponding kernels are recorded in the kernel_auto_config.yml file;
s4, judging whether the load state of the current running environment is suitable for executing kernel upgrade or not by using a naive Bayes algorithm;
s5, receiving a kernel upgrading instruction and executing kernel upgrading.
2. The method for automatically upgrading a Linux kernel perceived by a server load according to claim 1, wherein: the step S2 specifically comprises the following steps:
first a script is written, which uses the Linux distributed version of the software package management tool to detect if there are updates available in the kernel,
then automatically executing the script at preset time intervals by utilizing the Cron task; the Cron task is a tool used for automatically executing the planning task in Unix and Unix-like operating systems; cron is a time-based job scheduler that allows users to create and manage tasks according to a particular schedule in order to perform these tasks on a particular date or time in the future; a new Cron task needs to be added to the task table of Cron to run the script periodically.
3. The method for automatically upgrading a Linux kernel perceived by a server load according to claim 1, wherein: the related information in the step S3 comprises a version number of the kernel, an issue date of the kernel, a download link of the kernel, an issue description of the kernel and a catalog of the kernel.
4. The method for automatically upgrading a Linux kernel perceived by a server load according to claim 1, wherein: the step S3 specifically comprises the following steps:
recording the identification of different kernel versions in a kernel_auto_config.yml file, wherein a first kernel is required to be identified as a kernel_current, and the first kernel is a currently used kernel;
identifying a second kernel as a kernel_new, wherein the second kernel is a target kernel to be upgraded;
marking the replaced kernel as kernel_previous after the kernel is successfully upgraded, and recording the related information of the three kernels; when a new version of kernel is updated, the new version of kernel needs to be downloaded to a designated directory and is identified as kernel_new; when the kernel_new identifier appears in the kernel_auto_config.yml configuration file, then the next step is entered.
5. The method for automatically upgrading a Linux kernel perceived by a server load according to claim 1, wherein: the step S4 also comprises the following steps:
s41, collecting historical data: collecting system load state data under the conditions of performing kernel upgrade and not performing kernel upgrade, wherein the system load state data comprises CPU utilization rate, memory utilization rate and disk activity;
s42, data cleaning and preparation: cleaning and preparing the collected data, including processing missing values and abnormal data to ensure the quality and consistency of the data;
s43, extracting characteristics: extracting relevant features from the dataset, the features typically including CPU usage, memory usage, and disk activity; mapping the historical data of the features into corresponding load state labels for representing different system load states;
s44, calculating probability: the prior probability of performing the kernel upgrade and the prior probability of not performing the kernel upgrade, namely the probability of performing the kernel upgrade and the probability of not performing the kernel upgrade are calculated respectively by utilizing the data set; meanwhile, for each feature, calculating the probability of the feature under the conditions of performing kernel upgrade and not performing kernel upgrade respectively;
s45, judging the load state of the current running environment: according to the classification principle of the naive Bayes algorithm, whether the load state of the current running environment is suitable for executing kernel upgrading is judged by using the known characteristic probability and the prior probability.
6. The method for automatically upgrading a Linux kernel perceived by a server load according to claim 1, wherein: the step S45 specifically includes the following steps:
step one, calculating the prior probability of performing the kernel upgrade and the prior probability of not performing the kernel upgrade respectively by utilizing a data set, namely the probability of performing the kernel upgrade and the probability of not performing the kernel upgrade;
step two, calculating the probability of each feature under the conditions of executing the kernel upgrade and not executing the kernel upgrade by utilizing the data set for the feature;
step three, the posterior probability of executing the kernel upgrade and the posterior probability of not executing the kernel upgrade are calculated respectively, namely, the probability of executing the kernel upgrade and the probability of not executing the kernel under the condition of known characteristics;
and step four, selecting whether the load state of the current running environment executes the kernel upgrade or not according to the highest posterior probability.
7. The method for automatically upgrading a Linux kernel perceived by a server load according to claim 1, wherein: the step S5 specifically comprises the following steps:
s51: if the load state of the current running environment is judged to be suitable for executing the kernel upgrade, starting to load a second kernel into a specified continuous memory area, storing the process context of the current running environment into the specific memory area, and then performing kernel switching;
s52: once the kernel upgrade is successful, the dumped process context information in the memory is restored;
s53: if the kernel upgrade fails or the second kernel has safety and other problems, the system automatically rolls back to the first kernel; the process of kernel switching does not interrupt the operation of the system. The method greatly shortens the time of the kernel upgrade and executes the kernel upgrade without interrupting the user experience.
8. The method for automatically upgrading a Linux kernel perceived by a server load according to claim 1, wherein: in the step S51, the kernel switching is to switch the first kernel to the second kernel: when a kernel upgrading instruction is received, the module firstly loads a second kernel into a continuous memory area, and simultaneously transmits a kernel starting parameter prepared in advance to the second kernel;
after the second kernel is loaded successfully, the module stores the process context of the current running environment into a specific memory area and executes kernel switching operation, namely the first kernel is switched to the second kernel; the switching to the second kernel is to jump to the memory location of the second kernel mirror image, the CPU executes the codes of the entries, and the new kernel starts to initialize the system, including loading the driver, setting the hardware and loading the root file system.
9. A Linux kernel automatic upgrading system perceived by server load is characterized in that: comprising the following steps:
the kernel information management module is used for integrating software package management commands of various Linux release versions, automatically detecting kernel update at preset time intervals, downloading new version kernels to specific catalogues, and simultaneously managing identifiers of a plurality of kernel versions and catalog structures of corresponding kernels;
the kernel upgrading decision module is used for judging whether the load state of the current running environment of the server is suitable for kernel upgrading or not by using a naive Bayesian algorithm after the new version kernel is stored;
the kernel upgrading module is used for receiving the kernel upgrading instruction and executing kernel upgrading.
10. The server load aware Linux kernel automatic upgrade system of claim 9, wherein: the kernel information management module specifically comprises:
the role of the configuration and customization module is to allow the user to customize the behavior of the software package management operations;
the command mapping module is responsible for mapping software package management commands of different Linux release versions and mapping the software package management commands to a unified interface; this includes converting different commands and options so that they can use the same command on different Linux releases;
the software package information acquisition module is used for acquiring metadata and information of the software package and processing information returned by software package management tools of different Linux release versions so as to provide consistent data formats;
the kernel information automatic updating module is used for automatically updating the kernel information;
kernel version control module, which manages the versions of different kernels through one configuration file.
CN202311634044.5A 2023-12-01 2023-12-01 Method and system for automatically upgrading Linux kernel perceived by server load Pending CN117667170A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311634044.5A CN117667170A (en) 2023-12-01 2023-12-01 Method and system for automatically upgrading Linux kernel perceived by server load

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311634044.5A CN117667170A (en) 2023-12-01 2023-12-01 Method and system for automatically upgrading Linux kernel perceived by server load

Publications (1)

Publication Number Publication Date
CN117667170A true CN117667170A (en) 2024-03-08

Family

ID=90072705

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311634044.5A Pending CN117667170A (en) 2023-12-01 2023-12-01 Method and system for automatically upgrading Linux kernel perceived by server load

Country Status (1)

Country Link
CN (1) CN117667170A (en)

Similar Documents

Publication Publication Date Title
US11108859B2 (en) Intelligent backup and recovery of cloud computing environment
US20060047805A1 (en) Apparatus, system, and method for gathering trace data indicative of resource activity
US8589727B1 (en) Methods and apparatus for providing continuous availability of applications
US20060259594A1 (en) Progressive deployment and maintenance of applications on a set of peer nodes
CN101268620B (en) Device management system and method for managing device management object
US8984108B2 (en) Dynamic CLI mapping for clustered software entities
US20090013321A1 (en) Managing virtual computers
US20170322826A1 (en) Setting support program, setting support method, and setting support device
US8738966B2 (en) Change management system and method
CN115048205B (en) ETL scheduling platform, deployment method thereof and computer-readable storage medium
CN112732674B (en) Cloud platform service management method, device, equipment and readable storage medium
JP2001356912A (en) Install/update/uninstall system of software
CN109218401B (en) Log collection method, system, computer device and storage medium
CN114416200A (en) System and method for monitoring, acquiring, configuring and dynamically managing and loading configuration of declarative cloud platform
JP2008176722A (en) Software operation result management system, method and program
JP2021121921A (en) Method and apparatus for management of artificial intelligence development platform, and medium
CN110971439A (en) Policy decision method and device, system, storage medium, policy decision unit and cluster
EP3591530B1 (en) Intelligent backup and recovery of cloud computing environment
US20080172669A1 (en) System capable of executing workflows on target applications and method thereof
CN112202909B (en) Online upgrading method and system for computer storage system
EP4162649B1 (en) Stable references for network function life cycle management automation
CN117667170A (en) Method and system for automatically upgrading Linux kernel perceived by server load
CN111176959B (en) Early warning method, system and storage medium of cross-domain application server
CN114020368A (en) Information processing method and device based on state machine and storage medium
CN116166413A (en) Lifecycle management for workloads on heterogeneous infrastructure

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination