CN115857830A

CN115857830A - Method and device for storing data based on CEPH and electronic equipment

Info

Publication number: CN115857830A
Application number: CN202211722988.3A
Authority: CN
Inventors: 万玉铸; 江文龙; 朱盛; 何宇航
Original assignee: Zhejiang Dahua Technology Co Ltd
Current assignee: Zhejiang Dahua Technology Co Ltd
Priority date: 2022-12-30
Filing date: 2022-12-30
Publication date: 2023-03-28

Abstract

The invention provides a method and a device for storing data based on CEPH (content addressable Power), and electronic equipment, which are used for reducing time delay during data storage and avoiding the problem that CEPH can not meet the use scene with low time delay requirement in the prior art. The method is applied to the main OSD and comprises the following steps: receiving data to be stored; storing the data to be stored and sending first information to a client; the first information is used for indicating that the data to be stored is written into a disk; and sending the data to be stored to a slave OSD, and enabling the slave OSD to store the data to be stored.

Description

Method and device for storing data based on CEPH and electronic equipment

Technical Field

The application relates to the technical field of cloud storage, in particular to a method and a device for storing data based on CEPH and an electronic device.

Background

CEPH (distributed file system) as a unified distributed storage system can provide three storage functions of block device storage, file system storage and object storage. Since, when stored in CEPH, acknowledgements are only returned after all copy writes are complete (see fig. 1), its system performance increases linearly with the number of nodes. When the method is used for a scene with high requirements on the time delay and IOPS (IO per sec, IO request per second) performance of a storage system, such as cloud computing, the CEPH bottom layer storage cannot provide corresponding performance support. Taking a 3-node CEPH cluster, each node being a 36HDD bay as an example, assuming that a single-disk IO write IOPS is 200, the IOPS upper limit provided by the CEPH cluster is 21600. Removing performance penalties such as duplicate redundancy policies and OSD metadata partitioning, the IOPS that can be provided by the CEPH is about 6000 in practice. Obviously, the performance index IOPS of 6000 cannot meet the requirement of a usage scenario (such as a cloud platform) with a low latency requirement on CEPH underlying storage.

At present, in order to overcome the above problems, a persistent cache method is often adopted: and setting the SSD storage pool as the bottom storage pool of the persistent cache. That is, when CEPH performs a write operation, mapping IO to the SSD storage pool, and then uniformly writing IO in the SSD storage pool into OSD (i.e., writing back dirty data); the dirty data write back threshold in the actual cache management mechanism is about 80%. The method still has the problem that the cache pool is easy to be written to full due to too small capacity, so that subsequent IO cannot be written into the cache pool and is directly written into the HDD pool, and the CEPH performance is greatly reduced. Generally, the cache pool is composed of 3 blocks of SSD, and each block of SSD is 960GB for explanation, please refer to fig. 2: since the space occupied by the failover and metadata partitions is about 5% -10%, the actual available space per SSD is about 900GB or less. And because the write-back threshold of the dirty data is 80%, the space actually available for data caching in the cache pool is less than 720GB, when the IOPS is high, the cache pool is quickly written to full, and when the cache pool does not write the IO data cached therein into the back-end storage disk, a problem of rapid performance degradation caused by direct subsequent IO writing into the back-end storage disk easily occurs. Therefore, the CEPH bottom layer data storage method in the prior art has the problem of high time delay.

Disclosure of Invention

The invention provides a data storage method based on CEPH, which is used for reducing time delay during data storage, achieving the purpose of efficiently responding to an object request and avoiding the problem that CEPH can not meet the use scene with low time delay requirement in the prior art.

In a first aspect, the present application provides a method for storing data based on CEPH, where the method is applied to a main OSD, and includes:

receiving data to be stored;

storing the data to be stored, and sending first information to a client; wherein the first information is used for indicating that the data to be stored is written into the main OSD;

and sending the data to be stored to a slave OSD, and enabling the slave OSD to store the data to be stored.

According to the embodiment of the application, after the main OSD writes the data to be stored, the first information is directly sent to the client, then the data to be stored is written into the slave OSD, and the time delay is reduced by one time, so that the application range of the CEPH stored data is expanded, the high time delay caused by the fact that the data to be stored enters the cache pool in advance and cannot be directly stored into the main OSD can be effectively avoided, and the problem that the time delay caused by the fact that the data to be stored is directly written into the main OSD is multiplied due to the fact that the cache pool is full of data under continuous high writing pressure through the cache Chi Huancun in the prior art can also be avoided.

In a possible implementation manner, the disk type of the main OSD is an SSD disk; the disk type of the slave OSD is an HDD disk.

One possible implementation manner, the storing the data to be stored includes:

determining the length of the data to be stored;

responding to the condition that the length of the data to be stored is smaller than a first preset threshold value, storing and adding the data to be stored to a first aggregation queue; or,

and responding to the condition that the length of the data to be stored is not less than the first preset threshold value, and storing the data to be stored.

One possible embodiment, the sending the data to be stored to the slave OSD, and causing the slave OSD to store the data to be stored includes:

determining the length of the first aggregation queue and the creation time of the first aggregation queue;

in response to that the length of the first aggregation queue is larger than a first preset length threshold and/or the creation time is larger than a first preset time threshold, sending the aggregation queue to the slave OSD, and enabling the slave OSD to write in all data to be stored in the aggregation queue;

receiving second information; wherein the second information is used for indicating an aggregation queue to write the slave OSD.

One possible implementation manner, the storing the data to be stored includes:

determining the length of the data to be stored;

responding to the fact that the length of the data to be stored is smaller than a second preset threshold value, storing and adding the data to be stored to a first sub-queue; or,

and responding to the condition that the length of the data to be stored is not smaller than the second preset threshold value, storing and adding the data to be stored to a second sub queue.

determining the length of the first sub-queue, the creation time of the first sub-queue, and the length of the second sub-queue;

writing the first sub-queue into the slave OSD in response to the length of the first sub-queue being greater than a second preset length threshold and/or the creation time of the first sub-queue being greater than a second preset time threshold;

in response to the length of the second sub-queue being greater than the third preset length threshold, writing the second sub-queue to the slave OSD; the third preset length threshold is smaller than the second preset length threshold.

In a possible embodiment, the third preset length threshold is equal to the second preset threshold.

In a second aspect, an embodiment of the present application provides a method for storing data based on CEPH, where the method is applied to a monitor, and the method includes:

determining the disk type of the main OSD as SSD based on the input parameters in the CRUSH algorithm; wherein the input parameters include disk types of the master OSD and the slave OSD;

based on the CRUSH algorithm, selecting a first SSD from nodes containing the SSD as a storage disk of the main OSD;

determining the disk type of the slave OSD as an HDD based on the input parameters in the CRUSH algorithm;

based on the CRUSH algorithm, selecting a first HDD and a second HDD from the nodes containing the HDDs as storage disks of a first slave OSD and a second slave OSD respectively;

sending the OSD set to the client; the OSD set comprises the first SSD, a first HDD and the second HDD, and the client sends data to be stored to the main OSD.

In one possible embodiment, the number of HDD-containing nodes is not less than 2, and the first HDD and the second HDD are selected from different HDD-containing nodes.

In a third aspect, an embodiment of the present application provides an apparatus for storing data based on CEPH, where the apparatus is applied to a main OSD, and the apparatus includes:

a receiving unit: the data storage device is used for receiving data to be stored;

a response unit: the data storage device is used for storing the data to be stored and sending first information to a client; wherein the first information is used for indicating that the data to be stored is written into the main OSD;

a transmission unit: and sending the data to be stored to a slave OSD, and enabling the slave OSD to store the data to be stored.

In a possible embodiment, the response unit is specifically configured to determine a length of the data to be stored; responding to the condition that the length of the data to be stored is smaller than a first preset threshold value, storing and adding the data to be stored to a first aggregation queue; or, in response to that the length of the data to be stored is not less than the first preset threshold, storing the data to be stored.

