Configuration of a computational drive

Examples implementations relate to configuration of computational drives. An example computational drive includes a housing to be inserted in a drive bay of a host device, and persistent storage. The computational drive may also include a processor to respond to an insertion of the housing into the drive bay of the host device by configuring the computational drive to operate as a new node of a distributed file system, and connecting the computational drive to the distributed file system as the new node.

BACKGROUND

Some computing systems can be modified by adding modules or other devices. For example, a computer server may include slots and/or interfaces to receive storage devices.

DETAILED DESCRIPTION

Some computing systems may be implemented across multiple devices. For example, as used herein the term “distributed file system (DFS)” refers to a data storage system using multiple nodes connected via network links. Each node of the DFS may include processing resources (e.g., a central processor) and storage resources (e.g., storage drives). In some examples, setting up a DFS may require substantial configuration work by a human expert. Further, each node of the DFS may include a minimum set of hardware components that are not utilized at full capacity. Moreover, if the desired size or capacity of the DFS changes over time, additional work may be required to add more nodes to the DFS. Accordingly, setting up and maintaining a DFS may involve significant time and expense.

As used herein, the term “computational drive” refers to a storage device that includes a housing, persistent storage, a processor, an interface, and memory. For example, a computational drive may include a 2 TB solid state drive (SSD) (e.g., using flash memory), a 4-core central processor, 4 GB of random-access memory (RAM), and a Non-Volatile Memory Express (NVMe) interface. In some implementations, the housing of the computational drive has a form factor adapted to be inserted in or “plugged into” a drive bay of a host device (e.g., a server, a storage host, etc.). Further, the interface may provide data and/or power connections to the computational drive when plugged into the drive bay.

In accordance with some implementations of the present disclosure, plugging a computational drive into a drive slot of a host server may cause an initialization or “boot up” of the computational drive (e.g., by executing an operating system stored on the computational drive). The computational drive may then access file system configuration information (e.g., from a filesystem agent at a predefined location in the host), and may use this information to configure itself into a new node of a distributed file system. The configuration of the new node, as well as file system access to/from the new node, may be performed automatically without involving a processor (e.g., a central processing unit) or an operating system of the host server, and without requiring direct by a human user. Further, because a new node can be added by plugging a computational drive into an unused drive bay of an existing host server, the distributed file system can be set up or expanded without requiring the purchase and set up of a new host device for the new node. Accordingly, some implementations may reduce the cost and complexity of setting up or expanding the distributed file system. Furthermore, some implementations may include multiple computational drives to communicate directly with each via an internal bus (e.g., a Peripheral Component Interconnect express (PCIe) bus), and may thereby provide improved performance of the distributed file system.

As used herein, a “drive” can include a storage device or an array of storage devices. A drive may also include storage controller(s) that manage(s) access of the storage device(s). A “data unit” can refer to any portion of data that can be separately identified in the storage system. In some cases, a data unit can refer to a chunk, a collection of chunks, or any other portion of data. In some examples, a storage system may store data units in persistent storage. Persistent storage can be implemented using one or more of persistent (e.g., nonvolatile) storage device(s), such as disk-based storage device(s) (e.g., hard disk drive(s) (HDDs)), solid state device(s) (SSDs) such as flash storage device(s), or the like, or a combination thereof.

A “controller” can refer to a hardware processing circuit, which can include any or some combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, a digital signal processor, or another hardware processing circuit. Alternatively, a “controller” can refer to a combination of a hardware processing circuit and machine-readable instructions (software and/or firmware) executable on the hardware processing circuit.

1. Example System

FIG.1shows an example of a system100, in accordance with some implementations. As shown, the system100may include a host device110coupled via a network to any number of filesystem nodes170. The filesystem nodes170may be nodes included in a distributed file system (DFS). For example, each filesystem node170may include processing and storage resources (not shown). Further, the filesystem nodes170may be interconnected via network links.

As shown, the host device110may include a host processor115, memory120, a filesystem agent130, a baseboard management controller (BMC)135, an internal bus112, a network interface card (MC)160, and any number of drive bays140A-140N (also referred to herein as “drive bays140”). The host processor115can include a microprocessor, a microcontroller, a processor module or subsystem, a programmable integrated circuit, a programmable gate array, multiple processors, a microprocessor including multiple processing cores, or another control or computing device. The memory120can be any type of computer memory (e.g., dynamic random access memory (DRAM), static random-access memory (SRAM), etc.). In some examples, the memory120may include a host operating system (OS)125of the host device110.

The internal bus112may be a communication system to transfer data between components of the host device110(e.g., a Peripheral Component Interconnect (PCI) bus, a Peripheral Component Interconnect express (PCIe) bus, and so forth). In some implementations, the NIC160may be an intelligent interface device that includes a processor (not shown inFIG.1). For example, the processor of the NIC160may provide processing (e.g., decryption, decompression, etc.) of packets received via a network connection.

