OSD process upgrading method and device, equipment and storage medium
By using Unix domain sockets and preset data transfer technology to synchronize OSD process data in a distributed storage system, process upgrades were achieved without affecting client operation, resolving issues caused by OSD process restarts and improving system stability and performance.
Patent Information
- Application Number
- CN202511261382.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-04
- Publication Date
- 2025-11-21
AI Technical Summary
When performing online hot upgrades on mainstream distributed storage systems, OSD process restarts can cause problems such as client connection interruptions, PG re-peering, memory state loss, business interruptions, increased service latency, and decreased cache hit rate.
The old OSD process's file descriptor is sent to the new OSD process using a Unix domain socket. Process data is synchronized using a preset data transfer technique. A connection is established between the new OSD process and the client. Synchronization is performed using data synchronization methods and process data until the old OSD process and the new OSD process are consistent, at which point the old OSD process stops running.
It enables OSD process upgrades to be completed without affecting the client's running status, ensuring data security and solving problems such as client connection interruption, PG re-peering, memory state loss, increased service latency, and decreased cache hit rate caused by traditional hot upgrades. This improves the competitiveness of distributed storage and the customer's user experience.
Smart Images
Figure CN120994630A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of distributed storage, in particular to an OSD process upgrading method, device, equipment and storage medium. BACKGROUND
[0002] The current mainstream distributed storage system will restart the OSD (Object Storage Daemon, object storage unit) process when performing online hot upgrading, which causes the client connection to be interrupted, that is, the TCP (Transmission Control Protocol, a connection-oriented and reliable transport layer communication protocol) session is disconnected, the PG (Placement Group, logical placement group) is re-peered, the service interruption caused by the loss of memory state, the increase of service delay, the decrease of cache hit rate and other problems.
[0003] It can be seen that how to realize OSD process upgrading without affecting the running state of the client and ensure the safety of data is a problem to be solved by those skilled in the art. SUMMARY
[0004] The embodiment of the present application aims to provide an OSD process upgrading method, device, equipment and storage medium, which can realize OSD process upgrading without affecting the running state of the client and ensure the safety of data. The specific scheme is as follows:
[0005] In a first aspect, the present application discloses an OSD process upgrading method, comprising:
[0006] The file descriptor of the old OSD process is sent to the new OSD process by using the Unix domain Socket; the new OSD process includes the process configuration of the old OSD process;
[0007] The process data received by the old OSD process is synchronized to the new OSD process by using a preset data transmission technology, and the connection between the new OSD process and the client is established through the file descriptor, so that the old OSD process and the new OSD process are run simultaneously;
[0008] The old OSD process and the new OSD process are subjected to process synchronization operation by using the data synchronization method and the process data, and when the old OSD process and the new OSD process run consistently, the running of the old OSD process is stopped based on a termination instruction, so as to complete the OSD process upgrading.
[0009] Optionally, the file descriptor of the old OSD process is sent to the new OSD process by using the Unix domain Socket, comprising:
[0010] The new OSD process is started, and the process configuration of the old OSD process is loaded into the new OSD process.
[0011] creating a Unix domain Socket, and using SO_REUSEPORT in the Unix domain Socket to control the old OSD process to enter TCP_REPAIR mode to extract file descriptors from the old OSD process;
[0012] sending the file descriptors to the new OSD process by using the Unix domain Socket;
[0013] Correspondingly, the connection between the new OSD process and the client is established by using the file descriptors, so as to run the old OSD process and the new OSD process simultaneously, including:
[0014] using SO_REUSEPORT in the Unix domain Socket and the file descriptors to establish the connection between the new OSD process and the client, and controlling the old OSD process to exit the TCP_REPAIR mode, so as to run the old OSD process and the new OSD process simultaneously.
[0015] Optionally, the process data received by the old OSD process is synchronized to the new OSD process by using a preset data transmission technology, including:
[0016] synchronizing the data packets in the old OSD process to the cache queue of the new OSD process by using a preset real-time mirroring technology;
[0017] synchronizing the cache data in the old OSD process to the new OSD process by using a CRIU tool and a preset shared memory mapping technology;
[0018] synchronizing the log data in the old OSD process to the new OSD process by using a double-write log architecture.
[0019] Optionally, the data packets in the old OSD process are synchronized to the cache queue of the new OSD process by using a preset real-time mirroring technology, including:
[0020] sending the target data packet to the new OSD process by using a preset programming interface; the target data packet is a data packet obtained by copying the to-be-processed data packet obtained from the client by the old OSD process;
[0021] storing the to-be-processed data packet into a preset cache queue by using the new OSD process and based on the sequence number of the to-be-processed data packet;
[0022] Correspondingly, the process synchronization operation is performed on the old OSD process and the new OSD process by using the data synchronization method and the process data, and when the old OSD process and the new OSD process run consistently, the running of the old OSD process is stopped based on a termination instruction, including:
[0023] Inject the data packet to be processed into a preset protocol stack based on the serial number for data processing by using the new OSD process to generate a first confirmation signal;
[0024] Send the first confirmation signal to the old OSD process by the new OSD process, and generate a second confirmation signal after the data packet to be processed is completely processed;
[0025] Stop the running of the old OSD process based on the second confirmation signal.
[0026] Optionally, the cached data in the old OSD process is synchronized to the new OSD process by using a CRIU tool and a preset shared memory mapping technology, including:
[0027] Dirty page tracking is started in the old OSD process by using the CRIU tool to obtain the cached data, and a preset memory is created to store the cached data;
[0028] The memory snapshot of the old OSD process is taken, and the cached data is updated in real time by using the incremental dirty page;
[0029] Correspondingly, the process synchronization operation of the old OSD process and the new OSD process is performed by using the data synchronization method and the process data, including:
[0030] The new OSD process is replied by using the memory snapshot, the preset memory is injected into the new OSD process, and the cached data in the preset memory is synchronized and updated in real time by using the incremental dirty page.
[0031] Optionally, the log data in the old OSD process is synchronized to the new OSD process by using a double-write log architecture, including:
[0032] All write operations are written into the local WAL and the incremental log stream by using the old OSD process, and the incremental log stream is shared into the new OSD process by using a preset memory sharing mode;
[0033] Correspondingly, the process synchronization operation of the old OSD process and the new OSD process is performed by using the data synchronization method and the process data, and the running of the old OSD process is stopped based on a termination instruction when the old OSD process and the new OSD process run consistently, including:
[0034] All write operations in the incremental log stream are stored into a preset log cache area by the new OSD process;
[0035] The old OSD process is frozen to stop obtaining the write operation, and the new OSD process is registered to a monitoring unit;
[0036] The process address of the new OSD process is broadcasted by using the monitoring unit, so that the client automatically redirects the request to the new OSD process based on the process address.
[0037] Optionally, the process address of the new OSD process is broadcasted by the monitoring unit, so that the client automatically redirects the request to the new OSD process based on the process address, and the method comprises the following steps:
[0038] The consistency of the log information in the new OSD process and the old OSD process is judged by using the scrub check.
[0039] If the log information in the new OSD process and the old OSD process is inconsistent, the difference log data between the new OSD process and the old OSD process is determined, and the difference log data is written into the new OSD process.
[0040] In a second aspect, the application discloses an OSD process upgrading device, which comprises:
[0041] A file descriptor sending module is configured to send the file descriptor of the old OSD process to the new OSD process by using the Unix domain socket; the new OSD process comprises the process configuration of the old OSD process.
[0042] A data sending module is configured to synchronize the process data received by the old OSD process to the new OSD process by using a preset data transmission technology, and establish the connection between the new OSD process and the client by using the file descriptor, so that the old OSD process and the new OSD process are simultaneously run.
[0043] A process synchronization module is configured to perform the process synchronization operation on the old OSD process and the new OSD process by using the data synchronization method and the process data, and stop the running of the old OSD process based on the termination instruction when the old OSD process and the new OSD process are consistent, so as to complete the OSD process upgrading.
[0044] In a third aspect, the application discloses an electronic device, which comprises:
[0045] A memory is configured to save a computer program.
[0046] A processor is configured to execute the computer program to realize the OSD process upgrading method.
[0047] In a fourth aspect, the application discloses a computer readable storage medium, which is configured to save a computer program, and the computer program is executed by a processor to realize the OSD process upgrading method.
[0048] It can be seen that, in the application, the file descriptor of the old OSD process is sent to the new OSD process by using the Unix domain Socket, the process configuration of the old OSD process is contained in the new OSD process, the process data received by the old OSD process is synchronized to the new OSD process by using a preset data transmission technology, the connection between the new OSD process and the client is established through the file descriptor, the old OSD process and the new OSD process are simultaneously run, the process synchronization operation is performed on the old OSD process and the new OSD process by using the data synchronization method and the process data, and when the old OSD process and the new OSD process run consistently, the running of the old OSD process is stopped based on a termination instruction, so as to complete the OSD process upgrade.
[0049] That is, by using the new OSD process to obtain the file descriptor of the old OSD process and establish the connection with the client, and by using the preset data transmission technology to synchronize the process data in the old OSD process to the new OSD process, the client and the process data are both migrated from the old OSD process to the upgraded new OSD process, which can solve the problems of client connection interruption, PG re-peering, service interruption caused by memory state loss, service delay increase, and cache hit rate decrease caused by restarting the OSD process during the traditional hot upgrade, and effectively improve the competitiveness of the distributed storage and the customer experience. BRIEF DESCRIPTION OF DRAWINGS
[0050] In order to more clearly illustrate the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.
[0051] Figure 1 A flow chart of an OSD process upgrade method disclosed by the present application is shown in FIG. 1.
[0052] Figure 2 A flow chart of a double-write log disclosed by the present application is shown in FIG. 2.
[0053] Figure 3 A flow chart of a specific OSD process upgrade method disclosed by the present application is shown in FIG. 3.
[0054] Figure 4 A flow chart of a specific OSD process upgrade method disclosed by the present application is shown in FIG. 4.
[0055] Figure 5 A structure schematic diagram of an OSD process upgrade device disclosed by the present application is shown in FIG. 5.
[0056] Figure 6 A structure diagram of an electronic device disclosed by the present application is shown in FIG. 6. DETAILED DESCRIPTION
[0057] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all the other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.
[0058] The terms "comprising" and "having" and any variations thereof in the specification and above drawings of the present application are intended to cover the inclusion not an exclusive inclusion. For example, a process, method, system, product or device including a series of steps or units is not limited to the listed steps or units, but can include steps or units not listed.
[0059] In order for those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the drawings and specific embodiments.
[0060] When the distributed storage system is online hot upgraded, the OSD process needs to be restarted, which will cause the client connection to be interrupted, the PG to be re-peered, the service interruption caused by the loss of memory state, the increase of service delay, the decrease of cache hit rate and other problems. The present application will specifically introduce an OSD process upgrading method, which can solve the above problems.
[0061] Referring to Figure 1 The present application discloses an OSD process upgrading method, which comprises the following steps:
[0062] Step S11: The file descriptor of the old OSD process is sent to the new OSD process by using the Unix domain Socket; the new OSD process contains the process configuration of the old OSD process.
[0063] In the present embodiment, the TCP connection is completely migrated from the old OSD process to the new OSD process without interrupting the client session, so as to realize the "zero-awareness" upgrading. The Socket file descriptor fd can be hijacked by using the SO_REUSEPORT+TCP_REPAIR option. The SO_REUSEPORT allows the new and old processes to bind the same IP and the same port, which is used to realize the port sharing of the new and old OSD processes; the TCP_REPAIR allows the user to finely operate the TCP state.
[0064] That is, the file descriptor of the old OSD process is sent to the new OSD process by using the Unix domain Socket, including: starting the new OSD process, and loading the process configuration of the old OSD process into the new OSD process; creating a Unix domain Socket, and using the SO_REUSEPORT in the Unix domain Socket to control the old OSD process to enter the TCP_REPAIR mode, so as to extract the file descriptor from the old OSD process; sending the file descriptor to the new OSD process by using the Unix domain Socket. Specifically, the old OSD enters the TCP_REPAIR mode: freezing the connection, pausing the data transmission and reception, and buffering the new request. The specific code is as follows:
[0065] .
[0066] Then, the connection parameters of the old OSD are extracted from the kernel to obtain the corresponding file descriptor:
[0067] .
[0068] Then, the file descriptor fd of the old OSD process is sent to the new OSD process by using the Unix domain Socket:
[0069] .
[0070] In this way, the port sharing of the old and new OSD processes can be realized. It should be noted that the process configuration of the new OSD process contains the process configuration of the old OSD process, which is the upgraded OSD process.
[0071] Step S12: synchronizing the process data received by the old OSD process to the new OSD process by using the preset data transmission technology, and establishing the connection between the new OSD process and the client by using the file descriptor, so as to simultaneously run the old and new OSD processes.
[0072] In this embodiment, in order to ensure that the data packets sent by the client are not lost during the TCP connection migration process, and the connection state is consistent after migration; to realize the sub-second freezing, accurate migration and lossless recovery of the OSD process running memory state, and to guarantee zero interruption of business, zero loss of cache and strong consistency of data during upgrading; the preset data transmission technology is needed to share the data packets, cache data and log data in the old OSD process to the new OSD process. That is, the process data received by the old OSD process is synchronized to the new OSD process by using the preset data transmission technology, including: synchronizing the data packets in the old OSD process to the cache queue of the new OSD process by using the preset real-time mirroring technology; synchronizing the cache data in the old OSD process to the new OSD process by using the CRIU tool and the preset shared memory mapping technology; and synchronizing the log data in the old OSD process to the new OSD process by using the double-write log architecture.
[0073] After the data is shared, the connection between the new OSD process and the client needs to be established through the file descriptor, so as to run the old OSD process and the new OSD process simultaneously, including: using SO_REUSEPORT in the Unix domain Socket and the file descriptor to establish the connection between the new OSD process and the client, and controlling the old OSD process to exit the TCP_REPAIR mode, so as to run the old OSD process and the new OSD process simultaneously. That is, the new OSD process rebuilds the TCP state, including: sequence number, window size, timestamp, etc.
[0074] .
[0075] Then, the freeze is released and the communication is resumed:
[0076] .
[0077] Step S13: using the data synchronization method and the process data to perform process synchronization operation on the old OSD process and the new OSD process, and stopping the running of the old OSD process based on the termination instruction when the old OSD process and the new OSD process run consistently, so as to complete the OSD process upgrade.
[0078] In this embodiment, the specific operation process of sharing the data packet, the cache data and the log data in the old OSD process to the new OSD process will be described respectively.
[0079] Firstly, when sharing data packets, a double buffering mirror technology is mainly used. After the migration starts, the old OSD mirrors all received data packets to the new OSD in real time to achieve a similar soft RAID0 effect. The new OSD caches the mirrored packets until the state recovery is completed. After the state recovery is completed, the new OSD takes the data packets from the cache for processing and starts to independently respond to the client. That is, the preset real-time mirroring technology is used to synchronize the data packets in the old OSD process to the cache queue of the new OSD process, including: using a preset programming interface to send a target data packet to the new OSD process; the target data packet is a data packet obtained by copying a to-be-processed data packet obtained from the client by the old OSD process; using the new OSD process and storing the to-be-processed data packet in a preset cache queue based on the sequence number of the to-be-processed data packet; correspondingly, using the data synchronization method and process data to perform process synchronization operation on the old OSD process and the new OSD process, and stopping the running of the old OSD process based on a termination instruction when the old OSD process and the new OSD process run consistently, including: using the new OSD process and injecting the to-be-processed data packet into a preset protocol stack based on the sequence number for data processing to generate a first acknowledgement signal; sending the first acknowledgement signal to the old OSD process through the new OSD process, and generating a second acknowledgement signal after the to-be-processed data packet is completely processed; stopping the running of the old OSD process based on the second acknowledgement signal. First, when the migration starts, the mirror rule is set. The old OSD process sets a rule in the socket layer through eBPF (extended Berkeley Packet Filter, extended Berkeley Packet Filter) to copy a received data packet and send it to the raw socket of the new OSD. At the same time, the old OSD process continues to normally process the connection; including but not limited to responding to the acknowledgement signal (ACK, Acknowledge character, acknowledgement character) sent by the new process. When the distributed system is running, the data packet sent by the client arrives at the old OSD process. The kernel protocol stack of the old OSD process processes the packet, normally receives the data packet, and puts it into a receiving queue. The eBPF program simultaneously sends the data packet to the new OSD process through the raw socket. It should be noted that when sending the data packet, the data packet can also be transmitted through shared memory (i.e., the preset shared memory mapping technology introduced later is used to transmit the data packet), which can save some network overhead. The new OSD process sets a special thread to receive the mirrored packet and caches it in the queue according to the sequence number. By sorting, the data packet processing disorder caused by network disorder can be avoided. After the data packet sharing is completed, the old OSD process sends the connection state (sequence number, window, unacknowledged data, etc.) to the new OSD process. The new OSD process restores the connection state by setting the TCP_REPAIR option.After the new OSD process state recovery is completed, the data packets in the cache queue are processed, specifically in the order of the sequence number of the data packets (injecting the data packets into the protocol stack of the new OSD (simulating reception), and then generating an ACK response (issued by the new OSD process). It should be noted that, because TCP is streaming, when processing data, it must be processed in order. After the new OSD process processes all the data packets in the cache queue, it sends an acknowledgement to the old OSD process. At this time, the old OSD stops responding to the ACK of the client, i.e., the subsequent data packets are no longer processed, but at this time the client has switched to the response of the new OSD process. Finally, after all the work is completed, the old OSD process removes the eBPF image rule.
[0080] Secondly, when sharing data packets, process-level freezing / restoration is implemented based on CRIU (Checkpoint / Restore, which is a software tool running on the Linux operating system), then cross-process cache data transfer is implemented using shared memory mapping, and finally memory data and disk consistency is implemented through transaction log playback (PGLog replay mechanism). That is, the cache data in the old OSD process is synchronized to the new OSD process using the CRIU tool and the preset shared memory mapping technology, including: starting dirty page tracking in the old OSD process using the CRIU tool to obtain cache data, and creating a preset memory to store the cache data; taking a memory snapshot of the old OSD process, and using incremental dirty pages to update the cache data in real time; correspondingly, the old OSD process and the new OSD process are synchronized using the data synchronization method and the process data, including: restoring the new OSD process using the memory snapshot, and injecting the preset memory into the new OSD process, and synchronously obtaining the cache data in the preset memory that is updated in real time using incremental dirty pages. In the preparation phase, on the old OSD process side, first freeze the request processing, then enable dirty page tracking:
[0081] .
[0082] After obtaining the corresponding cache data through dirty page tracking, a shared memory area (i.e., the above-mentioned preset shared memory technology) can be created to cache the obtained cache data:
[0083] .
[0084] Further, a full initial snapshot of the old OSD process is taken, and incremental dirty page synchronization is performed:
[0085] .
[0086] After the new OSD process state is restored, the new OSD process is restored from the snapshot on the new OSD process side, and the shared memory area is injected into the new OSD process:
[0087] .
[0088] Then, replay the dirty pages to synchronize to the cache data of the old OSD process:
[0089] .
[0090] In addition, it should be noted that when sharing the entire cache data, the PGLog replay mechanism (transaction log replay) and the scrub check can be used to ensure data consistency. Specifically, first, the new OSD process communicates with the current PG master OSD process to compare the operation records (identified by the epoch sequence number) in the PGLog of both. The master OSD process sends its complete PGLog to the new OSD process, and the new OSD process finds the latest operation entries that are missing or not persisted in itself by comparison. Subsequently, the new OSD process re-executes (i.e., replays) these missing write operations in order to update its local data to the latest state, completing the fast synchronization of data. Further, on the basis of PGLog replay to complete data synchronization, in order to further ensure the absolute correctness of the data content on the disk (e.g., detect and repair bit damage caused by disk silent errors), Ceph (a distributed file system) will periodically or in the background perform a Scrub check. Scrub is divided into two modes: Light and Deep. It verifies data consistency by calculating and comparing the checksums (such as CRC32 values) of the data of the master and slave copies object by object. Once a checksum mismatch is found, the object is marked and the repair process is started: using the correct copy as the source, the data of the error copy is overwritten or repaired.
[0091] Finally, as Figure 2As shown, when the number of days data synchronization is performed, the incremental data synchronization engine can be used, specifically, a double write log architecture is adopted, during the hot upgrade, the old OSD process sends the newly written data to the new OSD process at the same time, the new OSD process applies the write and maintains the difference log, after the upgrade is completed, the difference log is compared, the missing write is completed, and the PG (PostgreSQL, an open source database) version number pg_info is checked to ensure consistency. The log data in the old OSD process is synchronized to the new OSD process by using the double write log architecture, including: using the old OSD process to write all write operations into the local WAL and the incremental log stream, and sharing the incremental log stream to the new OSD process by using a preset memory sharing method; correspondingly, the old OSD process and the new OSD process are synchronized by using the data synchronization method and the process data, and when the old OSD process and the new OSD process run consistently, the running of the old OSD process is stopped based on a termination instruction, including: storing all write operations in the incremental log stream into a preset log cache area by the new OSD process; freezing the old OSD process to stop obtaining write operations, and registering the new OSD process to the monitoring unit; the process address of the new OSD process is broadcasted by using the monitoring unit, so that the client automatically redirects the request to the new OSD process based on the process address. Specifically, log splitting is started, the old OSD writes all write operations into the local WAL and the incremental log stream, and then sends the incremental log stream to the new OSD process in the shared memory mode. Initialize the version vector epoch and version, then structure the log, and pipeline the playback engine. After the new OSD process state is restored, the old OSD process stops receiving new requests, and the old OSD process is frozen. The new OSD process registers to the Monitor (monitoring unit) and is ready. The Monitor broadcasts the new OSDMap address and takes effect. After the process address of the new OSD process is broadcasted by using the monitoring unit so that the client automatically redirects the request to the new OSD process, including: using the scrub check to determine whether the log information in the new OSD process and the old OSD process is consistent; if the log information in the new OSD process and the old OSD process is inconsistent, the difference log data between the new OSD process and the old OSD process is determined, and the difference log data is written into the new OSD process. Specifically, the PG info information is checked by the scrub, and the version vector comparison of the new OSD and the old OSD is performed, in other words, after the upgrade is completed, the difference log is compared, the missing write is completed, and the PG version number pg_info is checked to ensure consistency.
[0092] Here as Figure 3The TCP connection hijacking module mainly functions to migrate the old OSD process to the new OSD process completely by using SO_REUSEPORT+TCP_REPAIR options; the memory state capturing engine mainly functions to realize cross-process data transmission by using CRIU+shared memory mapping, and finally realize memory data and disk strong consistency by transaction log playback (PGLog replay mechanism); and the incremental synchronization controller mainly functions to realize that the old OSD process sends the newly written data to the new OSD process during the hot upgrade by using a double-write log architecture.
[0093] In general, as Figure 4 As shown, first, the client initiates a normal I / O (Input / Output) request, and the distributed storage system completes the sending of the memory snapshot within 15 milliseconds, ensuring that the original OSD state is captured completely. Subsequently, the TCP connection is migrated to the new OSD within 5 milliseconds, realizing seamless transfer of the network session. The new OSD registers the new service address to the Monitor immediately after receiving the connection, and the Monitor pushes the latest OSDMap update to the entire cluster, so that subsequent client requests can be sent directly to the new OSD process. Thereafter, the distributed storage system enters the incremental synchronization stage: the old OSD process continues to forward the residual requests to the new node in real time, ensuring that no requests are lost; at the same time, the final consistency log is submitted, ensuring the integrity of the data during the migration process. Subsequently, the Monitor sends a termination instruction, and the old OSD process executes a graceful exit process, finally completing the entire migration. This process realizes efficient and smooth OSD replacement through multi-stage coordination and control, minimizes service interruption time, and guarantees system high availability and data consistency. During the process of upgrading the process, by means of TCP connection hijacking, memory snapshot and memory sharing, and double-write log, etc., the problems of client connection interruption, PG re-peering, business interruption caused by memory state loss, service delay increase, and cache hit rate decrease, etc. caused by restarting the OSD process during traditional hot upgrade are greatly solved, effectively improving the competitiveness of the distributed storage and the customer experience.
[0094] It can be seen that, in the embodiment, the file descriptor of the old OSD process is sent to the new OSD process by using the Unix domain Socket; the new OSD process contains the process configuration of the old OSD process; process data received by the old OSD process is synchronized to the new OSD process by using a preset data transmission technology, and the connection between the new OSD process and the client is established through the file descriptor, so that the old OSD process and the new OSD process are simultaneously run; the process synchronization operation is performed on the old OSD process and the new OSD process by using the data synchronization method and the process data, and when the old OSD process and the new OSD process run consistently, the running of the old OSD process is stopped based on a termination instruction, so as to complete the OSD process upgrade. That is, the file descriptor of the old OSD process is obtained by using the new OSD process to establish the connection with the client, and the process data in the old OSD process is synchronized to the new OSD process by using the preset data transmission technology, so that the client and the process data that are both completed are migrated from the old OSD process to the upgraded new OSD process, which can solve the problems of client connection interruption, PG re-peering, service interruption caused by memory state loss, service delay increase, and cache hit rate decrease caused by restarting the OSD process during the traditional hot upgrade, and effectively improve the competitiveness of the distributed storage and the customer experience.
[0095] Reference Figure 5 The embodiment of the application also discloses an OSD process upgrading device, which comprises the following modules.
[0096] The file descriptor sending module 11 is configured to send the file descriptor of the old OSD process to the new OSD process by using the Unix domain Socket; the new OSD process contains the process configuration of the old OSD process.
[0097] The data sending module 12 is configured to synchronize process data received by the old OSD process to the new OSD process by using a preset data transmission technology, and establish the connection between the new OSD process and the client through the file descriptor, so that the old OSD process and the new OSD process are simultaneously run.
[0098] The process synchronization module 13 is configured to perform the process synchronization operation on the old OSD process and the new OSD process by using the data synchronization method and the process data, and when the old OSD process and the new OSD process run consistently, stop the running of the old OSD process based on a termination instruction, so as to complete the OSD process upgrade.
[0099] It can be seen that, in the embodiment, the file descriptor of the old OSD process is acquired by using the new OSD process to establish a connection with the client, and the process data in the old OSD process is synchronized to the new OSD process by using a preset data transmission technology, so that the client and the process data are both migrated from the old OSD process to the upgraded new OSD process, which can solve the problems of client connection interruption, PG re-peering, service interruption caused by memory state loss, service delay increase, and cache hit rate decrease caused by restarting the OSD process during traditional hot upgrade, and effectively improve the competitiveness of distributed storage and the customer experience.
[0100] Further, the embodiment of the application further discloses an electronic device, Figure 6 is an electronic device structure diagram according to an exemplary embodiment, the contents in the figure cannot be considered as any limitation on the use range of the application. The electronic device can specifically include at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25 and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to realize the related steps in the OSD process upgrading method disclosed in any of the preceding embodiments. In addition, the electronic device in the embodiment can be an electronic computer.
[0101] In the embodiment, the power supply 23 is used to provide working voltage for each hardware device on the electronic device; the communication interface 24 can create a data transmission channel between the electronic device and the external device, and the communication protocol followed by the communication interface 24 can be any communication protocol applicable to the technical solution of the application, which is not limited here; the input / output interface 25 is used to obtain external input data or output data to the outside, and the specific interface type can be selected according to the specific application needs, which is not limited here.
[0102] In addition, the memory 22 as a resource storage carrier can be a read-only memory, a random access memory, a magnetic disk or an optical disk, etc., and the resources stored thereon can include an operating system 221, a computer program 222, etc., and the storage mode can be temporary storage or permanent storage.
[0103] The operating system 221 is used to manage and control each hardware device on the electronic device and the computer program 222, and can be Windows Server, Netware, Unix, Linux, etc. In addition to the computer program capable of completing the OSD process upgrading method executed by the electronic device disclosed in any of the preceding embodiments, the computer program 222 can further include a computer program capable of completing other specific work.
[0104] Further, the application discloses a computer readable storage medium for storing a computer program, wherein the computer program is executed by a processor to implement the OSD process upgrading method disclosed above. For the specific steps of the method, refer to the corresponding content disclosed in the foregoing embodiments, which will not be repeated here.
[0105] Further, the application discloses a computer program product comprising computer programs / instructions, wherein the computer programs / instructions are executed by a processor to implement the alarm aggregation method disclosed above. For the specific steps of the method, refer to the corresponding content disclosed in the foregoing embodiments, which will not be repeated here.
[0106] The various embodiments are described in a progressive manner in the specification, and each embodiment focuses on the differences from other embodiments. The same or similar parts of each embodiment can be referred to each other. For the apparatus disclosed by the embodiments, since it corresponds to the method disclosed by the embodiments, the description is relatively simple, and the relevant parts can be referred to the method part.
[0107] The skilled person can further realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized by electronic hardware, computer software or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of the examples have been described in general terms in the above description. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the application.
[0108] The steps of the method or algorithm described in combination with the embodiments disclosed herein can be directly implemented by hardware, a software module executed by a processor, or a combination of both. The software module can be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
[0109] Finally, it needs to be pointed out that in this document, relational terms such as first and second and the like can only be intended to distinguish one entity or operation from another entity or operation without necessarily requiring or implying any actual such relationship or order between such entities or operations. Moreover, the terms "comprising", "including", or any other variant thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without more limitations, an element defined by the statement "comprising a" does not exclude the existence of additional identical elements in the process, method, article, or apparatus including the element.
[0110] The above detailed description of the technical solutions provided by the present application has been provided, and the principles and implementation manners of the present application have been described by applying specific examples. The above description of the examples is only applicable to helping understand the method and core idea of the present application; meanwhile, for those skilled in the art, according to the idea of the present application, the specific implementation manners and application ranges will have changes, and in view of the above, the content of the specification should not be understood as a limitation of the present application.
Claims
1. A method for upgrading an OSD process, characterized in that, include: Use Unix domain sockets to send the file descriptors of the old OSD process to the new OSD process; The new OSD process includes the process configuration of the old OSD process; The process data received by the old OSD process is synchronized to the new OSD process using a preset data transmission technology, and a connection between the new OSD process and the client is established through the file descriptor so that the old OSD process and the new OSD process can run simultaneously. The old OSD process and the new OSD process are synchronized using a data synchronization method and the process data. When the old OSD process and the new OSD process are running in the same direction, the old OSD process is stopped based on a termination command to complete the OSD process upgrade.
2. The OSD process upgrade method according to claim 1, characterized in that, The method of using Unix domain sockets to send the file descriptor of the old OSD process to the new OSD process includes: Start the new OSD process and load the process configuration of the old OSD process into the new OSD process; Create a Unix domain socket and use SO_REUSEPORT in the Unix domain socket to control the old OSD process to enter TCP_REPAIR mode in order to extract file descriptors from the old OSD process; The file descriptor is sent to the new OSD process using the Unix domain socket; Accordingly, establishing a connection between the new OSD process and the client through the file descriptor to run both the old OSD process and the new OSD process simultaneously includes: The connection between the new OSD process and the client is established using SO_REUSEPORT in the Unix domain socket and the file descriptor, and the old OSD process is controlled to exit TCP_REPAIR mode so that the old OSD process and the new OSD process can run simultaneously.
3. The OSD process upgrade method according to claim 1, characterized in that, The step of synchronizing process data received by the old OSD process to the new OSD process using a preset data transmission technology includes: The data packets in the old OSD process are synchronized to the cache queue of the new OSD process using a preset real-time mirroring technology. The cached data in the old OSD process is synchronized to the new OSD process using the CRIU tool and a preset shared memory mapping technology. The log data in the old OSD process is synchronized to the new OSD process using a dual-write log architecture.
4. The OSD process upgrade method according to claim 3, characterized in that, The step of synchronizing data packets from the old OSD process to the cache queue of the new OSD process using a preset real-time mirroring technology includes: The target data packet is sent to the new OSD process using a preset programming interface; the target data packet is a data packet obtained by copying the data packet to be processed obtained from the client by the old OSD process. The new OSD process is used to store the data packets to be processed into a preset cache queue based on the sequence number of the data packets to be processed; Accordingly, the process synchronization operation between the old OSD process and the new OSD process using the data synchronization method and the process data, and the termination of the old OSD process based on a termination instruction when the old OSD process and the new OSD process are running in the same direction, includes: The new OSD process is used to inject the data packet to be processed into a preset protocol stack based on the sequence number for data processing, so as to generate a first confirmation signal. The new OSD process sends the first confirmation signal to the old OSD process, and generates a second confirmation signal after all the data packets to be processed have been processed. The old OSD process is stopped based on the second confirmation signal.
5. The OSD process upgrade method according to claim 3, characterized in that, The process of synchronizing cached data from the old OSD process to the new OSD process using CRIU tools and preset shared memory mapping technology includes: The CRIU tool is used to initiate dirty page tracing in the old OSD process to obtain cached data, and a preset memory is created to store the cached data; A memory snapshot of the old OSD process is taken, and the cached data is updated in real time using incremental dirty pages; Accordingly, the process synchronization operation between the old OSD process and the new OSD process using the data synchronization method and the process data includes: The new OSD process is restored using the memory snapshot, and the preset memory is injected into the new OSD process. The cached data updated in real time in the preset memory is obtained through the incremental dirty page synchronization.
6. The OSD process upgrade method according to claim 3, characterized in that, The method of synchronizing log data from the old OSD process to the new OSD process using a dual-write log architecture includes: The old OSD process is used to write all write operations into the current WAL and the incremental log stream, and the incremental log stream is shared to the new OSD process using a preset memory sharing method. Accordingly, the process synchronization operation between the old OSD process and the new OSD process using the data synchronization method and the process data, and the termination of the old OSD process based on a termination instruction when the old OSD process and the new OSD process are running in the same direction, includes: The new OSD process stores all write operations in the incremental log stream into a preset log buffer. Freeze the old OSD process to stop write operations, and register the new OSD process to the monitoring unit; The monitoring unit broadcasts the process address of the new OSD process so that the client can automatically redirect requests to the new OSD process based on the process address.
7. The OSD process upgrade method according to claim 6, characterized in that, The step of broadcasting the process address of the new OSD process using the monitoring unit, so that the client can automatically redirect requests to the new OSD process based on the process address, includes: Use scrub verification to determine whether the log information in the new OSD process is consistent with that in the old OSD process; If the log information in the new OSD process is inconsistent with that in the old OSD process, then the difference log data between the new OSD process and the old OSD process is determined, and the difference log data is written into the new OSD process.
8. An OSD process upgrade device, characterized in that, include: The file descriptor sending module is used to send the file descriptors of the old OSD process to the new OSD process using the Unix domain socket; The new OSD process includes the process configuration of the old OSD process; The data sending module is used to synchronize the process data received by the old OSD process to the new OSD process using a preset data transmission technology, and to establish a connection between the new OSD process and the client through the file descriptor, so as to run the old OSD process and the new OSD process simultaneously. The process synchronization module is used to perform process synchronization operations on the old OSD process and the new OSD process using data synchronization methods and process data, and to stop the operation of the old OSD process based on a termination instruction when the old OSD process and the new OSD process are running in the same direction, so as to complete the OSD process upgrade.
9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the OSD process upgrade method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the OSD process upgrade method as described in any one of claims 1 to 7.