In a possible implementation manner, the sending unit is specifically configured to determine a length of the first aggregation queue and a creation time of the first aggregation queue; in response to that the length of the first aggregation queue is larger than a first preset length threshold and/or the creation time of the first aggregation queue is larger than a first preset time threshold, sending the aggregation queue to the slave OSD, and enabling the slave OSD to write in all data to be stored in the aggregation queue; receiving second information; wherein the second information is used for indicating an aggregation queue to write the slave OSD.

In a possible implementation manner, the response unit is further configured to store and add the data to be stored to the first sub-queue in response to that the length of the data to be stored is smaller than a second preset threshold; or, in response to that the length of the data to be stored is not smaller than the second preset threshold, storing and adding the data to be stored to a second sub-queue.

In a possible implementation manner, the sending unit is further configured to determine a length of the first sub-queue, a creation time of the first sub-queue, and a length of the second sub-queue; writing the first sub-queue into the slave OSD in response to the length of the first sub-queue being greater than a second preset length threshold and/or the creation time of the first sub-queue being greater than a second preset time threshold; in response to the length of the second sub-queue being greater than the third preset length threshold, writing the second sub-queue to the slave OSD; the third preset length threshold is smaller than the second preset length threshold.

In a fourth aspect, an embodiment of the present application provides an apparatus for storing data based on a CEPH, where the apparatus is applied to a monitor, and the apparatus includes:

a first type of unit: determining the disk type of the main OSD as SSD based on the input parameters in the CRUSH algorithm; wherein the input parameters include disk types of the master OSD and the slave OSD;

a first disk unit: based on the CRUSH algorithm, selecting a first SSD from nodes containing the SSD as a storage disk of the main OSD;

a second type of unit: determining the disk type from OSD as HDD based on the input parameters in the CRUSH algorithm;

a second disk unit: based on the CRUSH algorithm, selecting a first HDD and a second HDD from the nodes containing the HDDs as storage disks of a first slave OSD and a second slave OSD respectively;

a gathering unit: sending the OSD set to the client; the OSD set comprises the first SSD, a first HDD and the second HDD, and the client sends data to be stored to the main OSD.

In a fifth aspect, embodiments of the present application provide a readable storage medium, including,

a memory for storing a plurality of data to be transmitted,

the memory is configured to store instructions that, when executed by the processor, cause an apparatus comprising the readable storage medium to perform the method according to the first aspect to the second aspect and any possible implementation.

In a sixth aspect, an embodiment of the present application provides an electronic device, including:

a memory for storing a computer program;

a processor configured to execute the computer program stored in the memory to implement the method according to the first aspect to the second aspect and any possible implementation manner.

Drawings

FIG. 1 is a schematic diagram of a prior art CEPH-based data storage method;

FIG. 2 is a schematic diagram of a prior art CEPH-based data storage method;

fig. 3 is a schematic flowchart of a method for storing data based on CEPH according to an embodiment of the present application;

fig. 4 is a schematic diagram of another method for storing data based on CEPH according to an embodiment of the present application;

fig. 5 is a schematic diagram of a method for storing data based on CEPH according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of an apparatus for storing data based on CEPH according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of an apparatus for storing data based on CEPH according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of an electronic device storing data based on CEPH according to an embodiment of the present application.

Detailed Description

Aiming at the problem of high data storage time delay of the CEPH in the prior art, the embodiment of the application provides a method for storing data based on the CEPH, which comprises the following steps: after receiving the data to be stored, the master OSD sends confirmation information (i.e., first information) of a write request to the client when the storage of the master OSD is completed, and then initiates the write request to the slave OSD, so that the slave OSD stores the data to be stored, thereby avoiding the problem of high time delay caused by the fact that the master OSD initiates the confirmation information to the client after receiving the confirmation information of the slave OSD after the master OSD and the slave OSD are sequentially written.

It should be noted that, in the prior art, the reason that the master OSD sends the confirmation information to the client only after receiving the confirmation information sent by the slave OSD is to ensure strong consistency of data, that is, to ensure that both the data master OSD and the slave OSD are written. On the basis of efficiently responding to the client, the data to be stored is still sent to the slave OSD after the confirmation information is sent to the client, and finally the purpose that the master OSD and the slave OSD store the same data is still achieved, so that the method for storing the data provided by the embodiment of the application does not affect the consistency of the data stored in the master OSD and the slave OSD.

For the sake of understanding, the technical solutions of the present application are described in detail below with reference to the drawings and the specific embodiments, and it should be understood that the specific features of the embodiments and examples of the present application are detailed descriptions of the technical solutions of the present application, and are not limitations of the technical solutions of the present application, and the technical features of the embodiments and examples of the present application may be combined with each other without conflict.

Referring to fig. 3, an embodiment of the present application provides a method for storing data based on CEPH, so as to reduce a time delay of CEPH data and achieve a high IOPS performance index, where the method is applied to a main OSD, and specifically includes the following implementation steps:

step 301: data to be stored is received.

The data to be stored is data sent by the client.

OSD (Object Storage Device): one of the CEPH core components refers to the process/node responsible for responding to client requests and returning specific data. Each OSD is responsible for managing one disk.

Specifically, the master-slave model is still adopted in the embodiment of the present application. The master OSD and the slave OSD may be independently selected from one or more nodes. The number of nodes is preferably 3, which ensures that when one node is powered off/fails, other nodes can provide master and slave OSDs for storing data. Accordingly, when there are a plurality of master OSDs and/or a plurality of slave OSDs, selection can be made among different nodes. For example, if 3 nodes are set and 3 copies (OSDs) are determined, a first copy (for example, a master OSD) is selected from any one of the 3 nodes, and a second copy is continuously selected from any one of the other two nodes; the third copy is then selected among the remaining unselected nodes.

Further, the disk types of the master OSD and the slave OSD may be SSDs or HDDs. Since the SSD is different from the HDD in physical structure, the storage performance and the response rate of the SDD are better than those of the HDD, and therefore, the disk type of the main OSD is preferably the SSD.

Meanwhile, in order to realize high economic benefit, the HDD can be selected from the OSD; then when the number of nodes is 3, the underlying storage disk of CEPH may be (SSD, HDD).

Step 302: and storing the data to be stored, and sending first information to the client.

The first information is confirmation information used for indicating that the data to be stored is written into the bottom disk.

Specifically, in the embodiment of the present application, the data to be stored is actually IO (INPUT/OUTPUT), corresponding to a request/response. Since the length of the response, i.e., the confirmation information, is fixed, the data to be stored in the embodiment of the present application focuses on the request in the IO, i.e., the length of the input information.

Corresponding to the requirement of high IOPS performance, the requirement is small IO (that is, the length of data to be stored is smaller than a first preset threshold), and accordingly, the requirement on latency performance is high in a service scene. Such as database applications on a computing cloud. For the small IO, if the main OSD is still used to send the confirmation information to the client after receiving the confirmation information from the slave OSD, the delay is high, and the scene requirement cannot be met.

Similarly, when the master OSD writes (i.e., stores) a small IO each time, the slave OSD is immediately written, and under the large storage pressure of continuous writing, the master OSD will face an excessively large storage writing load, so that when the master OSD writes data to be stored into a local object storage engine (BlueStore), the IOs are aggregated in the OSD to form an aggregation queue, and the fixed length of the aggregation queue is periodically or (aggregation queue) flushed: and writes to the slave OSD together, further degrading the latency performance of CEPH.

Therefore, in an embodiment of the present application, the length of the data to be stored may be determined first, and whether to add the data to the aggregation queue for buffering may be determined according to the length of the data to be stored. That is, in response to the length of the data to be stored being less than a first preset threshold (e.g., 64KB, or 128 KB), the aforementioned data to be stored is stored and added to the first aggregation queue. Or, in response to that the length of the data to be stored is greater than or equal to the first preset threshold, determining that the data to be stored is large data to be stored, and therefore, only performing a write operation, that is, storing the data to be stored in the main OSD.

In another embodiment of the present application, data to be stored may be cached uniformly, but the large IO and the small IO are distinguished according to the length of the data to be stored, and then the large IO and the small IO are cached in the lower-flushing mechanism or the aggregation queue with different lower-flushing thresholds, respectively. Specifically, the length of the data to be stored is determined, and the data to be stored is stored and added to the first sub-queue in response to the fact that the length of the data to be stored is smaller than a second preset threshold value. Or, in response to that the length of the data to be stored is not less than a second preset threshold, storing and adding the data to be stored to the second sub-queue.

The second predetermined threshold may be the same as the first predetermined threshold.

Step 303: sending the data to be stored to a slave OSD, so that the slave OSD stores the data to be stored.

Specifically, when the data is transmitted to the slave OSDs, the data to be stored or the aggregation queues are transmitted simultaneously according to the number of the slave OSDs. That is, in case no aggregation is performed in step 302, this step 303 initiates a write request to the slave OSD immediately after the first information is sent in step 302, and receives confirmation information from the slave OSD after the data to be stored is written from the slave OSD.

If only the small IO with the length smaller than the first preset threshold is added to the aggregation queue in step 302, the large IO will be directly written into the slave OSD as in the foregoing embodiment; for a small IO, a write request may be initiated to the slave OSD through the aggregation thread in the master OSD according to the creation time of the aggregation queue or the aggregation queue, and after the slave OSD writes in the IO, confirmation information from the slave OSD is received, please refer to fig. 4. Thus, in one embodiment of the present application, the length and creation time of the first aggregate queue is determined. And in response to the fact that the length of the first aggregation queue is larger than a preset length threshold and/or the creation time is larger than a preset time threshold, sending the aggregation queue to the slave OSD, and enabling the slave OSD to write all the small IOs including the small IOs in the aggregation queue. Then, confirmation information from the OSD may be received: and second information. That is, the second information is used to indicate that all IO writes in the aggregation queue to the slave OSD, and the storage of the slave OSD is completed, please continue referring to fig. 4.

If in step 302, the data to be stored is cached in the flushing mechanism or the aggregation queues with different flushing thresholds according to the length of the data to be stored, different trigger conditions may be set for different aggregations, so as to promote the large IO to write in the slave OSD as soon as possible, and avoid that the large IO with a low delay requirement occupies too much cache space to affect the cache of the small IO. Therefore, in an embodiment of the present application, the length of the first sub-queue where the small IO is located and the creation time of the first sub-queue are determined first. Meanwhile, the length of the second sub-queue for caching the large IO is also determined. And then, in response to that the length of the first sub-queue is greater than a first length threshold and/or the creation time of the first sub-queue is greater than a second preset time threshold, writing all data to be stored in the first sub-queue into the slave OSD. Similarly, all the data to be stored in the second sub-queue is written into the slave OSD in response to the length of the second sub-queue being greater than the third length threshold. And the third preset length threshold is smaller than the second preset length threshold corresponding to the first sub-queue. Finally, the determination information from the OSD may be received: after the second information, it is determined that the data to be stored in the first sub-queue or the second sub-queue has been successfully written into the corresponding slave OSD.

Further, the third preset length threshold may be set to be equal to the second preset length threshold for distinguishing the large IO from the small IO, so as to avoid a problem that the large IO is not sensitive to the delay and the data to be stored occupies the buffer space.

Based on the same inventive concept, the embodiment of the application provides a CEPH data storage method, which is applied to a monitor and used for realizing heterogeneous disk type election for a main OSD and a slave OSD through a CRUSH algorithm, so that a client sends data to be stored to the elected main OSD to finish data storage.

For ease of understanding, the following description is made with respect to Monitor, CRUSH algorithm, and PG.

Mon (Monitor): one of the CEPH core components is responsible for managing metadata.

CRUSH (Controlled Replication of extensible hashes) algorithm: an algorithm for pseudo-randomly controlling data distribution and replication. The algorithm can realize the balance of data distribution and load in CEPH, flexibly cope with cluster expansion and support large-scale clusters.

PG (Placement Groups, put in Groups): is a logical concept, a PG contains multiple OSDs; the layer PG is introduced in the PECH to better distribute data and positioning data. CEPH splits data into Objects (Objects) when storing the data. Each object has a unique OID, and the OID can uniquely identify each different object and store the dependency relationship between the object and the file. Since all data of CEPH is assumed to be a uniform object, efficiency is high in reading and writing. In order to avoid the problem of large addressing workload when a large number of objects are directly written into the OSD, and to avoid the problem that data migration from the damaged OSD to a new OSD cannot be completed when the OSD is damaged, a reset group PG is introduced. PG is a logical concept, objects can be directly seen in a Linux system, but PG cannot be directly seen. It is similar to an index in a database when data is addressed: each object is fixedly mapped into one PG, so when finding one object, only the PG to which the object belongs needs to be found firstly, and then the PG is traversed, and all the objects do not need to be traversed. Moreover, even when data is migrated, a PG is migrated as a basic unit, and CEPH does not directly operate on the target.

Please refer to fig. 5 for a detailed description of the CEPH-based data storage method provided in the present application. When the data to be stored in the client is mapped onto the PGs, the Monitor node may perform selection of the master OSD and slave OSD disk types for the data to be stored in each PG based on the CRUSH algorithm. In which, PG, as a logic concept, can be used as a parameter in the CRUSH together with the disk type. Namely, in the embodiment of the application, an input parameter for identifying the disk type is newly added in the CRUSH, so as to achieve the purpose of electing the heterogeneous storage medium.

Therefore, the embodiment of the application adds the disk type input parameters including the master OSD and the slave OSD in the CRUSH algorithm. Specifically, the data to be stored is first split into objects in the client, hashed onto PG with object names, and then the disk types of PG, master OSD, and slave OSD are specified by the CRUSH algorithm, for example, [ SSD, HDD ], [ SSD, HDD ], or [ SSD, SSD ]. That is, the Monitor determines the disk type of the main OSD to be SSD for the PG based on the parameter and type input parameter corresponding to the PG in the CRUSH algorithm; and then selecting the first SSD from the nodes containing the SSDs through a CRUSH algorithm to be used as a storage disk of the main OSD. Then, determining the disk type of the slave OSD as the HDD by a CRUSH algorithm according to the input parameters; and then, in the nodes containing the HDDs, selecting the first HDD and the second HDD as storage disks of the first slave OSD and the second slave OSD respectively to obtain three copies of the storage disks (the first SSD, the first HDD and the second HDD). Finally, (the first SSD, the first HDD, the second HDD) may be sent to the client as an OSD set, so that the client sends the data to be stored in the PG to the main OSD. After receiving the OSD set, the client controls the objects in the PG, i.e., the data to be stored, to be sent to the main OSD.

The number of the SSD disks corresponding to the first SSD may be plural, and the HDD disks corresponding to the first HDD and the second HDD may also be plural. The number of the nodes containing the HDD is not less than 2, and is preferably 2; the first HDD and the second HDD are selected from different HDD-containing nodes.

Based on the same inventive concept, an embodiment of the present application provides a device for storing data based on CEPH, where the device corresponds to the method for storing data based on CEPH shown in fig. 3, and a specific implementation of the device may refer to the description of the foregoing method embodiment, and repeated parts are not repeated, referring to fig. 6, where the main OSD in the device includes:

the receiving unit 601: for receiving data to be stored.

The disk type of the main OSD is an SSD disk; the disk type of the slave OSD is an HDD disk.

The response unit 602: the data storage device is used for storing the data to be stored and sending first information to the client.

The first information is used for indicating that the data to be stored is written into the main OSD.

The response unit 602 is specifically configured to determine the length of the data to be stored; responding to the condition that the length of the data to be stored is smaller than a first preset threshold value, storing and adding the data to be stored to a first aggregation queue; or, in response to that the length of the data to be stored is not less than the first preset threshold, storing the data to be stored.

The response unit 602 is further configured to determine a length of the data to be stored; responding to the fact that the length of the data to be stored is smaller than a second preset threshold value, storing and adding the data to be stored to a first sub-queue; or, in response to that the length of the data to be stored is not smaller than the second preset threshold, storing and adding the data to be stored to a second sub-queue.

The transmission unit 603: the data storage device is used for sending the data to be stored to a slave OSD and enabling the data to be stored in the slave data to be stored.

The sending unit 603 is specifically configured to determine the length of the first aggregation queue and the creation time of the first aggregation queue; in response to that the length of the first aggregation queue is larger than a first preset length threshold and/or the creation time of the first aggregation queue is larger than a first preset time threshold, sending the aggregation queue to the slave OSD, and enabling the slave OSD to write in all data to be stored in the aggregation queue; receiving second information; wherein the second information is used for indicating an aggregation queue to write the slave OSD.

The sending unit 603 is further configured to determine a length of the first sub-queue, a creation time of the first sub-queue, and a length of the second sub-queue; writing the first sub-queue into the slave OSD in response to the length of the first sub-queue being greater than a second preset length threshold and/or the creation time of the first sub-queue being greater than a second preset time threshold; in response to the length of the second sub-queue being greater than the third preset length threshold, writing the second sub-queue to the slave OSD; the third preset length threshold is smaller than the second preset length threshold.

In the embodiment of the present application, a device for storing data based on CEPH is provided, and a specific implementation of the device may refer to the description in the foregoing method embodiment, and repeated details are not repeated, referring to fig. 7, where the device is applied to a monitor, and includes:

first type cell 701: determining the disk type of the main OSD as SSD based on the input parameters in the CRUSH algorithm; wherein the input parameters include disk types of the master OSD and the slave OSD.

First disk unit 702: and selecting a first SSD from the nodes containing the SSD as a storage disk of the main OSD based on the CRUSH algorithm.

Second type unit 703: determining the disk type of the slave OSD as the HDD based on the input parameters in the CRUSH algorithm.

Second disk unit 704: and selecting a first HDD and a second HDD as storage disks of a first slave OSD and a second slave OSD respectively in the nodes containing the HDDs on the basis of the CRUSH algorithm.

The aggregation unit 705: sending the OSD set to the client; wherein the OSD set comprises the first SSD, a first HDD and the second HDD.

If the number of the HDD-containing nodes is not less than 2, the first HDD and the second HDD are selected from different HDD-containing nodes.

Based on the same inventive concept, an embodiment of the present application further provides a readable storage medium, including:

a memory for storing a plurality of data to be transmitted,

the memory is to store instructions that, when executed by the processor, cause an apparatus comprising the readable storage medium to perform a method of storing data based on CEPH as described above.

Based on the same inventive concept as the method for storing data based on CEPH, an embodiment of the present application further provides an electronic device, where the electronic device can implement the function of the method for storing data based on CEPH, please refer to fig. 8, and the electronic device includes:

at least one processor 801 and a memory 802 connected to the at least one processor 801, in this embodiment, a specific connection medium between the processor 801 and the memory 802 is not limited in this application, and fig. 8 illustrates an example in which the processor 801 and the memory 802 are connected by a bus 800. The bus 800 is shown in fig. 8 by a thick line, and the connection manner between other components is merely illustrative and not limited thereto. The bus 800 may be divided into an address bus, a data bus, a control bus, etc., and is shown in fig. 8 with only one thick line for ease of illustration, but does not represent only one bus or type of bus. Alternatively, the processor 801 may also be referred to as a controller, without limitation to name a few.

In the embodiment of the present application, the memory 802 stores instructions executable by the at least one processor 801, and the at least one processor 801 may execute the method for storing data based on CEPH, which is discussed above, by executing the instructions stored in the memory 802. The processor 801 may implement the functions of the various modules in the apparatus shown in fig. 6 or fig. 7.

The processor 801 is a control center of the apparatus, and may connect various parts of the entire control device by using various interfaces and lines, and perform various functions of the apparatus and process data by operating or executing instructions stored in the memory 802 and calling up data stored in the memory 802, thereby performing overall monitoring of the apparatus.

In one possible design, the processor 801 may include one or more processing units, and the processor 801 may integrate an application processor that handles primarily operating systems, user interfaces, application programs, and the like, and a modem processor that handles primarily wireless communications. It will be appreciated that the modem processor described above may not be integrated into the processor 801. In some embodiments, the processor 801 and the memory 802 may be implemented on the same chip, or in some embodiments, they may be implemented separately on separate chips.

The processor 801 may be a general-purpose processor, such as a Central Processing Unit (CPU), digital signal processor, application specific integrated circuit, field programmable gate array or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or the like, that may implement or perform the methods, steps, and logic blocks disclosed in embodiments of the present application. A general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method for storing data based on CEPH disclosed in the embodiments of the present application may be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

Memory 802, which is a non-volatile computer-readable storage medium, may be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. The Memory 802 may include at least one type of storage medium, and may include, for example, a flash Memory, a hard disk, a multimedia card, a card-type Memory, a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a Programmable Read Only Memory (PROM), a Read Only Memory (ROM), a charge Erasable Programmable Read Only Memory (EEPROM), a magnetic Memory, a magnetic disk, an optical disk, and the like. The memory 802 is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to such. The memory 802 in the embodiments of the present application may also be circuitry or any other device capable of performing a storage function for storing program instructions and/or data.

The processor 801 is programmed to solidify the code corresponding to the method for storing data based on CEPH described in the foregoing embodiments into the chip, so that the chip can execute the steps of the method for storing data based on CEPH shown in fig. 3 when running. How to program the processor 801 is well known to those skilled in the art and will not be described in detail herein.

It will be clear to those skilled in the art that, for convenience and simplicity of description, the foregoing division of the functional modules is merely used as an example, and in practical applications, the above function distribution may be performed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to perform all or part of the above described functions. For the specific working processes of the system, the apparatus and the unit described above, reference may be made to the corresponding processes in the foregoing method embodiments, and details are not described here again.

In the embodiments provided in the present invention, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the modules or units is only one logical division, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, a network device, or the like) or a processor (processor) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a Universal Serial Bus flash disk (usb flash disk), a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.

Claims

1. A method for storing data based on CEPH, the method being applied to a main OSD and comprising:

receiving data to be stored;

storing the data to be stored and sending first information to a client; wherein the first information is used for indicating that the data to be stored is written into the main OSD;

2. The method of claim 1, wherein a disk type of the master OSD is an SSD disk; the disk type of the slave OSD is an HDD disk.

3. The method of claim 1 or 2, wherein said storing said data to be stored comprises:

determining the length of the data to be stored;

4. The method of claim 3, wherein the sending the data to be stored to the slave OSD, causing the slave OSD to store the data to be stored, comprises:

in response to that the length of the first aggregation queue is larger than a first preset length threshold and/or the creation time of the first aggregation queue is larger than a first preset time threshold, sending the aggregation queue to the slave OSD, and enabling the slave OSD to write in all data to be stored in the aggregation queue;

5. The method of claim 1 or 2, wherein said storing said data to be stored comprises:

determining the length of the data to be stored;

6. The method of claim 5, wherein the sending the data to be stored to the slave OSD, causing the slave OSD to store the data to be stored, comprises:

7. A method for storing data based on CEPH, which is applied to a monitor and comprises the following steps:

determining the disk type of the main OSD as SSD based on the input parameters in the CRUSH algorithm; wherein the input parameters comprise disk types of the master OSD and the slave OSD;

8. An apparatus for storing data based on CEPH, the apparatus being applied to a main OSD, comprising:

a response unit: the data storage device is used for storing the data to be stored and sending first information to a client; the first information is used for indicating that the data to be stored is written into the main OSD;

9. A readable storage medium, comprising,

a memory for storing a plurality of data to be transmitted,

the memory is to store instructions that, when executed by the processor, cause an apparatus comprising the readable storage medium to perform the method of any of claims 1-7.

10. An electronic device, comprising:

a memory for storing a computer program;

a processor for implementing the method of any one of claims 1 to 7 when executing the computer program stored on the memory.