CN113946291A - Data access method, device, storage node and readable storage medium - Google Patents
Data access method, device, storage node and readable storage medium Download PDFInfo
- Publication number
- CN113946291A CN113946291A CN202111221639.9A CN202111221639A CN113946291A CN 113946291 A CN113946291 A CN 113946291A CN 202111221639 A CN202111221639 A CN 202111221639A CN 113946291 A CN113946291 A CN 113946291A
- Authority
- CN
- China
- Prior art keywords
- data
- block device
- metadata
- accessed
- access
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/061—Improving I/O performance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0638—Organizing or formatting or addressing of data
- G06F3/064—Management of blocks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention relates to the technical field of distributed storage, and provides a data access method, a device, a storage node and a readable storage medium, wherein the method comprises the following steps: receiving a data access request sent by a client, wherein the data access request carries a target block device and an access address to be accessed by data to be accessed, and the target block device is one of at least one block device; if the target block device has a corresponding target file system view, determining a data type of data to be accessed according to the target file system view and the access address, wherein the target file system view is used for representing a spatial layout mode of the target block device, and the data type comprises a metadata type and a non-metadata type; and accessing the data to be accessed according to the data type and the access address, and responding to the client. The embodiment of the invention introduces the file system view representing the space layout mode of the block device, and improves the overall access performance of the distributed storage system.
Description
Technical Field
The invention relates to the technical field of distributed storage, in particular to a data access method, a data access device, a storage node and a readable storage medium.
Background
In a distributed storage system, block storage is a common way of managing the space of the distributed storage system, and the block storage is to divide the space of the distributed storage system into unit blocks and manage the space according to the unit blocks, so data in the distributed storage system generally includes two categories, namely metadata and application data, the metadata is data for managing the unit blocks of the distributed storage system, the application data is data that a user needs to store into the unit blocks of the distributed storage system, and for convenience of management, the existing distributed storage system generally does not distinguish the metadata and the application data, and stores the metadata and the application data uniformly according to the data.
Disclosure of Invention
The invention aims to provide a data access method, a data access device, a storage node and a readable storage medium, which can identify whether data to be accessed is a metadata type or a non-metadata type, so that different access strategies can be conveniently used for accessing according to different types of data to be accessed, and the overall access performance of a distributed storage system is improved.
In order to achieve the purpose, the technical scheme adopted by the invention is as follows:
in a first aspect, the present invention provides a data access method, applied to a storage node of a distributed storage system, where the storage node is in communication connection with a client, and the distributed storage system includes at least one block device, where the method includes: receiving a data access request sent by the client, wherein the data access request carries a target block device to be accessed by data to be accessed and an access address, and the target block device is one of the at least one block device; if the target block device has a corresponding target file system view, determining a data type of the data to be accessed according to the target file system view and the access address, wherein the target file system view is used for representing a spatial layout mode of the target block device, and the data type comprises a metadata type and a non-metadata type; and accessing the data to be accessed according to the data type and the access address, and responding to the client.
In a second aspect, the present invention provides a data access apparatus, applied to a storage node of a distributed storage system, where the storage node is communicatively connected to a client, and the distributed storage system includes at least one block device, where the apparatus includes: a receiving module, configured to receive a data access request sent by the client, where the data access request carries a target block device and an access address to be accessed by data to be accessed, and the target block device is one of the at least one block device; a determining module, configured to determine a data type of the data to be accessed according to the target file system view and the access address if the target block device has a corresponding target file system view, where the target file system view is used to represent a spatial layout manner of the target block device, and the data type includes a metadata type and a non-metadata type; and the access module is used for accessing the data to be accessed according to the data type and the access address and responding to the client.
In a third aspect, the present invention provides a storage node, comprising a memory and a processor, wherein the memory stores a computer program, the storage node is in communication connection with a client, and the processor executes the computer program to implement the data access method.
In a fourth aspect, the invention provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements a data access method as described above.
Compared with the prior art, the file system view representing the spatial layout mode of the block device is introduced, and whether the data to be accessed is the metadata type or the non-metadata type is identified through the perceived spatial layout mode and the access address of the block device, so that the data to be accessed can be accessed by adopting different access strategies according to different types of data to be accessed, and the overall access performance of the distributed storage system is improved.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present invention and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained according to the drawings without inventive efforts.
Fig. 1 is an exemplary diagram of an application scenario provided in an embodiment of the present invention.
Fig. 2 is a schematic block diagram of a storage node according to an embodiment of the present invention.
Fig. 3 is a diagram illustrating an example of a software architecture applied to fig. 1 according to an embodiment of the present invention.
Fig. 4 is a flowchart illustrating formatting of a block device in a data access method according to an embodiment of the present invention.
Fig. 5 is a diagram illustrating a layout of a file system according to an embodiment of the present invention.
Fig. 6 is a flowchart illustrating a data access method according to an embodiment of the present invention.
Fig. 7 is a flowchart illustrating another data access method according to an embodiment of the present invention.
Fig. 8 is a flowchart illustrating another data access method according to an embodiment of the present invention.
Fig. 9 is a flowchart illustrating another data access method according to an embodiment of the present invention.
Fig. 10 is a block diagram of a data access device according to an embodiment of the present invention.
Icon: 10-a storage node; 11-a processor; 12-a memory; 13-a bus; 14-a communication interface; 20-a client; 100-a data access device; 110-a receiving module; 120-a determination module; 130-an access module; 140-formatting module.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. The components of embodiments of the present invention generally described and illustrated in the figures herein may be arranged and designed in a wide variety of different configurations.
Thus, the following detailed description of the embodiments of the present invention, presented in the figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of selected embodiments of the invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.
In the description of the present invention, it should be noted that if the terms "upper", "lower", "inside", "outside", etc. indicate an orientation or a positional relationship based on that shown in the drawings or that the product of the present invention is used as it is, this is only for convenience of description and simplification of the description, and it does not indicate or imply that the device or the element referred to must have a specific orientation, be constructed in a specific orientation, and be operated, and thus should not be construed as limiting the present invention.
Furthermore, the appearances of the terms "first," "second," and the like, if any, are used solely to distinguish one from another and are not to be construed as indicating or implying relative importance.
It should be noted that the features of the embodiments of the present invention may be combined with each other without conflict.
The complexity of a distributed storage system that utilizes block storage for space management is mainly manifested in two ways: the cluster scale relates to hundreds of storage nodes and thousands of disks; one is data processing logic, which involves data redundancy calculation, flow control policy, hierarchical storage, and the like. Therefore, the management work for the distributed storage system is also more challenging. While the unified storage of metadata and application data provides administrative convenience, the overall access performance of distributed storage systems is still less than ideal.
In view of this problem, the inventor carefully analyzes the process of block storage, and finds that IO characteristics are one of the main factors affecting the overall access performance of the distributed storage system, and the IO characteristics generally include IO size, randomness and sequence of IO, and generally under different application scenarios, the IO characteristics are different, for example, in a database application scenario, the IO characteristics are generally small block IO and mostly random IO, and in a video monitoring application scenario, the IO characteristics are generally large block IO and mostly sequential IO. Although different distributed storage systems may be tailored for different application scenarios, even then, the overall performance of the distributed storage system is still not greatly improved. As a result of further research, the inventors found that, in fact, in the same application scenario, for example, a video surveillance application scenario, the IO characteristics of application data and metadata are also significantly different, where the application data is usually large blocks and mostly sequential IO, and the metadata is usually small blocks and mostly random IO. In addition, the inventor also found that, in general, the storage space for storing metadata is much smaller than that for storing application data, and the ratio of metadata access to application data access is close to 1:1, that is, metadata access is more intensive, and the access pressure is much higher than that of application data.
In the case where the IO characteristics of metadata and application data are so different, if the metadata and the application data are not distinguished, it may occur in a Ceph RBD (Ceph is an open source distributed storage system, and a Ceph RBD is a block device in Ceph): for an application scene with application data being large blocks, metadata has the problems of serious write amplification and space waste, and IO of non-stripe aligned original data introduces a complementary stripe read operation and a whole stripe update operation, so that the access delay of the metadata IO is relatively high; non-storage-unit-aligned over write operations, performing Copy-on-write (COW) requires allocation of new storage units, all of which affect the overall access performance of the distributed storage system.
In view of the above, the inventors provide a data access method, apparatus, storage node, and readable storage medium, which greatly optimize the overall access performance of a distributed storage system by identifying metadata and application data and accessing the metadata and the application data by using different access policies, and will be described in detail below.
Referring to fig. 1, fig. 1 is an exemplary diagram of an application scenario provided in an embodiment of the present invention, a distributed storage system includes a plurality of storage nodes 10, a client 20 is in communication connection with the plurality of storage nodes 10, a user issues a creation request for creating a block device on an operation interface through the operation interface provided by the distributed storage system, the user can designate a corresponding file system view while creating the block device, and the distributed storage system establishes a corresponding relationship between the block device and the file system view. The user loads the established block device to the local, before using the block device, an initialization command can be issued to initialize the file system of the block device, and after receiving the initialization command, the distributed storage system initializes the block device according to the file system view corresponding to the block device. After the block device is initialized, a user may send a data write request to the storage node 10 through the client 20 to write data to be written to the storage node 10, and may also send a data read request to the storage node 10 to read data in the storage node 10.
The storage node 10 may be a single storage server, or a storage array or a server group consisting of a plurality of storage servers. One storage node 10 may include a plurality of hard disks, which may be of the same type or different types, for example, one storage node 10 may include both a HDD type hard disk and an SSD type hard disk.
The client 20 may be a general host or an application platform.
On the basis of fig. 1, an embodiment of the present invention further provides a block schematic diagram of the storage node 10 in fig. 1, please refer to fig. 2, and fig. 2 is a block schematic diagram of the storage node 10 according to the embodiment of the present invention, where the storage node 10 includes a processor 11, a memory 12, a bus 13, and a communication interface 14. The processor 11 and the memory 12 are connected by a bus 13, and the processor 11 communicates with the client 20 through a communication interface 14.
The processor 11 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware or instructions in the form of software in the processor 11. The Processor 11 may be a general-purpose Processor, and includes a Central Processing Unit (CPU), a Network Processor (NP), and the like; but may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components.
The memory 12 is used for storing a program, for example, a data access device in the embodiment of the present invention, the data access device includes at least one software functional module which can be stored in the memory 12 in a form of software or firmware (firmware), and the processor 11 executes the program after receiving an execution instruction to implement the data access method in the embodiment of the present invention.
The Memory 12 may include a high-speed Random Access Memory (RAM) and may also include a non-volatile Memory (non-volatile Memory). Alternatively, the memory 12 may be a storage device built in the processor 11, or may be a storage device independent of the processor 11.
The bus 13 may be an ISA bus, a PCI bus, an EISA bus, or the like. Fig. 2 is represented by only one double-headed arrow, but does not represent only one bus or one type of bus.
Referring to fig. 3, fig. 3 is a diagram illustrating an example of a software architecture applied to fig. 1 according to an embodiment of the present invention. In fig. 3, the software architecture mainly includes three functional components: a Data Storage Server (DSS) cluster component, a Metadata Server MDS cluster (MDS) component, and a Virtual Block Device interface (VBD) component.
The DSS is mainly responsible for file storage and mainly comprises a Throttle module, an EVFSX module and a Beacon module. The thread module is used for performing priority flow control on the metadata and the application data, for example, the priority of metadata access is higher than that of the application data. The EVFSX module manages the space of the physical hard disk, and when the physical hard disk comprises an HDD disk and an SSD disk with different performances, the physical hard disk can also provide a layered storage function through the CacheTier submodule, for example, metadata is stored to the SSD disk, application data is stored to the HDD disk, and optimization of metadata access performance is realized. The Beacon module provides heartbeat detection to ensure that the storage server of the DSS can timely sense the state of the original data server.
The MDS is mainly responsible for managing a Virtual Block Device (VBD) and a file system view, and mainly includes a VBD management module and a Distributed Scheduling module (i.e., a Distributed Scheduling module). The VBD management module manages a block data organization structure and mainly comprises two information tables: the file system view information table comprises related information of the file system view, including a file system name, a file storage space size, file system parameters, a file system metadata segment and the like. The distributed scheduling module performs load balancing on the access requests by collecting information such as cpus, memories and capacities of all the storage servers in the DSS, so as to avoid that all the access requests are concentrated in a part of the storage servers in the DSS.
The libVBD is mainly responsible for converting standard operation of the VBD into operation of an internal file, identifying whether the file operation is metadata operation or application data operation according to a file system view corresponding to the VBD, and comprises a VBD Cache module which is responsible for caching the file system view of the VBD.
On the basis of fig. 1 and fig. 2, in conjunction with the software architecture diagram shown in fig. 3, an embodiment of the present invention further provides a data access method applied to the storage node 10 in fig. 1 and fig. 2. It should be noted that, before data access, a user first needs to create a block device and format the block device, and then can store data into the formatted block device, and then read the previously stored data from the block device.
It should be noted that a block device is a logical space visible to a user, and actually, what provides real storage space for the logical space is one or more hard disks on one or more storage nodes 10.
In order to describe the whole data access process more completely, the embodiment of the present invention starts with the creation process of the block device, and then describes the formatting process of the block device and the data access process in the block device in sequence.
As a specific implementation manner, the distributed storage system stores a plurality of file system views and identifiers thereof in advance, generates a unique block device identifier (also referred to as a block device ID) for a block device to be created, and generates a mapping table between the block device identifier and the identifier of the corresponding file system view (also referred to as a file system view ID), that is, the block device information table in fig. 3, to represent the mapping relationship between the two, table 1 is an example of a block device information table.
TABLE 1
| Block device ID (64Bytes) | File system view ID (64Bytes) |
| Lun1 | Ext-0 |
| Lun2 | Ext-0 |
| Lun3 | Ext-1 |
| Lun4 | Evfs-0 |
It should be noted that, in order to centrally manage the related information of each file system view and avoid maintaining the related information of the corresponding file system view for each block device, as a specific implementation manner, another table may also be used to manage the related information of the file system view, that is, the file system view information table in fig. 3, where table 2 is an example of the file system view information table.
TABLE 2
The file system parameters in table 2 include three parameters, namely block size (block size), inode size (inode size), and average file size (average file size), each of which occupies 1 byte, and as a specific implementation, the 1 st byte describes block size in a unit of 4KB, for example: the value n represents a block size of 2^ n × 4KB, the 2 nd byte describes the inode size, in units of 128Bytes, such as: the value n represents the inode size of 2^ n × 128Bytes, the 3 rd byte describes the average file size in units of 4KB, such as: the value n indicates that the block size is 2^ n × 4KB, the remaining bytes reservations are unused, e.g., for Ext-0, the first 3 numbers in the file system parameters: 0, 0, 2, respectively representing block size, inode size and average file size as: 20 × 4KB, 2 × 0 × 128KB, 2 × 4KB 16KB, wherein the last 5 "-1" represents that the byte is reserved.
"N" in table 2 represents the number of the single block groups, the block device is divided into a plurality of unit blocks according to block size, the unit blocks are grouped to obtain the unit block group, metadata is stored in a preset address field of each unit block, the file system metadata field includes preset address fields of all unit blocks, for example, for Ext-1, the file system metadata field includes N preset address fields, and the 1 st preset address field is: 0 ~ 2113535, the 2 nd preset address field is: 536870912-538976255, the rest of the default address segments will not be described again.
In this embodiment, the file system view may be a standard file system or a private file system, the standard file system is a recognized file system, for example, Ext2, Ext3, Ext4, and the file system parameters of different standard file systems may be different. The private file system is generally a file system which is customized and developed by a manufacturer of the distributed storage system according to the requirements of a user, and for the private file system, the user can preset by accessing an operation page provided by the distributed storage system, and specify file system parameters of the required private file system, and then specify the previously set private file system when creating the block device.
It should be noted that the user may also not specify the file system view when creating the block device, and in this case, the block device is laid out and used according to the implementation manner in the prior art.
In this embodiment, after the block device is created, the block device needs to be formatted before the block device is used, and the process of formatting the block device will be described below.
Referring to fig. 4, fig. 4 is a flowchart illustrating a block device formatting process in a data access method according to an embodiment of the present invention, where the method includes the following steps:
step S100, a block device formatting command sent by a client is received, wherein the block device formatting command comprises a block device to be formatted, which is specified from at least one block device.
In this embodiment, the distributed storage system may include one or more block devices, each block device has a file system view corresponding to the block device, an operation page provided by the distributed storage system may display unformatted block devices, or may display all block devices, including formatted and unformatted block devices, and a user accesses the operation page provided by the distributed storage system through a client to select a block device to be formatted, and issues a format command by clicking a preset format button.
Step S110, obtaining layout parameters of the file system view corresponding to the block device to be formatted.
In this embodiment, as a specific implementation manner, the layout parameters of the file system view corresponding to the block device to be formatted may be obtained through the block device information table and the file system view information table in fig. 3.
And step S120, formatting the space of the block device to be formatted according to the layout parameters.
In this embodiment, the layout parameters may include a block size, an average file size, and a management node size, a space of the device to be formatted is divided into a plurality of unit blocks according to the block size, the unit blocks are management units of the block device, and the average file size may be estimated according to an actual application scenario, for example, for a large IO request, the average file size may be set to be larger, and for a small IO request, the average file size may be set to be smaller. The size of the management node determines the number of management nodes which can be managed, for a file storage system, directories and files are managed according to files, each directory or each file corresponds to one management node, and the management node records relevant information of the directories or the files and is used for indexing targets or files or accessing data in the targets or the files.
In this embodiment, as a specific implementation manner of formatting, the implementation steps may be:
first, the space of a device to be formatted is partitioned according to the block size to obtain a plurality of cell blocks.
Secondly, grouping a plurality of cell blocks to obtain a plurality of block groups.
Thirdly, according to the block size, the average file size and the size of the management node, the metadata address field of each block group is determined.
In this embodiment, the block sizes, the average file sizes, and the sizes of the management nodes are different, and the layouts of the block devices are different, please refer to fig. 5, fig. 5 is a layout example diagram of a file system provided in the embodiment of the present invention, fig. 5(a) is a layout example diagram of a standard file system, and fig. 5(b) is a layout example diagram of a private file system.
In fig. 5(a), the standard file system includes N Block groups (Block groups), each Block Group includes a unit Block bitmap (data Block bitmap), a management node bitmap (inode bitmap), a management node list (inode table), and unit blocks (data blocks), and for the first Block Group (Block Group0), in addition to the above information, a boot Block, a super Block, and Group descriptor (Group descriptor) are included, each of which occupies a space of an integer number of sizes, for example, the boot Block and the super Block occupy a space of one unit Block size, and the Group descriptor occupies a space of N unit Block sizes.
In fig. 5(b), the private file system includes a Reserved area (Reserved), 2 super blocks (super), and N Block groups (Block groups), each Block Group includes a log area (log) for storing an operation log for operating the Block Group, a DNode area for managing a directory of the Block Group, a FNode area for managing a file of the Block Group, the Reserved area occupies 4MB space, each super Block occupies 4KB space, and the log area, the DNode area, and the FNode area occupy 4KB, and 8KB, respectively.
For FIG. 5(a), according to the layout in FIG. 5(a), the file system parameters are: block size is 4KB, inode size is 128bytes, average file size is 16KB, then the set of metadata segments is: [0,1064959], [ X,1064959+ X ], [2X,1064959+2X ], …, where X represents the file system chunk size. For FIG. 5(b), the file system parameters are, according to the layout in FIG. 5 (b): if the block size is 64MB, the inode size is 128Bytes, and the average file size is 64MB, then the metadata segment set is: [0,16 KB-1 ], [ Y +16KB, Y +2X 16-1 ], [2Y +2X 16KB,2Y +2X 16 KB-1 ], …, where Y is the file system chunk size.
And finally, taking the metadata address fields of all the block groups as the metadata address fields of the file system views corresponding to the block devices to be formatted.
According to the method provided by the embodiment of the invention, the block device is formatted according to the file system view configured for the block device in advance, so that the requirement of a user for formatting the block device according to an actual scene is met, on one hand, the configurable flexibility of formatting is improved, and on the other hand, the block device can be managed in a mode more in fit with the actual scene.
After formatting the block device, the data to be stored may be written into the block device, and the data in the block device may also be read out, and whether the block device is written into or read from is referred to as an access block device, an embodiment of the present invention provides a data access method for accessing the block device, please refer to fig. 6, where fig. 6 is a flowchart of a data access method provided by an embodiment of the present invention, and the method includes the following steps:
step S130, receiving a data access request sent by the client, where the data access request carries a target block device and an access address to be accessed by the data to be accessed, and the target block device is one of the at least one block device.
In this embodiment, the distributed storage system includes at least one block device, and the at least one block device may have a corresponding file system view, where the file system view is used to represent a spatial layout manner of the corresponding block device, for example, a size of a spatial management unit block of the block device, a number of unit block groups divided by the unit block, and the like. The target block device is one of the at least one block devices. When the data access request is a read request, the read request carries target block equipment which needs to be read for obtaining data to be read and an address to be read, and when the data access request is a write request, the write request carries the target block equipment which needs to be written in by the data to be written and the address to be written.
Step S140, if the target block device has a corresponding target file system view, determining a data type of the data to be accessed according to the target file system view and the access address, wherein the target file system view is used for representing a spatial layout mode of the target block device, and the data type includes a metadata type and a non-metadata type.
In this embodiment, the target file system view is a file system view corresponding to the target block device that is specified in advance, for example, when the target block device is created by the user.
In this embodiment, the data types include a metadata type and a non-metadata type, and in general, data of the metadata type may be directly referred to as metadata, and data of the non-metadata type may be directly referred to as data, user data, application data, or the like.
In this embodiment, as a specific implementation manner, in the target file view, the metadata is stored in the preset address field, and the data is stored in the address field other than the preset address field, so that the data type of the data to be accessed, that is, whether the data to be accessed is metadata or data, may be determined according to the metadata address field and the access address of the target file view.
And S150, accessing the data to be accessed according to the data type and the access address, and responding to the client.
In the embodiment, different access policies are adopted for different data types to access the data to be accessed. The differences in access policies include, but are not limited to, different access priorities (e.g., metadata access priority is higher than data access priority), different access performance storage (metadata is stored in higher performance storage, data is stored in lower performance storage), different storage policies (metadata employs a replica storage policy, data employs an erasure correction storage policy), and so forth.
According to the method provided by the embodiment of the invention, the file system view representing the space layout mode of the block device is introduced, and whether the data to be accessed is the metadata type or the non-metadata type is identified through the perceived space layout mode and the access address of the block device, so that the data to be accessed can be accessed by adopting different access strategies according to different types of data to be accessed, and the overall access performance of the distributed storage system is improved.
On the basis of fig. 5, an embodiment of the present invention further provides a specific implementation manner for determining a data type of data to be accessed, referring to fig. 7, fig. 7 is a flowchart illustrating another data access method provided in the embodiment of the present invention, and step S140 includes the following sub-steps:
in sub-step S1401, a metadata address field of the target file system view is acquired.
In this embodiment, for any piece of device, once the layout parameters of the file system view of the device are determined, the metadata address field for storing the metadata is also determined, and as a specific implementation manner, after the layout parameters are determined, the corresponding metadata address field may be pre-calculated and stored, for example, as shown in table 2 above.
And a substep S1402, determining that the data to be accessed is the metadata type if the access address is in the metadata address field.
In sub-step S1403, if the access address is outside the metadata address segment, it is determined that the data to be accessed is a non-metadata type.
According to the method provided by the embodiment of the invention, the data type of the data to be accessed can be simply and quickly judged by judging whether the access address is in the metadata address field of the target file system view.
On the basis of fig. 5, an embodiment of the present invention further provides a specific implementation manner for determining a data type of data to be accessed, please refer to fig. 8, fig. 8 is a flowchart illustrating another data access method provided in the embodiment of the present invention, and step S150 includes the following sub-steps:
in sub-step S1501, if the data type is the metadata type, it is determined that the to-be-accessed region is the metadata region, and the metadata region is managed according to the access characteristics of the metadata type.
In this embodiment, the access characteristic of the metadata type is generally high in access performance requirement and high in data reliability requirement, and for this access characteristic, a storage medium with high access performance, such as an SSD disk, may be used in the metadata area, and a storage policy with high reliability, such as a copy policy, may also be used, and the copy policy has a smaller influence on the access performance, so that a better access performance may also be obtained.
In the sub-step S1502, if the data type is a non-metadata type, the to-be-accessed region is determined to be a data region, and the data region is managed according to the access characteristics of the non-metadata type.
In the present embodiment, the metadata area and the data area are actual storage areas in which metadata and data are stored, respectively. The data area can adopt a storage medium with slightly lower access performance, such as an HDD disk, for the access characteristic, because the data volume of the data to be accessed of the non-metadata type is much larger than that of the data to be accessed of the metadata type, in order to achieve full utilization of the storage space, the data area can also adopt a storage strategy of erasure codes, so as to obtain higher space utilization rate under the condition that the influence on the access performance is controllable.
It should be noted that, in order to meet the requirements of high performance and low latency of metadata, as a specific implementation, a priority higher than data may be set for the metadata, and when an access request of the metadata and data is concurrently issued, the metadata is preferentially in the access request of the metadata, as another specific implementation, a preset proportion of resources, for example, 10% of resources, may also be reserved for the metadata, so as to ensure that when the resources are insufficient, the metadata type operation is not blocked due to resource shortage, which affects the access efficiency of the metadata, thereby affecting the overall efficiency of the distributed storage system.
It should be further noted that, in order to further enhance the reliability of the metadata, a background thread may be used to periodically migrate the metadata in the metadata area to a preset area in the data area, so that on one hand, high-performance access of the metadata in the metadata area is achieved, and on the other hand, multiple backups of the metadata in the metadata area and the preset area in the data area are achieved.
And a substep S1503, accessing the data to be accessed in the area to be accessed according to the access address.
In this embodiment, when the data to be accessed is the data to be read, the access address is the address to be read, the data to be read is read from the area to be accessed, when the data to be accessed is the data to be written, the access address is the address to be written, and the data to be written is written into the area to be accessed.
In this embodiment, as a specific implementation manner, the area to be accessed is pre-divided into a plurality of files, each file corresponds to a preset address range, and a specific manner for accessing the data to be accessed in the area to be accessed may be as follows:
firstly, determining a file with an access address within a preset address range as a target file.
Second, the data to be accessed is accessed from the target file.
According to the method provided by the embodiment of the invention, the metadata area and the non-metadata area are respectively managed according to the access characteristics of the metadata type and the access characteristics of the non-metadata type, so that the metadata area and the non-metadata area are more consistent with the respective access characteristics, and the respective best access performance is achieved.
In this embodiment, in order to achieve good compatibility with an existing distributed storage system, a user is allowed not to specify a corresponding target file system view for a target block device, and at this time, metadata and application data are processed uniformly according to a processing manner of the existing distributed storage system, so that the present invention further provides an implementation manner compatible with the existing distributed storage system on the basis of fig. 5, please refer to fig. 9, where fig. 9 is a flowchart of another data access method provided by an embodiment of the present invention, and the method further includes the following steps:
step S160, if the target block device does not have the corresponding target file system view, determining that the data to be accessed is of the non-metadata type.
In this embodiment, the target block device does not have a corresponding target file system view, and at this time, the target block device accesses according to the prior art, that is, the metadata and the data are processed uniformly, and are not treated differently according to different access policies.
To more clearly illustrate a specific implementation process of the foregoing method, with reference to fig. 3, an example applied to a specific scenario is further provided in an embodiment of the present invention, in the scenario, a distributed storage system includes 3 storage nodes, where each storage node is according to 5: the method comprises the steps that 1000 two types of disks including an SSD and an HDD are configured, SSD disks of all storage nodes form a distributed cache pool (providing storage space for a metadata area), 3 copy strategies are configured, HDD disks of all the storage nodes form a distributed data pool (providing storage space for a data area), a 2+1 erasure strategy is configured, and the cache pool and the data pool are uniformly managed by an EVFSX module of DSS service to provide local file storage service. The MDS service and the DSS service are deployed on the same storage node, and a Postgres database is adopted to store a file system view information table. The libVBD provides private distributed file access service in a dynamic library form, converts a standard block device operation protocol into a private file operation protocol, and fixes the file size to 1 GB.
Taking a file system view as an EXT series standard file as an example, a virtual block device with the size of 64GB is allocated and created from a distributed storage system, the ID of the virtual block device is 'mylun', the virtual block device is composed of 64 1GB internal files, and the file names are respectively: "mylun.data.0", "mylun.data.1", "…", "mylun.data.63". The super block and block group (i.e. unit block group) descriptor tables of the file system are distributed in each block group, and the file system view is as follows:
based on the above configuration, the process of writing data to mylun is as follows:
a) inquiring a file system view corresponding to the virtual block device mylun, and if the file system view does not exist, executing the data IO operation in the step (d);
b) calculating a write address interval (which can be obtained by a write offset address offset and a write length) in the write request, judging whether the write address interval falls into a metadata segment range of the file system view, and if not, executing the data IO operation in the step (d);
c) and judging the type of the metadata, sending a request to the DSS service, redirecting and writing the data into a cache pool, wherein the file names are 'myrun.data.0', 'myrun.data.1', '…' and 'myrun.data.n', and responding the processing result to the client. Meanwhile, the background synchronizes the current modification to the corresponding file in the data pool;
d) and judging the data type (namely the non-metadata type), sending a request to the DSS service, directly writing the data into a corresponding file in the data pool, and responding a processing result to the client.
Based on the above configuration, the process of reading out data from mylun is as follows:
a) inquiring a file system view corresponding to the virtual block device mylun, and if the file system view does not exist, executing the data IO operation in the step (d);
b) calculating a write address interval (which can be obtained by a write offset address offset and a write length) in the write request, judging whether the write address interval falls into a metadata segment range of the file system view, and if not, executing the data IO operation in the step (d);
c) judging the type of the metadata, sending a request to the DSS, reading data from the buffer pool, and responding a processing result to the client;
d) and judging to be the data type (namely the non-metadata type), sending a request to the DSS service, reading data from the data pool, and responding to the processing result to the client.
In order to perform the corresponding steps in the above-described embodiments and various possible implementations, an implementation of the data access apparatus 100 is given below. Referring to fig. 10, fig. 10 is a block diagram illustrating a data access apparatus 100 according to an embodiment of the present invention. It should be noted that the basic principle and the resulting technical effect of the data access apparatus 100 provided in the present embodiment are the same as those of the above embodiments, and for the sake of brief description, no reference is made to this embodiment portion.
The data access device 100 includes a receiving module 110, a determining module 120, an accessing module 130, and a formatting module 140.
The receiving module 110 is configured to receive a data access request sent by a client, where the data access request carries a target block device and an access address to be accessed by data to be accessed, and the target block device is one of at least one block device.
As a specific embodiment, at least one block device has a file system view corresponding thereto, and the receiving module 110 is further configured to: and receiving a block device formatting command sent by the client, wherein the block device formatting command comprises a block device to be formatted specified from at least one block device.
The determining module 120 is configured to determine a data type of data to be accessed according to the target file system view and the access address if the target block device has the corresponding target file system view, where the target file system view is used to represent a spatial layout manner of the target block device, and the data type includes a metadata type and a non-metadata type.
As a specific embodiment, the determining module 120 is specifically configured to: acquiring a metadata address field of a target file system view; if the access address is in the metadata address field, determining that the data to be accessed is of the metadata type; and if the access address is outside the metadata address field, determining that the data to be accessed is of a non-metadata type.
As a specific embodiment, the determining module 120 is further configured to: and if the target block device does not have a corresponding target file system view, determining that the data to be accessed is of a non-metadata type.
And the access module 130 is configured to access the data to be accessed according to the data type and the access address, and respond to the client.
As a specific embodiment, the storage node includes a metadata area and a data area, and the access module 130 is specifically configured to: if the data type is the metadata type, determining that the area to be accessed is the metadata area, and managing the metadata area according to the access characteristics of the metadata type; if the data type is a non-metadata type, determining that the area to be accessed is a data area, and managing the data area according to the access characteristics of the non-metadata type; and accessing the data to be accessed in the area to be accessed according to the access address.
As a specific implementation manner, the to-be-accessed area is pre-divided into a plurality of files, each file corresponds to a preset address range, and the accessing module 130 is specifically configured to, when accessing the to-be-accessed data in the to-be-accessed area according to the access address: determining a file with an access address within a preset address range as a target file; and accessing the data to be accessed from the target file.
A formatting module 140 for: obtaining layout parameters of a file system view corresponding to block equipment to be formatted; and formatting the space of the block device to be formatted according to the layout parameters.
As an embodiment, the layout parameters include a block size, an average file size, and a management node size, and the formatting module 140 is specifically configured to: partitioning the space of the formatting equipment according to the block size to obtain a plurality of cell blocks; grouping a plurality of cell blocks to obtain a plurality of block groups; determining a metadata address field of each block group according to the block size, the average file size and the size of the management node; and taking the metadata address fields of all the block groups as the metadata address fields of the file system views corresponding to the block devices to be formatted.
Embodiments of the present invention provide a computer-readable storage medium, on which a computer program is stored, and the computer program, when executed by a processor, implements the data access method as described above.
In summary, embodiments of the present invention provide a data access method, an apparatus, a storage node, and a readable storage medium, which are applied to a storage node of a distributed storage system, where the storage node is in communication connection with a client, and the distributed storage system includes at least one block device, where the method includes: receiving a data access request sent by a client, wherein the data access request carries a target block device and an access address to be accessed by data to be accessed, and the target block device is one of at least one block device; if the target block device has a corresponding target file system view, determining a data type of data to be accessed according to the target file system view and the access address, wherein the target file system view is used for representing a spatial layout mode of the target block device, and the data type comprises a metadata type and a non-metadata type; and accessing the data to be accessed according to the data type and the access address, and responding to the client. Compared with the prior art, the embodiment of the invention introduces the file system view representing the spatial layout mode of the block device, and identifies whether the data to be accessed is the metadata type or the non-metadata type through the perceived spatial layout mode and the access address of the block device, so that the data to be accessed can be accessed by adopting different access strategies according to different types of data to be accessed, and the overall access performance of the distributed storage system is improved.
The above description is only for the specific embodiment of the present invention, but the scope of the present invention is not limited thereto, and any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope of the present invention are included in the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the appended claims.
Claims (10)
1. A data access method applied to a storage node of a distributed storage system, the storage node being communicatively connected to a client, the distributed storage system including at least one block device, the method comprising:
receiving a data access request sent by the client, wherein the data access request carries a target block device to be accessed by data to be accessed and an access address, and the target block device is one of the at least one block device;
if the target block device has a corresponding target file system view, determining a data type of the data to be accessed according to the target file system view and the access address, wherein the target file system view is used for representing a spatial layout mode of the target block device, and the data type comprises a metadata type and a non-metadata type;
and accessing the data to be accessed according to the data type and the access address, and responding to the client.
2. The data access method of claim 1, wherein the step of determining the data type of the data to be accessed according to the target file system view and the access address comprises:
acquiring a metadata address field of the target file system view;
if the access address is in the metadata address field, determining that the data to be accessed is of a metadata type;
and if the access address is outside the metadata address field, determining that the data to be accessed is of a non-metadata type.
3. The data access method of claim 1, wherein the method further comprises:
and if the target block device does not have a corresponding target file system view, determining that the data to be accessed is of a non-metadata type.
4. The data access method of claim 1, wherein the storage node includes a metadata area and a data area, and the step of accessing the data to be accessed according to the data type and the access address includes:
if the data type is a metadata type, determining that the area to be accessed is the metadata area, wherein the metadata area is managed according to the access characteristics of the metadata type;
if the data type is a non-metadata type, determining that the area to be accessed is the data area, wherein the data area is managed according to the access characteristics of the non-metadata type;
and accessing the data to be accessed in the area to be accessed according to the access address.
5. The data access method according to claim 4, wherein the area to be accessed is pre-divided into a plurality of files, each file corresponds to a preset address range, and the step of accessing the data to be accessed in the area to be accessed according to the access address comprises:
determining the file with the access address in the preset address range as a target file;
and accessing the data to be accessed from the target file.
6. The data access method of claim 1, wherein the at least one block device has a file system view corresponding thereto, each of the file system views including layout parameters, the method further comprising:
receiving a block device formatting command sent by the client, wherein the block device formatting command comprises a block device to be formatted, which is specified from the at least one block device;
obtaining layout parameters of a file system view corresponding to the block device to be formatted;
and formatting the space of the block device to be formatted according to the layout parameters.
7. The data access method of claim 6, wherein the layout parameters include a block size, an average file size, and a management node size, and the step of formatting the space of the block device to be formatted according to the layout parameters includes:
partitioning the space of the block device to be formatted according to the block size to obtain a plurality of cell blocks;
grouping a plurality of cell blocks to obtain a plurality of block groups;
determining a metadata address field of each block group according to the block size, the average file size and the size of the management node;
and taking the metadata address fields of all the block groups as the metadata address fields of the file system views corresponding to the block devices to be formatted.
8. A data access apparatus, applied to a storage node of a distributed storage system, the storage node being communicatively connected to a client, the distributed storage system including at least one block device, the apparatus comprising:
a receiving module, configured to receive a data access request sent by the client, where the data access request carries a target block device and an access address to be accessed by data to be accessed, where the target block device is one of the at least one block device;
a determining module, configured to determine a data type of the data to be accessed according to the target file system view and the access address if the target block device has a corresponding target file system view, where the target file system view is used to represent a spatial layout manner of the target block device, and the data type includes a metadata type and a non-metadata type;
and the access module is used for accessing the data to be accessed according to the data type and the access address and responding to the client.
9. A storage node comprising a memory and a processor, wherein the memory stores a computer program, the storage node is in communication with a client, and the processor implements the data access method of any one of claims 1-7 when executing the computer program.
10. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the data access method according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111221639.9A CN113946291A (en) | 2021-10-20 | 2021-10-20 | Data access method, device, storage node and readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111221639.9A CN113946291A (en) | 2021-10-20 | 2021-10-20 | Data access method, device, storage node and readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113946291A true CN113946291A (en) | 2022-01-18 |
Family
ID=79331796
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111221639.9A Pending CN113946291A (en) | 2021-10-20 | 2021-10-20 | Data access method, device, storage node and readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113946291A (en) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114826956A (en) * | 2022-03-30 | 2022-07-29 | 杭州迪普科技股份有限公司 | DPI policy library file automatic generation method and device for DPI test equipment |
| CN114936188A (en) * | 2022-05-30 | 2022-08-23 | 重庆紫光华山智安科技有限公司 | Data processing method and device, electronic equipment and storage medium |
| CN115599704A (en) * | 2022-11-30 | 2023-01-13 | 湖南国科亿存信息科技有限公司（Cn） | File system metadata separate storage method and device and storage medium |
| CN117591038A (en) * | 2024-01-18 | 2024-02-23 | 济南浪潮数据技术有限公司 | Data access method, device, distributed storage system, equipment and medium |
| CN117591038B (en) * | 2024-01-18 | 2024-06-11 | 济南浪潮数据技术有限公司 | Data access method, device, distributed storage system, equipment and medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101079902A (en) * | 2007-06-29 | 2007-11-28 | 清华大学 | A great magnitude of data hierarchical storage method |
| CN102158546A (en) * | 2011-02-28 | 2011-08-17 | 中国科学院计算技术研究所 | Cluster file system and file service method thereof |
| CN102164161A (en) * | 2011-01-10 | 2011-08-24 | 清华大学 | Method and device for performing file layout extraction on parallel file system |
| CN109947363A (en) * | 2018-12-11 | 2019-06-28 | 深圳供电局有限公司 | A kind of data cache method of distributed memory system |
-
2021
- 2021-10-20 CN CN202111221639.9A patent/CN113946291A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101079902A (en) * | 2007-06-29 | 2007-11-28 | 清华大学 | A great magnitude of data hierarchical storage method |
| CN102164161A (en) * | 2011-01-10 | 2011-08-24 | 清华大学 | Method and device for performing file layout extraction on parallel file system |
| CN102158546A (en) * | 2011-02-28 | 2011-08-17 | 中国科学院计算技术研究所 | Cluster file system and file service method thereof |
| CN109947363A (en) * | 2018-12-11 | 2019-06-28 | 深圳供电局有限公司 | A kind of data cache method of distributed memory system |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114826956A (en) * | 2022-03-30 | 2022-07-29 | 杭州迪普科技股份有限公司 | DPI policy library file automatic generation method and device for DPI test equipment |
| CN114826956B (en) * | 2022-03-30 | 2023-05-26 | 杭州迪普科技股份有限公司 | Automatic DPI policy library file generation method and device for DPI test equipment |
| CN114936188A (en) * | 2022-05-30 | 2022-08-23 | 重庆紫光华山智安科技有限公司 | Data processing method and device, electronic equipment and storage medium |
| CN115599704A (en) * | 2022-11-30 | 2023-01-13 | 湖南国科亿存信息科技有限公司（Cn） | File system metadata separate storage method and device and storage medium |
| CN115599704B (en) * | 2022-11-30 | 2023-03-17 | 湖南国科亿存信息科技有限公司 | File system metadata separate storage method and device and storage medium |
| CN117591038A (en) * | 2024-01-18 | 2024-02-23 | 济南浪潮数据技术有限公司 | Data access method, device, distributed storage system, equipment and medium |
| CN117591038B (en) * | 2024-01-18 | 2024-06-11 | 济南浪潮数据技术有限公司 | Data access method, device, distributed storage system, equipment and medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11068455B2 (en) | Mapper tree with super leaf nodes | |
| KR101930117B1 (en) | Volatile memory representation of nonvolatile storage device set | |
| US9507800B2 (en) | Data management in distributed file systems | |
| CN113946291A (en) | Data access method, device, storage node and readable storage medium | |
| US7676628B1 (en) | Methods, systems, and computer program products for providing access to shared storage by computing grids and clusters with large numbers of nodes | |
| US9400792B1 (en) | File system inline fine grained tiering | |
| US9355121B1 (en) | Segregating data and metadata in a file system | |
| US20180181339A1 (en) | Asynchronous semi-inline deduplication | |
| US20160062694A1 (en) | Object store architecture for distributed data processing system | |
| US11188246B2 (en) | Composite aggregate architecture | |
| US7624230B2 (en) | Information processing apparatus, information processing method and storage system using cache to reduce dynamic switching of mapping between logical units and logical devices | |
| US20160364407A1 (en) | Method and Device for Responding to Request, and Distributed File System | |
| CN113722275B (en) | Object storage space management method, device, server and storage medium | |
| US9940331B1 (en) | Proactive scavenging of file system snaps | |
| JP2020511714A (en) | Selective storage of data using streams in allocated areas | |
| US9307024B2 (en) | Efficient storage of small random changes to data on disk | |
| US8443369B1 (en) | Method and system for dynamically selecting a best resource from each resource collection based on resources dependencies, prior selections and statistics to implement an allocation policy | |
| CN111399761B (en) | Storage resource allocation method, device and equipment, and storage medium | |
| CN106709014B (en) | File system conversion method and device | |
| US10592469B1 (en) | Converting files between thinly and thickly provisioned states | |
| CN111522514B (en) | Cluster file system, data processing method, computer equipment and storage medium | |
| US11513702B2 (en) | Placement of metadata on data storage drives in a first storage enclosure of a data storage system | |
| US10521398B1 (en) | Tracking version families in a file system | |
| US9009204B2 (en) | Storage system | |
| US8725979B1 (en) | Efficient methods and systems for allocating storage volumes |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |