WO2019144553A1 - Data storage method and apparatus, and storage medium - Google Patents

Abstract

Provided in the present application are a data storage method and apparatus, and a computer-readable storage medium, the method comprising the following steps: determining the quantity of OSDs used by each service group according to a preset rule in every preset cycle, and allocating a unique sub-cluster identifier for OSDs of the same service group; receiving a request of a user for storing a data file to a distributed storage system; determining, according to identification information of the user, the service group to which the user belongs and the sub-cluster identifier of the OSDs of said service group; and uniformly dividing the data file into multiple data blocks, and storing multiple copies of each data block in the OSDs which have the corresponding sub-cluster identifier by utilizing a CRUSH algorithm. With the present application, resources are reasonably configured by allocating the OSD for each service group, and the influence of OSD faults on the storage system are controlled to be within a sub-cluster range by means of adding logic division of sub-clusters into a topology structure of a cluster.

Description

Data storage method, device and storage medium

Priority claim

The present application claims priority to Chinese Patent Application No. 201,810, 079, 307, filed on Jan. 26, 2018, the entire disclosure of which is incorporated herein by reference. In this application.

Technical field

The present application relates to the field of data storage technologies, and in particular, to a data storage method, apparatus, and computer readable storage medium.

Background technique

A distributed storage system is a system that distributes data decentralized on multiple independent devices. Ceph is a widely used open source distributed storage system that treats data as an object through extensible hashing. The Controlled Replication Under Scalable Hashing (CRUSH) algorithm evenly distributes objects into clusters of storage devices and provides dynamic scaling, balancing, and recovery.

At present, in a distributed storage system, three copies are used to store data in three different locations to improve the reliability of data storage. When data is stored in three copies, the data center and the computer room are respectively used. The hierarchy of the cabinet, host, and object storage device (OSD) is used to plan the fault domain. Once one of the OSDs fails, in order to ensure the availability of the three copies, data migration of the entire cluster will be performed. This data migration process consumes a large amount of system resources and greatly affects system performance.

Summary of the invention

To solve the deficiencies of the prior art, the present application provides a storage method, an apparatus, and a computer readable storage medium, which can allocate an OSD for each service group, and add a logical division of a sub-cluster to the hierarchy of the host in the topology of the cluster. To achieve reasonable allocation of resources and to control the impact of OSD failures on the storage system within the scope of the sub-cluster.

To achieve the above objective, the present application provides a data storage method, which is applied to an electronic device, which is connected to a distributed storage system through a network, and the distributed storage system provides a series of hosts and an OSD, wherein the method includes:

Device allocation step: determining the number of OSDs used by each service group according to a preset rule every preset period, and assigning a unique sub-cluster identifier to the OSD of the same service group;

Request receiving step: receiving a request for a user to store a data file to a distributed storage system;

The service group determining step is: determining, according to the identification information of the user, the service group to which the user belongs and the sub-cluster identifier of the service group OSD; and

File storage step: uniformly divide the data file into a plurality of data blocks, and store multiple copies of each data block in an OSD having a corresponding sub-cluster identifier by using a CRUSH algorithm.

The application also provides an electronic device including a memory and a processor, the memory including a data storage program. When the processor of the electronic device executes the data storage program in the memory, the following steps are implemented:

Device allocation step: determining the number of OSDs used by each service group according to a preset rule every preset period, and assigning a unique sub-cluster identifier to the OSD of the same service group;

Request receiving step: receiving a request for a user to store a data file to a distributed storage system;

The service group determining step is: determining, according to the identification information of the user, the service group to which the user belongs and the sub-cluster identifier of the service group OSD; and

File storage step: uniformly divide the data file into a plurality of data blocks, and store multiple copies of each data block in an OSD having a corresponding sub-cluster identifier by using a CRUSH algorithm.

In addition, in order to achieve the above object, the present application further provides a computer readable storage medium including a data storage program, when the data storage program is executed by a processor, implementing data storage as described above Any step in the method.

The data storage method, device and computer readable storage medium provided by the present application determine the number of OSDs used by each service group according to a preset rule, and assign a unique sub-cluster identifier to the OSD of the same service group, thereby In the topological structure, the logical hierarchy of a sub-cluster is added to the hierarchy of the host. Then, the data file is evenly divided into multiple data blocks, and each data block is mapped into a placement group (PG), and finally Multiple copies of each PG are stored in the OSD with the corresponding sub-cluster identification using the CRUSH algorithm. With the application, the reasonable configuration of the resources is realized, and the influence of the OSD failure on the storage system can be controlled within the scope of the sub-cluster.

DRAWINGS

1 is an application environment diagram of a preferred embodiment of an electronic device of the present application.

2 is a program block diagram of the data storage program of FIG. 1.

3 is a schematic diagram of data file storage of the present application.

4 is a flow chart of a preferred embodiment of a data storage method of the present application.

The implementation, functional features and advantages of the present application will be further described with reference to the accompanying drawings.

Detailed ways

Those skilled in the art will appreciate that embodiments of the present application can be implemented as a method, apparatus, device, system, or computer program product. Accordingly, the application can be embodied in a complete hardware, complete software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

The principles and spirit of the present application are described below with reference to a number of specific embodiments. It is understood that the specific embodiments described herein are merely illustrative of the application and are not intended to be limiting.

1 is an application environment diagram of a preferred embodiment of an electronic device of the present application. In this embodiment, the electronic device 1 is connected to the distributed storage system 3 via the network 2 and to the client 5 via the network 4. The distributed storage system 3 includes a plurality of cabinets, each of which has a plurality of cabinets, and each of the cabinets has a plurality of hosts, each of which contains a plurality of OSDs, and the hosts are connected by a fiber optic high-speed switch. Interconnecting is accomplished through a higher bandwidth fiber exchange. The electronic device 1 stores the data file transmitted by the user at the client 5 into the OSD of the distributed storage system 3 using the data storage program 10 provided by the present application.

The electronic device 1 may be a terminal device having a storage and computing function such as a server, a smart phone, a tablet computer, a portable computer, a desktop computer, or the like.

The electronic device 1 includes a memory 11, a processor 12, a network interface 13, and a communication bus 14.

The network interface 13 may include a standard wired interface, a wireless interface (such as a WI-FI interface). Communication bus 14 is used to implement connection communication between these components.

The memory 11 includes at least one type of readable storage medium. The at least one type of readable storage medium may be a non-volatile storage medium such as a flash memory, a hard disk, a multimedia card, a card type memory, or the like. In some embodiments, the readable storage medium may be an internal storage unit of the electronic device 1, such as a hard disk of the electronic device 1. In other embodiments, the readable storage medium may also be an external memory 11 of the electronic device 1, such as a plug-in hard disk equipped on the electronic device 1, a smart memory card (SMC). , Secure Digital (SD) card, Flash Card, etc.

In the present embodiment, the memory 11 stores program codes of the data storage program 10 and other data to which the processor 12 executes the program code of the data storage program 10, and finally outputted data and the like.

Processor 12 may be a Central Processing Unit (CPU), microprocessor or other data processing chip in some embodiments.

Figure 1 shows only the electronic device 1 with components 11-14, but it should be understood that not all illustrated components may be implemented, and more or fewer components may be implemented instead.

Optionally, the electronic device 1 may further include a user interface, and the user interface may include an input unit such as a keyboard, a voice input device such as a microphone, a device with a voice recognition function, a voice output device such as an audio, a headphone, and the like. Optionally, the user interface may also include a standard wired interface and a wireless interface.

Optionally, the electronic device 1 may further include a display. The display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, an OLED (Organic Light-Emitting Diode) touch sensor or the like in some embodiments. The display is used to display information processed by the electronic device 1 and a visualized user interface.

Optionally, the electronic device 1 further comprises a touch sensor. The area provided by the touch sensor for the user to perform a touch operation is referred to as a touch area. Further, the touch sensor described herein may be a resistive touch sensor, a capacitive touch sensor, or the like. Moreover, the touch sensor includes not only a contact type touch sensor but also a proximity type touch sensor or the like. Furthermore, the touch sensor may be a single sensor or a plurality of sensors arranged, for example, in an array. The user can start the data storage program 10 by touching.

The electronic device 1 may further include a radio frequency (RF) circuit, a sensor, an audio circuit, and the like, and details are not described herein.

The data storage program 10 of FIG. 1, when executed by the processor 12, implements the following steps:

Device allocation step: determining the number of OSDs used by each service group according to a preset rule every preset period, and assigning a unique sub-cluster identifier to the OSD of the same service group;

Request receiving step: receiving a request for a user to store a data file to a distributed storage system;

The service group determining step is: determining, according to the identification information of the user, the service group to which the user belongs and the sub-cluster identifier of the service group OSD; and

File storage step: uniformly divide the data file into a plurality of data blocks, and store multiple copies of each data block in an OSD having a corresponding sub-cluster identifier by using a CRUSH algorithm.

For a detailed description of the above steps, please refer to the following description of the program block diagram of the data storage program 10, the schematic diagram of the data file storage of FIG. 3, and the flowchart of the preferred embodiment of the data storage method of FIG.

Referring to FIG. 2, it is a program block diagram of the data storage program 10 of FIG. In the present embodiment, the data storage program 10 is divided into a plurality of modules, which are stored in the memory 11 and executed by the processor 12 to complete the present application. A module as referred to in this application refers to a series of computer program instructions that are capable of performing a particular function.

The data storage program 10 can be divided into: a device allocation module 110, a request receiving module 120, a service group determining module 130, and a file storage module 140.

The device allocation module 110 is configured to determine the number of OSDs used by each service group according to a preset rule every preset period, and allocate a unique sub-cluster identifier to the OSD of the same service group. In this embodiment, the preset period is one quarter, and the preset rule includes:

Counting historical data of data stored in a distributed storage system by each service group in a preset period (for example, the first three months), including total data size, total number of OSDs involved, and number of OSDs in which data migration occurs;

Calculate the average data size of the data stored in the distributed storage system by all service groups in the preset time range, and the average OSD involved, according to the total data size of each service group, the total number of OSDs involved, and the number of OSDs in which data migration occurs. The number and the average number of OSDs where data migration occurs;

When the difference between the total data size of the service group and the average data size is greater than a first preset threshold (for example, 500 GB), a first preset number is added to the service group based on the total number of OSDs involved (for example, 2) OSD,

When the difference between the number of OSDs in which data migration occurs in the service group and the average number of OSDs in which data migration occurs in each service group is greater than a second predetermined threshold (for example, two), the service is based on the total number of OSDs involved. The group adds a second predetermined number (eg, 1) of OSDs.

The preset rule is to dynamically allocate sufficient OSDs for service groups with large number of services and frequent data migration according to actual service requirements. When an OSD is assigned to a service group, the OSDs with different sub-cluster IDs should be located on different hosts, so that the logical division of the sub-clusters added in the topology of the cluster is above the level of the host.

The request receiving module 120 is configured to receive a request for the user to store the data file to the distributed storage system. When the user issues a request to the distributed storage system to store the data file at the client 5, the request receiving module 120 receives the request and sends the request to the distributed storage system 3.

The service group determining module 130 is configured to determine, according to the identification information of the user, the service group to which the user belongs and the sub-cluster identifier of the service group OSD. Because the device allocation module 110 allocates the determined OSD for each service group, when storing the data file, it is first determined which service group the data file belongs to, thereby determining the storage range of the data file, and the storage data can be sent by identifying at this time. The user requesting the file knows the business group to which the data file belongs. The identification information of the user may include a user IP address, a system login name, identity verification information, and the like.

The file storage module 140 divides the data file into a plurality of data blocks uniformly, and stores multiple copies of each data block in an OSD having a corresponding sub-cluster identifier by using a CRUSH algorithm. In this embodiment, when storing the data file, the data file is first uniformly divided into a plurality of data blocks according to a specific size, and each data block is mapped into one PG to obtain a PG identification code of each PG ( PlacementGroupid, PGid) Finally, multiple copies of the PG are stored in the OSD with the corresponding sub-cluster identifier according to the PGid using the CRUSH algorithm. A PG has n copies, which are stored in n OSDs. The value of n can be configured according to the reliability requirements of the actual application. In the normal case, the value is 3. The process of evenly dividing a data file into data blocks is similar to the process of disk striping. The purpose of this is to: firstly, data files of different sizes can be changed into multiple data blocks with uniform capacity for efficient management; Second, the serial processing of the data file becomes parallel processing of a plurality of data blocks, and the processing speed is improved. When Ceph distributed storage system divides data files into data blocks, the default data block size is 4MB. Therefore, when a data file is divided into data blocks, the number of data blocks is usually very large. If a large number of objects are traversed in a storage device cluster. Addressing, the speed will be very slow, in order to solve these problems, we introduce the concept of PG. A PG is an abstract storage node. Each data block is fixedly mapped to a PG, and a PG can usually contain multiple objects. All data blocks in the same PG have the same storage strategy, that is, the data blocks in the same PG will be stored in the same OSD, and different copies of the same PG can be regarded as similar PGs, but they will It is stored in different OSDs. In the present embodiment, PG is used as a basic unit in data addressing or data migration, and data blocks are not directly manipulated. The service group to which the data file belongs is known by the service group determining module 130. The number of OSDs used by each service group is determined by the device allocation module 110. Therefore, the number of PGs can be set because the setting of the number of PGs generally follows the following rules:

When the number of OSDs used is less than 5, the number of PGs is set to 128;

When the number of OSDs used is 5 to 10, the number of PGs is set to 512;

When the number of OSDs used is 10 to 50, the number of PGs is set to 4096;

When the number of OSDs used is greater than 50, the number of PGs can be calculated using a tool such as PGCalculator.

Once the number of PGs is determined, it is usually not changed because it significantly affects the behavior of the cluster and the data persistence in the event of a failure such as OSD, that is, the probability of data loss caused by a catastrophic event.

The CRUSH algorithm can calculate the storage location of the data, ie which OSD each copy of each PG will be stored on, which can ensure that different copies of the same PG are stored in different OSDs. The CRUSH algorithm requires a description map of the cluster topology (CRUSH Map) when calculating the data storage location. In this embodiment, we change the CRUSH Map, and a sub-cluster is added to the hierarchy of the host in the topology of the cluster. The logical division. Referring to FIG. 3, which is a schematic diagram of the file storage of the present application, we use a plurality of hosts including the OSD used by each service group as a sub-cluster, and each sub-cluster is dedicated to storing data of a certain service group. In this way, when calculating the data storage location, the CRUSH algorithm can ensure that multiple copies of each PG are stored in the same sub-cluster and different copies of the same PG are stored on different hosts.

It can be understood that the data files of different business groups are stored in different sub-clusters. For example, China Ping An Insurance (Group) Co., Ltd. stores the data files of life insurance and the data files of property insurance in a sub-cluster. The advantage of this is that when an OSD fails, the data stored in the OSD of the sub-cluster of the OSD belongs to the data stored in the OSD, and the data is not lost, and the data recovery process does not occupy the system of other service groups. The data does not affect the data access performance of other service groups. When the number of failed OSDs is greater than or equal to the number of copies, the data may be lost, but only the data of the service group corresponding to the sub-cluster where the failed OSD is located is lost. It does not affect the data of other business groups and does not affect the data access performance of other business groups.

Referring to FIG. 4, it is a flowchart of a preferred embodiment of the data storage method of the present application. With the architecture shown in FIG. 1, the electronic device 1 is booted, and the processor 12 executes the data storage program 10 stored in the memory 11, implementing the following steps:

In step S10, the device allocation module 110 determines the number of OSDs used by each service group according to a preset rule every preset period, and allocates a unique sub-cluster identifier to the OSD of the same service group. In this embodiment, the OSDs with different sub-cluster identifiers should be located on different hosts, so that the logical division of the sub-cluster added in the topology of the cluster is above the hierarchy of the host. For the preset period and preset rules, please refer to the above detailed description about the device allocation module 110.

In step S20, the request receiving module 120 is used to receive a request for the user to store the data file to the distributed storage system. When the user issues a request to store the data file to the distributed storage system on the electronic device 1, the request receiving module 120 receives the request for the user to store the data file, and sends the request to the distributed storage system 3.

In step S30, the service group determining module 130 determines the service group to which the user belongs and the sub-cluster identifier of the service group OSD according to the identification information of the user. The identification information of the user may include an IP address, a system login name, identity verification information, and the like. The storage bit range of the data file can be known by determining the service group to which the user who issued the request to store the data file belongs.

In step S40, the data file is evenly divided into a plurality of data blocks by using the file storage module 140, and multiple copies of each data block are stored in the OSD having the corresponding sub-cluster identifier. For the specific process of data file storage, please refer to the above detailed description of the file storage module 140. It should be further explained that the user stores the data file, that is, when the client writes a data file, multiple copies of one PG include one master copy and multiple slave copies, and the CRUSH algorithm calculates the number of copies for each PG. An equal OSD, for example, assuming that a PG has one master copy and two slave copies, the CRUSH algorithm calculates three OSDs for the PG and encodes the three OSDs so that the three OSDs have different sequence numbers. The first OSD of the serial number is used to store the primary copy, and the other two OSDs are used to store the secondary copy. When storing data files, all copies must be stored in the OSD, and all read operations are read from the primary copy when the data is read. When the OSD where the primary copy is located fails, the file storage module 140 automatically recalculates the OSD by using the CRUSH algorithm for data migration and recovery. The original storage OSD from the copy of the OSD is set to replace the OSD of the primary copy. , began to provide external data reading operations. When the failure occurs from the OSD where the copy is located, the file storage module 140 automatically recalculates the OSD by using the CRUSH algorithm, but does not affect the location of the OSD where the primary copy is located.

In addition, the embodiment of the present application further provides a computer readable storage medium, which may be a hard disk, a multimedia card, an SD card, a flash memory card, an SMC, a read only memory (ROM), and an erasable programmable Any combination or combination of any one or more of read only memory (EPROM), portable compact disk read only memory (CD-ROM), USB memory, and the like. The computer readable storage medium includes a file to be stored and a data storage program 10, and when the data storage program 10 is executed by the processor, the following operations are implemented:

Device allocation step: determining the number of OSDs used by each service group according to a preset rule every preset period, and assigning a unique sub-cluster identifier to the OSD of the same service group;

Request receiving step: receiving a request for a user to store a data file to a distributed storage system;

The service group determining step is: determining, according to the identification information of the user, the service group to which the user belongs and the sub-cluster identifier of the service group OSD; and

File storage step: uniformly divide the data file into a plurality of data blocks, and store multiple copies of each data block in an OSD having a corresponding sub-cluster identifier by using a CRUSH algorithm.

The specific implementation of the computer readable storage medium of the present application is substantially the same as the above-described data storage method and the specific embodiment of the electronic device 1, and details are not described herein again.

It is to be understood that the term "comprises", "comprising", or any other variants thereof, is intended to encompass a non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a series of elements includes those elements. It also includes other elements not explicitly listed, or elements that are inherent to such a process, device, item, or method.

The serial numbers of the embodiments of the present application are merely for the description, and do not represent the advantages and disadvantages of the embodiments. Through the description of the above embodiments, those skilled in the art can clearly understand that the foregoing embodiment method can be implemented by means of software plus a necessary general hardware platform, and of course, can also be through hardware, but in many cases, the former is better. Implementation. Based on such understanding, the technical solution of the present application, which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium (such as ROM/RAM as described above). , a disk, an optical disk, including a number of instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the methods described in the various embodiments of the present application.

The above is only a preferred embodiment of the present application, and is not intended to limit the scope of the patent application, and the equivalent structure or equivalent process transformations made by the specification and the drawings of the present application, or directly or indirectly applied to other related technical fields. The same is included in the scope of patent protection of this application.

Claims (20)

A data storage method is applied to an electronic device, the electronic device is connected to a distributed storage system through a network, and the distributed storage system provides a series of hosts and an OSD, wherein the method comprises: Device allocation step: determining the number of OSDs used by each service group according to a preset rule every preset period, and assigning a unique sub-cluster identifier to the OSD of the same service group; Request receiving step: receiving a request for a user to store a data file to a distributed storage system; The service group determining step is: determining, according to the identification information of the user, the service group to which the user belongs and the sub-cluster identifier of the service group OSD; and File storage step: uniformly divide the data file into a plurality of data blocks, and store multiple copies of each data block in an OSD having a corresponding sub-cluster identifier by using a CRUSH algorithm. The data storage method according to claim 1, wherein the preset rule in the device allocation step comprises: Counting historical data of data stored in a distributed storage system by each service group in a preset period, including total data size, total number of OSDs involved, and number of OSDs in which data migration occurs; Calculate the average data size, average OSD quantity, and occurrence of data stored in the distributed storage system by all service groups in the preset period according to the total data size of each service group, the total number of OSDs involved, and the number of OSDs in which data migration occurs. The average number of OSDs for data migration; When the difference between the total data size of a service group and the average data size of all the service groups is greater than the first preset threshold, the first preset quantity is added to the service group based on the total number of OSDs involved. OSD; When the difference between the number of OSDs in which data migration occurs in a certain service group and the average number of OSDs in which data migration occurs in each service group is greater than a second preset threshold, the service group is added based on the total number of OSDs involved. The second predetermined number of OSDs. The data storage method according to claim 1, wherein the OSDs having different sub-cluster identifiers are located on different hosts. The data storage method according to claim 2, wherein the OSDs having different sub-cluster identifiers are located on different hosts. The data storage method according to claim 2, wherein said file storage step comprises the following steps: Evenly dividing the data file into a plurality of data blocks; Map each data block to a PG; Multiple copies of each PG are stored in the OSD with the corresponding sub-cluster identification using the CRUSH algorithm. The data storage method according to claim 1, further comprising: when an OSD fails, recovering data stored in the OSD by using replica data stored by other OSDs of the sub-cluster to which the OSD belongs. The data storage method according to claim 2, wherein the method further comprises: when an OSD fails, recovering data stored in the OSD by using replica data stored by other OSDs of the sub-cluster to which the OSD belongs. An electronic device includes a memory and a processor, wherein the memory includes a data storage program, and the data storage program is executed by the processor to implement the following steps: Device allocation step: determining the number of OSDs used by each service group according to a preset rule every preset period, and assigning a unique sub-cluster identifier to the OSD of the same service group; Request receiving step: receiving a request for a user to store a data file to a distributed storage system; The service group determining step is: determining, according to the identification information of the user, the service group to which the user belongs and the sub-cluster identifier of the service group OSD; and File storage step: uniformly divide the data file into a plurality of data blocks, and store multiple copies of each data block in an OSD having a corresponding sub-cluster identifier by using a CRUSH algorithm. The electronic device according to claim 8, wherein the preset rule in the device allocation step comprises: Counting historical data of data stored in a distributed storage system by each service group in a preset period, including total data size, total number of OSDs involved, and number of OSDs in which data migration occurs; Calculate the average data size, average OSD quantity, and occurrence of data stored in the distributed storage system by all service groups in the preset period according to the total data size of each service group, the total number of OSDs involved, and the number of OSDs in which data migration occurs. The average number of OSDs for data migration; When the difference between the total data size of a service group and the average data size of all the service groups is greater than the first preset threshold, the first preset quantity is added to the service group based on the total number of OSDs involved. OSD; When the difference between the number of OSDs in which data migration occurs in a certain service group and the average number of OSDs in which data migration occurs in each service group is greater than a second preset threshold, the service group is added based on the total number of OSDs involved. The second predetermined number of OSDs. The electronic device of claim 8 wherein the OSDs having different sub-cluster identifications are located on different hosts. The electronic device of claim 9, wherein the OSDs having different sub-cluster identifiers are located on different hosts. The electronic device of claim 8, wherein the file storing step comprises the steps of: Evenly dividing the data file into a plurality of data blocks; Map each data block to a PG; Multiple copies of each PG are stored in the OSD with the corresponding sub-cluster identification using the CRUSH algorithm. The electronic device according to claim 8, wherein said data storage program is further executed by said processor: when an OSD fails, utilizing a copy of another OSD stored by the sub-cluster to which the OSD belongs The data is restored to the data stored in the OSD. The electronic device according to claim 9, wherein said data storage program is further executed by said processor to: when an OSD fails, utilizing a copy of another OSD stored by the sub-cluster to which the OSD belongs The data is restored to the data stored in the OSD. A computer readable storage medium, comprising: a data storage program, wherein when the data storage program is executed by a processor, the following steps are implemented: Device allocation step: determining the number of OSDs used by each service group according to a preset rule every preset period, and assigning a unique sub-cluster identifier to the OSD of the same service group; Request receiving step: receiving a request for a user to store a data file to a distributed storage system; The service group determining step is: determining, according to the identification information of the user, the service group to which the user belongs and the sub-cluster identifier of the service group OSD; and File storage step: uniformly divide the data file into a plurality of data blocks, and store multiple copies of each data block in an OSD having a corresponding sub-cluster identifier by using a CRUSH algorithm. The storage medium according to claim 15, wherein the preset rule in the device allocation step comprises: The historical data of the data stored in the distributed storage system by each service group in a preset period, including the total data size, the total number of OSDs involved, and the number of OSDs in which data migration occurs; Calculate the average data size, average OSD quantity, and occurrence of data stored in the distributed storage system by all service groups in the preset period according to the total data size of each service group, the total number of OSDs involved, and the number of OSDs in which data migration occurs. The average number of OSDs for data migration; When the difference between the total data size of a service group and the average data size of all the service groups is greater than the first preset threshold, the first preset quantity is added to the service group based on the total number of OSDs involved. OSD; When the difference between the number of OSDs in which data migration occurs in a certain service group and the average number of OSDs in which data migration occurs in each service group is greater than a second preset threshold, the service group is added based on the total number of OSDs involved. The second predetermined number of OSDs. The storage medium of claim 15 wherein the OSDs having different sub-cluster identifications are located on different hosts. The storage medium of claim 16 wherein the OSDs having different sub-cluster identifications are located on different hosts. A storage medium according to claim 15, wherein said file storing step comprises the steps of: Evenly dividing the data file into a plurality of data blocks; Map each data block to a PG; Multiple copies of each PG are stored in the OSD with the corresponding sub-cluster identification using the CRUSH algorithm. A storage medium according to claim 15 or 16, wherein said data storage program is further executed by said processor to: when an OSD fails, utilizing other OSD storage of the sub-cluster to which the OSD belongs The copy data is restored to the data stored in the OSD.

Images