In some implementations, the BMC135may be a specialized microcontroller embedded on an expansion card or on a motherboard of the host device110. For example, the BMC135may support the Intelligent Platform Management Interface (IPMI) architecture, which defines a set of common interfaces to computer hardware and firmware that system administrators can use to monitor health and manage a computing device. Further, the BMC135may provide remote management access to the host device110, and may provide such remote management access over an out-of-band communication channel, which isolates management communication from communication of the host OS125. In some implementations, the BMC135may enable lights-out management of the host device110, which provides remote management access (e.g., system console access) to the host device110regardless of whether the host device110is powered on, whether a primary network subsystem hardware is functioning, or whether the host OS125of the host device110is operating.

In some implementations, the filesystem agent130may be a software agent that is dedicated for providing configuration information for new nodes of a particular distributed file system (e.g., an implementation of the HPE Ezmeral Data Fabric, produced by Hewlett Packard Enterprise). For example, the filesystem agent130may be a software program that runs without continuous direct supervision from the host OS125of the host device110. The filesystem agent130may be accessed by a computational drive150at a known location (e.g., a predefined network address and port, a loopback network address, and so forth). Upon receiving a request from a computational drive150, the filesystem agent130may respond by sending configuration information that allows the computational drive150to configure itself as a new node of the distributed file system. For example, such configuration information may include a unique identifier for the new node, access credentials and/or protocols for the distributed file system, a network address and/or identifier of a master node of the distributed file system, network addresses and ports of other nodes, and so forth.

Note that, althoughFIG.1illustrates one possible implementation of the filesystem agent130, other implementations are possible. For example, the filesystem agent130may be executed by the host processor115. In another example, the filesystem agent130may be included in or otherwise provided by the NIC160(e.g., executed by a processor of the MC160). In still another example, the filesystem agent130may be included in or otherwise provided by the BMC135(e.g., executed by a processor of the BMC135). In yet another example, the filesystem agent130may be included in or otherwise provided by a component or service that is external to the host device110.

As shown inFIG.1, the drive bays140may be any feature of the host device110that is configured to receive or otherwise be connected to computational drives150A-150N (also referred to herein as “computational drives150”) and/or non-computational drives (e.g., a storage drive without an on-board processor for executing instructions). For example, the drive bays140may include a hard disk drive bay, an expansion card slot, a memory module slot (e.g., a dual in-line memory module (DIMM) slot), and so forth. In some implementations, plugging a computational drive150into a drive bay140may cause the computational drive150to boot up and configure itself to act as a new node of a distributed file system that includes the filesystem nodes170. Some example operations of a computational drive150are described below with reference toFIGS.2A-2C.

Note that, whileFIG.1show an example system100, implementations are not limited in this regard. For example, it is contemplated that the system100and/or the host device110may include additional devices and/or components, fewer components, different components, different arrangements, and so forth. In another example, it is contemplated that the functionality of the computational drive150described above may be included in any another engine or software of the computational drive150. Other combinations and/or variations are also possible.

2. Example Implementation of a Computational Drive

Referring toFIGS.2A-2C, shown are example operations of a computational drive150. The computational drive150may include a media controller205, a processor210, memory220, storage230, and a connector240.

The processor210can include a microprocessor, a microcontroller, a processor module or subsystem, a programmable integrated circuit, a programmable gate array, multiple processors, a microprocessor including multiple processing cores, or another control or computing device. The memory220can be any type of computer memory (e.g., DRAM, SRAM, etc.). The connector240may provide a physical connection, a data transfer connection, and/or an electrical power connection between the computational drive150and the drive bay140. The media controller205may be an electronic component to control the transfer of data from the storage230to an external device via a communication link (e.g., via the connector240). The storage230can include non-transitory persistent storage media such as a hard disk drive (HDD), solid state drives (SSDs), optical disks, and so forth, or a combination thereof. As shown, the storage230may include a stored operating system (OS)235). In some implementations, the computational drive150may use a NVMe interface.

Referring now toFIG.2A, when the computational drive150is initially plugged into a drive bay140, the computational drive150may receive electrical power250via the connector240. For example, the connector240may be a PCIe connector that provides electrical power and data connections when coupled to the drive bay140. Further, receiving the electrical power250may cause the computational drive150to perform a booting process. For example, receiving the electrical power250may cause the processor210to read and execute the stored OS235from the storage230. In some examples, the stored OS235may be a specialized OS for execution on the computational drive150.

Referring now toFIG.2B, after completing the booting process, the computational drive150may send a request260to the filesystem agent130(e.g., at a predefined network address and port of a host device) associated with a particular distributed file system, and in response may receive configuration information265from the filesystem agent130. The computational drive150may use the received configuration information265to configure itself as a new node of the distributed file system. In some implementations, configuring the new node using the received configuration information265may be performed without involving a host processor or OS. For example, after receiving the configuration information265from the filesystem agent130, the configuration of the new node may not use a datapath of the host processor115or the host OS125(shown inFIG.1). Further, the configuration of the new node may be performed automatically (e.g., without requiring configuration work by a human user). Accordingly, some implementations may reduce the cost and/or complexity of setting up the distributed file system in comparison to conventional techniques.

Referring now toFIG.2C, upon configuring itself, the computational drive150may be connected to the distributed file system as a new node, and may be accessed as part of the distributed file system. For example, the computational drive150may directly communicate270with the MC160, and may thereby connect275with other nodes170of the distributed file system. In this manner, the computational drive150can operate as a new node of the distributed file system without involving other resources of a host device (e.g., without using a datapath or bandwidth of the host processor115, the memory120, the host OS125, or the filesystem agent130shown inFIG.1). The computational drive150and the other nodes170may communicate directly with each other over the path270,275through the NIC160(e.g., a smart network card). Further, the MC160may keep the path270,275to be separate and isolated from network traffic of the host device110(e.g., packets to/from the host OS125). In some examples, the new node (i.e., the configured computational drive150) may appear to other nodes or users as an individual server providing a storage service, and may only be accessed via the distributed file system.

In some implementations, a single host device may include multiple nodes of a distributed file system. For example, referring again toFIG.1, the computational drives150A and150N may be configured as separate nodes of a distributed file system. In this example, the computational drives150A and150N may communicate directly with each other as file system nodes via the internal bus112(e.g., a PCIe bus).

3. Example Process

Referring now toFIG.3, shown is an example process300, in accordance with some implementations. In some examples, the process300may be performed using the host device110and/or the computational drive150(shown inFIGS.1-2B). The process300may be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions executable by a processor(s)). The machine-readable instructions may be stored in a non-transitory computer readable medium, such as an optical, semiconductor, or magnetic storage device. The machine-readable instructions may be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, and so forth. For the sake of illustration, details of the process300may be described below with reference toFIGS.1-2B, which show examples in accordance with some implementations. However, other implementations are also possible.

Block310may include inserting a computational drive into a drive bay of a host device. Block320may include booting up an operating system of the inserted computational drive. For example, referring toFIGS.1-2A, the computational drive150is plugged into (or is otherwise connected to) a drive bay140of the host device110, and may then receive electrical power250via the connector240. The processor210of the computational drive150then reads and executes the stored OS235from the storage230included in the computational drive150.

Block330may include sending a request to a filesystem agent associated with a distributed file system. Block340may include receiving configuration data from the filesystem agent. For example, referring toFIGS.1-2B, the computational drive150sends the request260to the filesystem agent130(e.g., a predefined network address and port of the host device110), and in response receives the configuration information265from the filesystem agent130. The received configuration information265may include a unique node identifier for the computational drive150, access credentials of a distributed file system, a network address of a master node of the distributed file system, and so forth. In various implementations, the filesystem agent130may be executed by the host processor115, may be executed by a processor of the NIC160, may be executed by a processor of the BMC135, and so forth.

Block350may include configuring the computational drive based on the received configuration data. Block360may include connecting the computational drive as a new node in the distributed file system. For example, referring toFIGS.1-2B, the computational drive150uses the received configuration information265to configure itself as a new node of the distributed file system. After this configuration is completed, the computational drive150is connected to the distributed file system as a new node. The new node can then be accessed as part of the distributed file system (e.g., for data read operations, for data write operations, etc.) via a node datapath. In some examples, the node datapath includes a network interface of the host device (e.g., MC160shown inFIG.1), but does not include a processor or memory of the host device (e.g., host processor115or memory120shown inFIG.1). After block360, the process300may be completed. In some implementations, blocks330,340,350, and360may be performed by the stored OS235executing on the processor210of the computational drive150.

4. Example Process

Referring now toFIG.4, shown is an example process400, in accordance with some implementations. In some examples, the process400may be performed using the host device110and/or the computational drive150(shown inFIGS.1-2B). The process400may be implemented in hardware or a combination of hardware and programming (e.g., machine-readable instructions executable by a processor(s)). The machine-readable instructions may be stored in a non-transitory computer readable medium, such as an optical, semiconductor, or magnetic storage device. The machine-readable instructions may be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, and so forth. For the sake of illustration, details of the process400may be described below with reference toFIGS.1-2B, which show examples in accordance with some implementations. However, other implementations are also possible.

Block410may include powering up a computational drive upon insertion in a drive bay of a host device, the computational drive comprising a drive processor. For example, referring toFIGS.1-2A, the computational drive150is plugged into the drive bay140, and then receives electrical power250via the connector240. In some examples, the processor210of the computational drive150may read and execute the stored OS235from the storage230included in the computational drive150.

Block420may include configuring, by the drive processor, the computational drive to operate as a new node of a distributed file system. For example, referring toFIGS.1-2B, the computational drive150sends the request260to the filesystem agent130(e.g., a predefined network address and port of the host device110), and in response receives the configuration information265from the filesystem agent130. The computational drive150uses the received configuration information265to configure itself as a new node of the distributed file system.

Block430may include connecting, by the drive processor, the computational drive to the distributed file system as the new node. For example, referring toFIGS.1-2B, the configured computational drive150may send a request to a master node to connect the distributed file system as a new node. Once connected, the new node can be accessed as part of the distributed file system (e.g., for data read operations, data write operations, and so forth). After block430, the process400may be completed.

FIG.5shows a machine-readable medium500storing instructions510-520, in accordance with some implementations. The instructions510-520can be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, and so forth. The machine-readable medium500may be a non-transitory storage medium, such as an optical, semiconductor, or magnetic storage medium. In some implementations, the instructions510-520may be performed by an operating system stored on a computational drive (e.g., by the stored OS235executing on the processor210of the computational drive150).

Instruction510may be executed to, in response to an insertion of a computational drive into a drive bay of a host device, configure the computational drive to operate as a new node of a distributed file system. Instruction520may be executed to connect the computational drive to the distributed file system as the new node. For example, referring toFIGS.1-2B, upon being plugged into the drive bay140, the computational drive150may receive electrical power250via the connector240, and may read and execute the stored OS235from the storage230. The computational drive150send the request260to the filesystem agent130, and in response may receive the configuration information265. The computational drive150may configure itself to operate a new node of a distributed file system based on the received configuration information265(e.g., via execution of instruction510). The configured computational drive150may then connect to and be accessed as a new node of the distributed file system (e.g., via execution of instruction520).

6. Example Computational Drive

FIG.6shows a schematic diagram of an example computational drive600. In some examples, the computational drive600may correspond generally to a computational drive150(shown inFIG.1). As shown, the computational drive600may include hardware processor602and machine-readable storage605including instructions610-620. The machine-readable storage605may be a non-transitory medium. The instructions610-620may be executed by the hardware processor602, or by a processing engine included in hardware processor602. In some implementations, the computational drive600may have a housing601that is configured to be plugged into (or otherwise connected to) a drive bay of a host device (e.g., drive bay140of host device110, as shown inFIG.1). In some implementations, the instructions610-620may be performed by an operating system stored on a computational drive (e.g., by the stored OS235executing on the processor210of the computational drive150).

Instruction610may be executed to, in response to an insertion of the housing into a drive bay of a host device, configure the computational drive to operate as a new node of a distributed file system. Instruction620may be executed to connect the computational drive to the distributed file system as the new node. For example, referring toFIGS.1-2B, upon being plugged into the drive bay140, the computational drive150may receive electrical power250via the connector240, and may read and execute the stored OS235from the storage230. The computational drive150send the request260to the filesystem agent130, and in response may receive the configuration information265. The computational drive150may configure itself to operate a new node of a distributed file system based on the received configuration information265. The configured computational drive150may then connect to and be accessed as a new node of the distributed file system.

In accordance with implementations described herein, plugging a computational drive into a drive slot of a host server may cause the computational drive to boot up and configure itself into a new node of a distributed file system. The configuration of the new node, as well as the file system access to/from the new node, may be performed automatically without involving a central processing unit or operating system of the host server, and without requiring direct intervention by a human user. Further, because a new node can be added by plugging a computational drive into an unused drive bay of an existing host server, the distributed file system can be set up or expanded without requiring the purchase and set up of a new host device for the new node. Accordingly, some implementations may reduce the cost and complexity of setting up or expanding the distributed file system.

Note that, whileFIGS.1-6show various examples, implementations are not limited in this regard. For example, referring toFIG.1, it is contemplated that the system100and/or the host device110may include additional devices and/or components, fewer components, different components, different arrangements, and so forth. In another example, it is contemplated that the functionality of the computational drive150described above may be included in any another engine or software of the computational drive150. Other combinations and/or variations are also possible.

Data and instructions are stored in respective storage devices, which are implemented as one or multiple computer-readable or machine-readable storage media. The storage media include different forms of non-transitory memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories; magnetic disks such as fixed, floppy and removable disks; other magnetic media including tape; optical media such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices.

Note that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture can refer to any manufactured single component or multiple components. The storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution.