Method and architecture for accelerating compute storage in full flash array network

Abstract

A method and architecture for accelerating compute storage in a full flash array network is provided. A method for accelerating compute storage in a full flash array, the full flash array comprising a plurality of solid state drives (SSDs) connected in a ring topology. The method includes receiving, by a controller of a first SSD, a request for reading or writing data from a dynamic random access memory (DRAM) associated with the first SSD; creating a packet comprising an identifier of the first SSD in the ring topology, an identifier of the packet, and a read / write flag identifying the request; and sending the packet to a next SSD in the ring topology. When the request is a read request and a read data address is not located in the DRAM, the read / write flag indicates a read request, and when the request is a write request and the DRAM is full, the read / write flag indicates a write request, and the packet includes data to be written.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to a storage system stack in a computer system in which DRAM is shared among multiple SSDs to accelerate in-storage computing. Background Art

[0002] The storage system stack includes devices, protocols, and layers. In performance-oriented mass storage systems, flash-based solid-state drive (SSD) devices are grouped to form an all-flash array (AFA), accessed and mapped through a single host interface protocol, organized as file system sectors, and balanced and managed with a dedicated software layer.

[0003] SSD devices form an integrated storage system with processors, embedded memory, and random access memory (RAM) resources that are optimized for independent operation with a single host. When several SSDs are collected to be used as a single storage entity, there may be a situation where one SSD has a specific component that acts as an obstacle while other devices have the same resources that are not fully utilized. Such a scenario reduces overall system performance. Even if the necessary hardware is available, the necessary hardware cannot be used due to lack of inter-SSD communication.

[0004] A flash memory-based storage system includes multiple SSDs, where each SSD is independently activated. The SSD internal components are uniquely used for a given workload of the SSD internal components provided by the host protocol. However, when some SSDs are grouped into a flash memory array, it is challenging to balance the storage task distribution management due to the internal processing.

[0005] Dynamic RAM (DRAM) is an essential component in SSDs for improving their read / write performance and reliability by enabling dynamic Flash Translation Layer (FTL) management and data buffering. However, in certain workload scenarios, DRAM may overflow and the data of DRAM may be migrated to NAND flash memory, resulting in severe performance degradation. Therefore, algorithms for coping with insufficient RAM space situations are desired. In addition, the ongoing cost competition has led to attempts to reduce DRAM space, thus making the situation more challenging.

[0006] Figure 1A An example of the architecture of an SSD network is shown in Figure 1AA processor 101 is shown connected to an I / O controller hub (or referred to as an I / O controller, an I / O hub, or a hub) 102, which in turn is connected to each of SSD 1 103, SSD 2 104, SSD 3 105, and SSD 4 106. Each SSD includes a controller (or referred to as an SSD controller), a DRAM connected to the controller, and a plurality of NAND flash memories connected to the controller. Although Figure 1A Four SSDs are shown connected to hub 102, but this is for ease of illustration. Summary of the invention

[0007] The disclosed embodiment shares DRAM between SSDs in an AFA by connecting multiple SSDs, so that when a specific SSD DRAM space is insufficient, the data of the SSD DRAM can be stored on another SSD with available RAM. The improvement is the efficient utilization of DRAM resources and the elimination of the situation where a single SSD has insufficient DRAM space and other SSDs have free DRAM. All-flash array (AFA) computing shares SSD DRAM resources. In addition, AFA can perform high-performance computing, and for better performance, DRAM resources within the SSD can be shared. The analysis results show a performance improvement of up to 2 times the AFA performance compared to conventional solutions depending on the number of SSDs, DRAM overflow probability, and performance degradation factor. As the demand for data centers and AFA products grows, more components are filled in the basic building blocks. The SSD inter-connection structure according to the embodiment effectively utilizes SSD integrated components and open research directions as resource sharing and fault tolerance. The disclosed embodiment can solve cost and performance problems through effective component utilization and ensure competitive products in the global market.

[0008] According to a disclosed embodiment, a method for accelerating computational storage in an all-flash array network is provided, the all-flash array network including a plurality of solid-state drives (SSDs) connected in a ring topology, wherein each of the plurality of SSDs includes a controller and a dynamic random access memory DRAM connected to the controller. The method includes: receiving, through a controller of a first SSD, a request for reading data or writing data from a DRAM associated with the first SSD; creating a packet including an identifier of the first SSD in the ring topology, an identifier of the packet, and a read / write flag identifying the request; and sending the packet to the next SSD in the ring topology. When the request is a read request and the read data address is not located in the DRAM, the read / write flag indicates a read request, and when the request is a write request and the DRAM is full, the read / write flag indicates a write request, and the packet includes data to be written.

[0009] According to a further disclosed embodiment, the method includes verifying that the read / write flag indicates a read request and the read data address is located in the DRAM, and reading data from the read data address in the DRAM.

[0010] According to a further disclosed embodiment, the method includes verifying that the read / write flag indicates a write request and the DRAM is not full, and writing data to a write address in the DRAM.

[0011] According to a further disclosed embodiment, the method includes: receiving the packet through the next SSD in the ring topology; verifying that the next SSD in the ring topology is different from the first SSD in the ring topology, the read / write flag indicates a write request and the DRAM associated with the next SSD is not full; requesting a write address of the DRAM associated with the next SSD from a controller of the next SSD; writing the data in the packet to the write address of the DRAM; updating the packet by setting the read / write flag to indicate a write confirmation; and sending the packet to the next SSD in the ring topology.

[0012] According to a further disclosed embodiment, the method includes: receiving the packet by the next SSD in the ring topology; verifying that the next SSD in the ring topology is different from the first SSD in the ring topology and that a read / write flag indicates a read request; requesting a read address of a DRAM associated with the next SSD from a controller of the next SSD based on an identifier of the first SSD in the ring topology and an identifier of the packet; updating the packet by setting the read / write flag to indicate a write confirmation and replacing the data to be written with the data read from the read address; and sending the packet to the next SSD in the ring topology.

[0013] According to a further disclosed embodiment, the method includes: receiving the packet through the next SSD in the ring topology; verifying that the next SSD in the ring topology is the first SSD in the ring topology; updating the incoming packet table / outgoing packet table of the controller of the first SSD when the read / write flag indicates a write confirmation; performing DRAM space shortage processing when the read / write flag indicates a write request and the DRAM associated with the first SSD is full; and outputting the data of the packet to the host of the all-flash array when the read / write flag indicates a read confirmation.

[0014] According to a further disclosed embodiment, the packet includes a field for an SSD identifier, a field for an identifier of the packet, a field for a read / write request / confirmation flag, and a field for data to be written to or read from a DRAM associated with the SSD.

[0015] According to a disclosed embodiment, an architecture for accelerating computational storage in an all-flash array is provided, the architecture comprising: a plurality of solid-state drives (SSDs) connected to an input / output (I / O) hub, wherein each of the plurality of SSDs comprises a controller, a DRAM connected to the controller, and a plurality of NAND flash memories connected to the controller, and a processor connected to the hub. The plurality of SSDs are connected in a ring topology, in which each controller comprises an input port and an output port, each input port of each SSD is connected to an output port of a previous SSD via a connector, and an input port of a first SSD of the plurality of SSDs is connected to an output port of a last SSD of the plurality of SSDs via a connector.

[0016] According to further disclosed embodiments, each SSD further includes a hardware accelerator connected to the DRAM, wherein the hardware accelerator accelerates tasks other than reading or writing to the DRAM of each SSD.

[0017] According to a further disclosed embodiment, the architecture includes: an artificial intelligence (AI) server. The AI ​​server is an SSD including a processor, a DRAM connected to the processor, and a plurality of NAND memories connected to the processor.

[0018] According to a further disclosed embodiment, the connector is a cable.

[0019] According to a further disclosed embodiment, the controller of each SSD includes: a DRAM manager connected to the DRAM and an output port; a packet buffer connected to the input port, the DRAM, and the output port; an inter-SSD finite state machine FSM connected to the packet buffer, the input port, and the DRAM manager, wherein the inter-SSD FSM performs packet routing and processing of received packets; a multiplexer connecting the DRAM manager and the packet buffer to the output port; a multiplexer connecting the DRAM manager and the packet buffer to the DRAM; and an additional component connecting the DRAM manager to the host and the plurality of NAND memories.

[0020] According to a further disclosed embodiment, packet routing includes: receiving, by a controller of a first SSD, a request for reading data or writing data from a DRAM associated with the first SSD; creating a packet including an identifier of the first SSD in a ring topology, an identifier of the packet, and a read / write flag identifying the request; and sending the packet to a next SSD in the ring topology. When the request is a read request and the read data address is not located in the DRAM, the read / write flag indicates a read request, and when the request is a write request and the DRAM is full, the read / write flag indicates a write request, and the packet includes data to be written.

[0021] According to a further disclosed embodiment, packet processing includes: receiving the packet by the next SSD in the ring topology; verifying that the next SSD in the ring topology is different from the first SSD in the ring topology, the read / write flag indicates a write request and the DRAM associated with the next SSD is not full; requesting a write address of the DRAM associated with the next SSD from a controller of the next SSD; writing the data in the packet to the write address of the DRAM; updating the packet by setting the read / write flag to indicate a write confirmation; and sending the packet to the next SSD in the ring topology.

[0022] According to a further disclosed embodiment, packet processing includes: receiving the packet by the next SSD in the ring topology; verifying that the next SSD in the ring topology is different from the first SSD in the ring topology and that a read / write flag indicates a read request; requesting a read address of a DRAM associated with the next SSD from a controller of the next SSD based on an identifier of the first SSD in the ring topology and an identifier of the packet; updating the packet by setting the read / write flag to indicate a read confirmation and replacing the data to be written with the data read from the read address; and sending the packet to the next SSD in the ring topology.

[0023] According to a further disclosed embodiment, the DRAM manager includes: an incoming packet table, including a field for an identifier of the SSD and a field for an identifier of the incoming packet; and an outgoing packet table, including a field for an identifier of the outgoing packet and a field for the DRAM data link.

[0024] According to another disclosed embodiment, an architecture for accelerating computational storage in an all-flash array is provided, the architecture comprising: a plurality of solid-state drives (SSDs) connected to an input / output (I / O) hub, wherein each of the plurality of SSDs comprises a controller, a DRAM connected to the controller, and a plurality of NAND memories connected to the controller; and a processor connected to the hub. The hub is configured to support incoming DRAM data and confirmation packets, and each SSD controller is configured to route DRAM read and write requests and process received packets.

[0025] According to a further disclosed embodiment, packet routing includes: receiving, by a controller of a first SSD, a request to read data or write data from a DRAM associated with the first SSD; creating a packet, the packet including an identifier of the first SSD, an identifier of the packet, and a read / write flag identifying the request; and sending the packet to a hub, wherein the hub sends the packet to a next SSD. When the request is a read request and the read data address is not located in the DRAM, the read / write flag indicates a read request, and when the request is a write request and the DRAM is full, the read / write flag indicates a write request, and the packet includes data to be written.

[0026] According to a further disclosed embodiment, packet processing includes: receiving the packet by the next SSD; verifying that the next SSD is different from the first SSD, the read / write flag indicates a write request and the DRAM associated with the next SSD is not full; requesting a write address of the DRAM associated with the next SSD from a controller of the next SSD; writing the data in the packet to the write address of the DRAM; updating the packet by setting the read / write flag to indicate a write confirmation; and sending the packet to a hub.

[0027] According to a further disclosed embodiment, packet processing includes: receiving the packet by the next SSD; verifying that the next SSD comes from the first SSD and the read / write flag indicates a read request; requesting a read address of the DRAM associated with the next SSD from the controller of the next SSD based on an identifier of the first SSD and an identifier of the packet; updating the packet by setting the read / write flag to indicate a read confirmation and replacing the data to be written with the data read from the read address; and sending the packet to the hub. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1A An example of the architecture of a current inter-SSD channel is shown.

[0029] Figure 1BShown is a new connection between SSDs according to the disclosed embodiments.

[0030] Figure 2 An SSD inter-packet structure according to an embodiment is shown.

[0031] FIG. 3A to FIG. 3B A connection is shown where DRAM allocation is managed by an I / O controller hub in accordance with a disclosed embodiment.

[0032] Figure 4 The data flow in an inter-SSD controller according to the disclosed embodiment is shown.

[0033] Figure 5 Showing the embodiment according to the disclosure Figure 4 Overview diagram of the DRAM Manager.

[0034] Figure 6 Optional inter-SSD communication through an I / O controller hub is shown in accordance with the disclosed embodiments.

[0035] Figure 7 is a graph of normalized AFA bandwidth and probability of single SSD DRAM overflow according to the disclosed embodiment.

[0036] Figure 8 is a block diagram of a system for implementing read / write request and packet processing algorithms according to a disclosed embodiment. DETAILED DESCRIPTION

[0037] The embodiments include two implementation schemes: an I / O controller independent scheme with inter-SSD connections including hardware and wiring modifications, and an alternative scheme with only software changes at the I / O hub and SSD controller.The embodiments also provide algorithms for packet network communications.

[0038] Figure 1B An SSD network according to an embodiment is shown. Figure 1B The architecture and Figure 1AThe architecture shown in FIG. 1 is different in that each SSD controller has two additional ports "IN" and "OUT", and a new connector (e.g., cable) is added between the controllers in the separated SSDs to form a ring topology. A ring topology is a network topology in which each node is connected to exactly two other nodes, thereby forming a single continuous path for signals through each node, and the network topology forms a ring network. In one example, the nodes of the ring network may be represented by SSDs. For example, each input port of each SSD is connected to the output port of the previous SSD via a connector, and the input port of the first SSD of the plurality of SSDs is connected to the output port of the last SSD of the plurality of SSDs via a connector. In the event that there is insufficient space for DRAM in a particular SSD, the data will be routed to another DRAM located on another device in an all-flash array (AFA). If no such location is found, the packet is returned to the original SSD via a ring connection and is processed as a regular structure. In some embodiments, one or more SSDs include a hardware (HW) accelerator that accelerates tasks other than reading or writing to the DRAM of each SSD, and the one or more SSDs are artificial intelligence (AI) servers that include a processor, a DRAM connected to the processor, and a plurality of NAND memories connected to the processor. Figure 1B Four SSDs are shown connected to hub 102 , but this is for ease of illustration and embodiments are not necessarily limited in this regard.

[0039] The communication is based on packet switching, where DRAM overflow causes a RAM request to be sent in the controller output port. Each SSD is assigned a unique identifier (ID) for identification (such as a serial manufacturing number). Each controller has two additional ports: IN and OUT for inter-controller communication. In the accompanying figure, SSD 1 is connected to SSD 2, SSD 2 is connected to SSD 3, SSD 3 is connected to SSD 4, and SSD 4 is connected back to SSD 1, which forms a ring topology. When a specific SSD DRAM space is needed but is unavailable, the controller sends a packet with its SSD-ID and data to the next SSD in the ring network through the IN port. If a request is issued, the receiving controller checks its DRAM availability and sends a confirmation packet with its ID. Otherwise, if the DRAM space is unavailable, the original packet is passed to the next SSD through the OUT port. If no SSD can satisfy the request, the original packet returns to the original SSD that treats the situation as a regular independent SSD. The hub may include additional resources for expanding SSD capabilities.

[0040] Described below FIG. 3A to FIG. 3BAn alternative connection is shown in which DRAM allocation is managed by the I / O controller in software. In this case, the SSD controller can request RAM space from the hub and route the data to other SSDs through the hub connection. This architecture does not require additional cabling or SSD controller ports, but only requires driver and software modifications at the I / O controller and SSD controller.

[0041] DRAM sharing capabilities can be used to enable and extend memory reduction, Flash Translation Layer (FTL) compression, garbage collection operations, write buffers, and internal accelerators. Inter-SSD connections can also share error correction decoder modules (ECC) or other controller resources (such as processors).

[0042] I. Symbols and Definitions

[0043] Symbol 1 (Number of SSDs in AFA): The number of SSDs in a single AFA platform is denoted by N. Assuming Figure 1B The AFA shown in FIG. 1 includes multiple SSDs connected to a single I / O controller hub connected to a host processor.

[0044] Symbol 2 (Probability of DRAM overflow): In the predefined SSD parameters, the probability of DRAM space demand when the DRAM space is fully utilized is denoted by p.

[0045] Symbol 3 (SSD bandwidth): The average data rate (GB / sec) of read operations and / or write operations is denoted by B, and r·B (r<1) is used for the cases with and without DRAM overflow. The degradation of SSD performance originates from the storage of DRAM data in NAND flash memory. Therefore, the expected bandwidth SSD BW (p) is:

[0046] SSD BW (p)=(1-p)B+p·r·B=B[1-p(1-r)]

[0047] For normalization purposes, SSD BW (p) is divided by a constant B to obtain the normalized bandwidth of a single SSD, and r is determined statically based on analysis.

[0048] Symbol 4 (AFA bandwidth): Performance of AFA BW (p) is defined as the product of the number of SSDs in the AFA and the bandwidth of a single SSD:

[0049] AFA BW (p) = N·SSD BW (p)

[0050] Because each SSD acts independently, its bandwidth can be added for overall system performance.

[0051] II. Communication between SSDs

[0052] A. Physical Link

[0053] In one embodiment, each controller has two additional ports "IN" and "OUT" for incoming and outgoing packets. The link width and operating frequency as well as the interaction protocol can be determined arbitrarily.

[0054] B. Package Structure

[0055] The packet size can be 20 bits or 84 bits, depending on whether the packet carries data or acknowledgment. Regardless of the type of data (such as address, sector write / read data, or metadata), the packet size can be 20 bits or 84 bits. Figure 2 The data shown in FIG. 1 includes a unique ID, a two-bit indication of a read operation or a write operation, additional data of the DRAM page size (usually 64 bytes) in the case of a write request or a read response, and the SSD-ID. Figure 2 FIG. 2 shows an SSD packet structure according to an embodiment. Figure 2 , the packet includes an SSD identifier SSD-ID that uniquely identifies each SSD in the SSD network, a unique packet identifier packet-ID that uniquely identifies the packet, a two-bit read / write instruction R / W (or referred to as a read / write flag) including an indication of a request or confirmation of additional data, and the original SSD data to be written to the DRAM in the size of a DRAM page (usually 64 bytes). In one embodiment, the SSD identifier SSD-ID is 8 bits and the unique packet identifier packet-ID is 10 bits. The transmission can be distributed over several cycles depending on the bus bandwidth. The packet size is divided by the connection bus width to determine the amount of clock cycles required for the transmission. For an SSD request to read data from a DRAM associated with another SSD, the packet R / W indication (or referred to as an R / W field) is {R, 0}, and when the read data is appended to its path to the target SSD, the packet R / W indication is {R, 1}. In the case of a write confirmation of an SSD, the packet R / W indication is {W, 0}, and for an SSD request to program data onto another SSD, the R / W field is {W, 1}.

[0056] C. Routing and Services

[0057] A method for requesting a read or write to other DRAMs on an AFA when the SSD DRAM is full according to an embodiment is described in detail in the following Algorithm 1. The allocation of packet identifiers is performed in ascending order, and outgoing packet identification is performed by an additional DRAM manager mechanism at the SSD controller, which attempts to store the sent packet identifiers in addition to conventional DRAM data management. The case of DRAM reads where the data is stored in another SSD (e.g., the read data address is not located in the DRAM associated with the current SSD) is addressed in steps (1) to (3), in which case a packet identifier (packet #) is requested from the DRAM manager, and a packet is constructed from the identifier of the current SSD in the AFA (SSD identifier), the packet identifier, and the read request instruction (R0). The case of DRAM writes where DRAM space is unavailable is shown in steps (4) to (6), in which a packet is constructed from the identifier of the current SSD in the AFA, the packet identifier, and the write request instruction (W1). In each case, the packet is then sent to the next SSD in the AFA. In one example, the packet may include an identifier of the current SSD receiving the request in the ring topology, a packet identifier, and a read / write flag identifying the request. For example, in response to the request being a read request, the read / write flag indicates a read request, and in response to the read / write flag indicating a read request and the read data address is not located in the DRAM associated with the current SSD, the packet is sent to the next SSD in the ring topology. For example, when the read / write flag indicates a read request and the read data address is located in the DRAM associated with the current SSD, data may be read from the read data address in the DRAM associated with the current SSD. For example, in response to the request being a write request, the read / write flag indicates a write request, and the packet includes data to be written, and in response to the read / write flag indicating a write request and the DRAM associated with the current SSD is full, the packet is sent to the next SSD in the ring topology. For example, when the read / write flag indicates a write request and the DRAM associated with the current SSD is not full, the data in the packet may be written to the write address in the DRAM associated with the current SSD.

[0058] Algorithm 1: Request DRAM read and / or write

[0059] Input: D-RAM data bit, ID-SSD identification

[0060] (1) Packet #←Get Packet # from DRAM Manager

[0061] (2) If (RAM read) and (the address (e.g., the read data address) is not in DRAM), then

[0062] (3) Packet←{ID, Packet#, R0}

[0063] (4) Else If (RAM write request) && (DRAM is full), Then

[0064] (5) Packet←{ID, Packet#, W1, Data}

[0065] (6)End

[0066] (7) Send the packet to the next SSD on the ring (e.g., a ring network)

[0067] A method for processing an incoming packet according to an embodiment is shown in Algorithm 2 below. In the following, the phrase "different SSD" refers to a different SSD within an SSD network, in which each SSD in the network can be identified and distinguished by its unique SSD-ID. The case of writing or reading the DRAM of a different SSD is addressed in steps (1) to (12), in which case the SSD identifier of the SSD that has received the packet is different from the SSD identifier SSD-ID (packet {ID}) of the received packet, and the SSD identifier SSD-ID of the received packet identifies the sending SSD. The case of writing to the DRAM of a different SSD is addressed in steps (1) to (6), and the case of reading the DRAM in a different SSD is addressed in steps (7) to (12). If the DRAM is full or the read packet # is not found, the packet is simply routed to the next SSD on the ring in step (13). The case when the packet has returned to the originating SSD is addressed in steps (13) to (21). The originating SSD will have the same SSD-ID as the SSD-ID in the packet. The case of write confirmation is shown in steps (14) to (16), in which case the DRAM manager is updated by updating the incoming packet table and / or the outgoing packet table. As shown in steps (17) to (18), if the packet with a write request has traveled through all ring nodes (e.g., nodes of a ring network) (full circle) and has returned to the original SSD, and the DRAM is still full, then the situation is considered as a conventional DRAM space shortage (e.g., DRAM space shortage processing is performed). As described in steps (19) to (20), in the case of read confirmation, the read data is sent back to the original SSD and the data is output to the host. In Algorithm 2, W0 represents write confirmation and R1 represents read confirmation. For example, when the read / write flag indicates a write request and the DRAM associated with the next SSD is not full, the write address of the DRAM associated with the next SSD can be requested from the controller of the next SSD (e.g., step (3)). Then, the data in the packet can be written to the write address of the DRAM associated with the next SSD (e.g., step (4)). Next, the packet may be updated by setting the read / write flag to indicate write confirmation (e.g., step (5)). For example, when the read / write flag indicates a read request and the read data address is not located in the DRAM associated with the current SSD, the controller of the next SSD may be requested for the read data address of the DRAM associated with the next SSD based on the identifier of the current SSD in the ring topology and the identifier of the packet (e.g., step (8)). Then, the packet may be updated by setting the read / write flag to indicate read confirmation and replacing the data to be written with the data read from the read data address (e.g., step (10)).

[0068] Algorithm 2: Packet Processing

[0069] Input: Received packet

[0070] (1) If package {ID}~=SSD(ID), Then

[0071] (2) If {R / W} = W1 && (DRAM is not full), then

[0072] (3) DRAM-address (e.g., write address) ← request to DRAM manager

[0073] (4) DRAM address writes the packet {data} into DRAM

[0074] (5) package←{package{ID}, package{#}, W0}

[0075] (6) End

[0076] (7) If {R / W} = R0, then

[0077] (8) DRAM-address←Request RAM with ID, packet {#}

[0078] (9) If found in DRAM, Then

[0079] (10) Packet←{packet{ID}, pack{#}, R1, read data}

[0080] (11) End

[0081] (12)End

[0082] (13) Send the packet to the next SSD on the ring

[0083] (14) Else / / Package {ID} = SSD (ID)

[0084] (15) If {R / W} = W0, then

[0085] (16) Update DRAM manager

[0086] (17) Else If {R / W} = W1 && (DRAM is full), Then

[0087] (18) It manifests as insufficient regular DRAM space

[0088] (19) Else If package {R / W}=R1, Then

[0089] (20) Output the packet {data} to the host

[0090] (21) End

[0091] (22)End

[0092] D. Optional SSD Interconnection

[0093] To reduce interconnect costs, embodiments provide optional inter-SSD communication by managing the I / O controller hub. For example, instead of sending a packet to the next SSD in the AFA, the sending SSD will send the packet to the hub, which will then send the packet to the next SSD. The hub-SSD interface is extended beyond storage protocols such as Serial Advanced Technology Attachment (SATA), Peripheral Component Interconnect Express (PCIe), Non-Volatile Memory Express (NVMe), etc., as described above in Section II.B and as described below with reference to Figure 6 The internal DRAM data transfer and acknowledgement commands are described as follows. This configuration does not require external links and is discussed in the next section.

[0094] FIG. 3A to FIG. 3B Optional inter-SSD communication through an I / O controller hub is shown according to an embodiment. FIG. 3A to FIG. 3B The SSD controller does not have Figure 1B Additional IN ports and OUT ports shown in . Figure 3A SSD 2 104 is shown requesting RAM space from I / O controller hub 102, while Figure 3B Hub 102 is shown allocating available DRAM at SSD 3 105 and routing data according to the protocol.

[0095] E. RAM expansion and other resource sharing

[0096] According to the method according to the embodiment, additional AFA resources (such as additional DRAM) can be allocated at the hub to improve overall SSD performance. The SSD can also share other resources (such as error correction decoders) using an architecture similar to the above architecture.

[0097] III. Implementation Methods

[0098] To reduce interconnect costs, the disclosed embodiments provide optional inter-SSD communication as follows.

[0099] A. SSD inter-ring connection

[0100] According to an embodiment, the modification includes:

[0101] SSD controller hardware (HW) and software (SW)

[0102] like Figure 1BAs shown in , two additional IN ports and OUT ports. As described in Algorithms 1 and 2 above, the controller requires dedicated hardware or software to send and receive packets. Figure 4 Additional hardware is depicted in Figure 4 Shows the data flow in the inter-SSD communication module. Figure 4 An exemplary SSD controller 201 is shown including multiplexers 210 and 211, a DRAM manager 212, a packet buffer 213, an inter-SSD finite state machine (FSM) 214, and additional controller components 215. Routing and processing algorithms are implemented at the inter-SSD FSM 214. The DRAM manager includes a conventional structure and a register list of incoming DRAM data from other SSDs identified by SSD-ID and packet #, and outgoing packets as a result of insufficient DRAM space identified by a conventional table index. Additional hardware also includes multiplexers 210 and 211 and a packet buffer 213 for routing. For example, the DRAM manager 212 may be connected to the DRAM 202 and the output port OUT. For example, the packet buffer 213 may be connected to the input port IN, the DRAM 202, and the output port OUT. For example, the inter-SSD FSM 214 may be connected to the packet buffer 213, the input port IN, and the DRAM manager 212, and the inter-SSD FSM 214 may perform packet routing and processing of received packets. For example, multiplexer 211 may connect DRAM manager 212 and packet buffer 213 to output port OUT. For example, multiplexer 210 may connect DRAM manager 212 and packet buffer 213 to DRAM 202. For example, additional controller component (e.g., additional component) 215 may connect DRAM manager 212 to a host and NAND flash memory. Figure 5 An overview diagram of a DRAM manager according to an embodiment is shown in FIG. Figure 5 DRAM manager 212 is shown including a conventional DRAM manager 300 and an incoming packet table 301 and an outgoing packet table 302 for detecting and recovering DRAM data. For example, incoming packet table 301 includes a field for an identifier of the SSD and a field for an identifier of the incoming packet, and outgoing packet table 302 includes a field for an identifier of the outgoing packet and a field for a DRAM data link.

[0103] Link Cable

[0104] The interconnection of the ring topology requires N cables between the N SSDs. Wireless communication can also be used to establish the link, but the current transfer rate and hardware / software complexity of such a connection are not suitable for high-speed DRAM data transfer.

[0105] B. Inter-SSD communication via management I / O controller hub

[0106] To support the optional solution according to the embodiment, only software modifications are required:

[0107] I / O Controller Hub SW

[0108] The hub driver according to an embodiment supports incoming DRAM data and / or confirmation packets in addition to its storage protocol. The required changes can be implemented in internal hub driver software. For example, the controller of each SSD can route DRAM read and write requests and process received packets. For example, the routing step may include: receiving a request for reading data or writing data from a DRAM associated with the current SSD through the controller of the current SSD; creating a packet (the packet includes an identifier of the current SSD, an identifier of the packet, and a read / write flag identifying the request); and sending the packet to the I / O hub, wherein the I / O hub sends the packet to the next SSD. For example, in response to the request being a read request, the read / write flag indicates a read request, and in response to the read / write flag indicating a read request and the read data address is not located in the DRAM associated with the current SSD, the I / O hub sends the packet to the next SSD. For example, in response to the request being a write request, the read / write flag indicating the write request, and in response to the read / write flag indicating the write request and the DRAM associated with the current SSD being full, the I / O hub sends the packet to the next SSD, and the packet includes data to be written. For example, the steps of processing the received packet may include: receiving the packet by the next SSD; verifying that the next SSD is different from the current SSD, the read / write flag indicates the write request and the DRAM associated with the next SSD is not full; requesting a controller of the next SSD for a write address of the DRAM associated with the next SSD; writing the data in the packet to the write address of the DRAM associated with the next SSD; updating the packet by setting the read / write flag to indicate a write confirmation; and sending the packet to the I / O hub. For example, the steps of processing a received packet may include: receiving the packet by a next SSD; verifying that the next SSD is different from the current SSD and that the read / write flag indicates a read request; requesting a controller of the next SSD for a read data address of a DRAM associated with the next SSD based on an identifier of the current SSD and an identifier of the packet; updating the packet by setting the read / write flag to indicate a read confirmation and replacing the data to be written with the data read from the read data address; and sending the packet to the I / O hub.

[0109] SSD Controller SW

[0110] A controller according to an embodiment transfers DRAM data to external IO along with the packet components as described above in Section II.B. Such modifications may be implemented by internal SSD processor software.

[0111] Figure 6 Optional inter-SSD communication through an I / O controller hub is shown according to an embodiment. Figure 6 SSD 2 is shown requesting DRAM space from I / O controller 102, after which hub 102 allocates the available DRAM at SSD 3 and routes the data according to the protocol. Figure 6 In the embodiment, the DRAM management software 401 at the hub and the packet transmission / reception (Tx / Rx) software 503 in the SSD controller 502 are implemented. Figure 5 and Figure 6 In addition, SSD represents both requesting SSD SSD 2 and receiving SSD SSD 3. For example, I / O controller hub 102 may support SATA and / or PCle protocol 402.

[0112] IV. Analysis

[0113] In one embodiment, the normalized regular bandwidth of a single SSD depends on the probability p of DRAM overflow:

[0114] SSD BW (p) = 1-p(1-r)

[0115] Because SSDs are independent, the conventional bandwidth of AFA is BW (p,N) is the product of the bandwidth of a single SSD and the number of SSDs in the AFA:

[0116] OFA BW (p,N)=N·[1-p(1-r)]

[0117] In the case of DRAM sharing, performance is only reduced when all SSDs have full DRAM. However, since all SSDs use each other's memory, the probability of overflow p increases. According to the analytical assumptions of the embodiment, if a particular SSD DRAM is out of space, other SSDs in the same AFA will be able to provide DRAM as long as they do not overflow in their independent workloads. In this case, each SSD with DRAM overflow needs a similar SSD that is activated due to the available DRAM space. For simplicity, the embodiment will assume an even number of SSDs (N).

[0118] For two SSDs in AFA utilizing DRAM Sharing (DS), performance only degrades when both are overflowed. Normalized performance of a single SSD DS is the total AFA performance divided by N:

[0119]

[0120] For four SSDs, up to two SSDs with overflow do not change performance. If three SSDs overflow, the performance of two SSDs degrades because there is one remaining SSD that can support DRAM sharing. If four SSDs overflow, the performance of all SSDs degrades:

[0121]

[0122] The N SSDs included in AFA are:

[0123]

[0124] therefore:

[0125]

[0126] exist Figure 7 In the figure, the analysis results for the conventional AFA architecture are plotted for p = 10 -2 Until May 10 -1 , r = 0.1 and N = 2, 4, 8, 16 and 32 SSDs (e.g., DRAM sharing), Figure 7 The normalized AFA bandwidth (performance) is shown versus the probability of a single SSD DRAM overflow. Note that with higher DRAM overflow probability and a larger number of SSDs in the AFA, up to a 2x performance improvement is observed.

[0127] V. System Implementation

[0128] It will be understood that the embodiments of the present disclosure may be implemented in various forms of hardware, software, firmware, dedicated processing, or combinations thereof. In one embodiment, the read / write request and packet processing algorithms according to the embodiments of the present disclosure may be implemented in hardware as an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA). In another embodiment, the algorithms according to the embodiments of the present disclosure may be implemented in software as an application program tangibly implemented on a computer readable program storage device. The application program may be uploaded to and executed by a machine comprising any suitable architecture.

[0129] Figure 8 is a block diagram of a system for implementing a read / write request and packet processing algorithm according to a disclosed embodiment. Figure 8, the computer system 81 includes, among other things, a central processing unit (CPU) or controller 82, a memory 83, and an input / output (I / O) interface 84. The computer system 81 is typically coupled to a display 85 and various input devices 86 (such as a mouse and a keyboard) via the I / O interface 84. Support circuits may include circuits such as caches, power supplies, clock circuits, and communication buses. The memory 83 may include a random access memory (RAM), a read-only memory (ROM), a disk drive, a tape drive, or the like, or a combination thereof. The algorithm according to an embodiment of the present disclosure may be implemented as a routine 87, which is stored in the memory 83 and executed by the CPU or controller 82 to process a signal from a signal source 88. Therefore, the computer system 81 is a general-purpose computer system that becomes a special-purpose computer system when executing the routine 87 of the present disclosure. Alternatively, as described above, an embodiment of the present disclosure may be implemented as an ASIC or FPGA 87 that communicates signals with the CPU or controller 82 to process a signal from a signal source 88.

[0130] The computer system 81 also includes an operating system and microinstruction codes. The various processes and functions described herein may be part of the microinstruction code or part of the application program (or a combination thereof) executed via the operating system. In addition, various other peripheral devices may be connected to the computer platform (such as additional data storage devices and printing devices).

[0131] It will also be understood that because some of the constituent system components and method steps depicted in the drawings can be implemented in software, the actual connections between the system components (or processing steps) may vary depending on how the disclosure is programmed. Given the teachings of the disclosure provided herein, one of ordinary skill in the relevant art will be able to consider these and similar implementations or configurations of the disclosure.

[0132] While the present disclosure has been described in detail with reference to exemplary embodiments, those skilled in the art will appreciate that various modifications and substitutions may be made thereto without departing from the spirit and scope of the disclosure as set forth in the appended claims.

Claims

1. A method for accelerating computational storage in an all-flash array network, the all-flash array network comprising a plurality of solid-state drives connected in a ring topology, wherein: Each of the plurality of solid state drives includes a controller and a dynamic random access memory connected to the controller, the method comprising: receiving, by a controller of the first solid-state drive, a request to read data from or write data to a dynamic random access memory associated with the first solid-state drive; creating a packet including an identifier of a first solid-state drive in a ring topology, an identifier of the packet, and a read / write flag identifying the request; and sending the packet to the next solid-state drive in the ring topology, Wherein, in response to the request being a read request, the read / write flag indicates a read request, and in response to the request being a write request, the read / write flag indicates a write request, and the packet includes data to be written.

2. The method according to claim 1, wherein: In response to the read / write flag indicating a read request and the read data address is not located in the dynamic random access memory associated with the first solid-state drive, the packet is sent to the next solid-state drive in the ring topology, The method further comprises: verifying that the read / write flag indicates a read request and that the read data address is located in a dynamic random access memory associated with the first solid state drive, and Data is read from a read data address in a dynamic random access memory associated with the first solid-state drive.

3. The method according to claim 1, wherein: In response to the read / write flag indicating a write request and the dynamic random access memory associated with the first solid-state drive being full, the packet is sent to the next solid-state drive in the ring topology, The method further includes verifying that the read / write flag indicates a write request and that a dynamic random access memory associated with the first solid-state drive is not full, and The data in the packet is written to a write address in a dynamic random access memory associated with a first solid-state drive.

4. The method according to claim 1, further comprising: receiving the packet via the next solid-state drive in the ring topology; verifying that the next solid-state drive in the ring topology is different from the first solid-state drive in the ring topology, that a read / write flag indicates a write request and that a dynamic random access memory associated with the next solid-state drive is not full; requesting a controller of the next solid-state drive for a write address of a dynamic random access memory associated with the next solid-state drive; writing the data in the packet to a write address of a dynamic random access memory associated with the next solid-state drive; updating the packet by setting a read / write flag to indicate a write confirmation; as well as The packet is sent to the next solid state drive in the ring topology.

5. The method according to claim 1, further comprising: receiving the packet via the next solid-state drive in the ring topology; verifying that the next solid-state drive in the ring topology is different from the first solid-state drive in the ring topology and that the read / write flag indicates a read request; requesting, from a controller of the next solid-state drive, a read data address of a dynamic random access memory associated with the next solid-state drive based on an identifier of a first solid-state drive in the ring topology and an identifier of the packet; updating the packet by setting a read / write flag to indicate a read acknowledgement and replacing data to be written with data read from a read data address; as well as The packet is sent to the next solid state drive in the ring topology.

6. The method according to claim 1, further comprising: receiving the packet via the next solid-state drive in the ring topology; verifying that the next solid-state drive in the ring topology is the first solid-state drive in the ring topology; In response to the read / write flag indicating a write confirmation, updating an incoming packet table and / or an outgoing packet table of a controller of the first solid-state drive; In response to the read / write flag indicating a write request and the dynamic random access memory associated with the first solid-state drive being full, performing dynamic random access memory out of space processing; as well as In response to the read / write flag indicating a read acknowledgement, the data of the packet is output to a host of the all-flash array network.

7. The method according to claim 1, wherein: The packet includes a field for an identifier of the first solid-state drive, a field for an identifier of the packet, a field for a read / write flag, and a field for data to be written to or read from a dynamic random access memory associated with the first solid-state drive.

8. An architecture for accelerating computational storage in an all-flash array, the architecture comprising: a plurality of solid-state drives connected to the input / output hub, wherein each of the plurality of solid-state drives comprises a controller, a dynamic random access memory connected to the controller, and a plurality of NAND memories connected to the controller, and processor, connected to the input / output hub, Wherein, the multiple solid-state drives are connected in a ring topology, in which each controller includes an input port and an output port, the input port of each solid-state drive is connected to the output port of the previous solid-state drive through a connector, and the input port of the first solid-state drive among the multiple solid-state drives is connected to the output port of the last solid-state drive among the multiple solid-state drives through a connector.

9. The architecture of claim 8, wherein: Each solid-state drive also includes a hardware accelerator connected to the dynamic random access memory, wherein the hardware accelerator accelerates tasks other than reading or writing to the dynamic random access memory of each solid-state drive.

10. The architecture of claim 8, further comprising: An artificial intelligence server, wherein the artificial intelligence server is a solid-state drive including a processor, a dynamic random access memory connected to the processor, and a plurality of NAND memories connected to the processor.

11. The architecture of claim 8, wherein: The connector is the cable.

12. An architecture according to any one of claims 8 to 11, wherein: Each solid-state drive controller includes: a dynamic random access memory manager connected to the dynamic random access memory and the output port; a packet buffer connected to the input port, the dynamic random access memory, and the output port; an inter-solid state drive finite state machine coupled to the packet buffer, the input port, and the DRAM manager, wherein the inter-solid state drive finite state machine performs packet routing and processing of received packets; a first multiplexer connecting the DRAM manager and the packet buffer to the output port; a second multiplexer connecting the DRAM manager and the packet buffer to the DRAM; and An additional component connects the dynamic random access memory manager to the host and the plurality of NAND memories.

13. The architecture of claim 12, wherein: Packet routing includes: receiving, by a controller of the first solid-state drive, a request to read data from or write data to a dynamic random access memory associated with the first solid-state drive, creating a packet including an identifier of a first solid-state drive in a ring topology, an identifier of the packet, and a read / write flag identifying the request; and sending the packet to the next solid-state drive in the ring topology, Wherein, in response to the request being a read request, the read / write flag indicates a read request, and in response to the request being a write request, the read / write flag indicates a write request, and the packet includes data to be written.

14. The architecture of claim 12, wherein: The processing of received packets includes: receiving the packet via the next solid-state drive in the ring topology; verifying that the next solid-state drive in the ring topology is different from the first solid-state drive in the ring topology, that a read / write flag indicates a write request and that a dynamic random access memory associated with the next solid-state drive is not full; requesting a controller of the next solid-state drive for a write address of a dynamic random access memory associated with the next solid-state drive; writing the data in the packet to a write address of a dynamic random access memory associated with the next solid-state drive; updating the packet by setting a read / write flag to indicate a write acknowledgement; and The packet is sent to the next solid state drive in the ring topology.

15. The architecture of claim 12, wherein: The processing of received packets includes: receiving the packet via the next solid-state drive in the ring topology; verifying that the next solid-state drive in the ring topology is different from the first solid-state drive in the ring topology and that the read / write flag indicates a read request; requesting, from a controller of the next solid-state drive, a read data address of a dynamic random access memory associated with the next solid-state drive based on an identifier of a first solid-state drive in the ring topology and an identifier of the packet; updating the packet by setting a read / write flag to indicate a read acknowledgement and replacing the data to be written with the data read from the read data address; and The packet is sent to the next solid state drive in the ring topology.

16. The architecture of claim 12, wherein: The DRAM manager includes: an incoming packet table including a field for an identifier of the solid state drive and a field for an identifier of an incoming packet; and An outgoing packet table includes a field for an identifier of the outgoing packet and a field for a dynamic random access memory data link.

17. An architecture for accelerating computational storage in an all-flash array, the architecture comprising: a plurality of solid state drives connected to the input / output hub, wherein each of the plurality of solid state drives comprises a controller, a dynamic random access memory connected to the controller, and a plurality of NAND memories connected to the controller; and processor, connected to the input / output hub, The input / output hub is configured to support incoming dynamic random access memory data and acknowledgement packets, and the controller of each solid-state drive is configured to route dynamic random access memory read and write requests and process received packets.

18. The architecture of claim 17, wherein: The routing steps include: receiving, by a controller of the first solid-state drive, a request to read data from or write data to a dynamic random access memory associated with the first solid-state drive, creating a packet including an identifier of the first solid-state drive, an identifier of the packet, and a read / write flag identifying the request; and sending the packet to an input / output hub, wherein the input / output hub sends the packet to a next solid-state drive, wherein, in response to the request being a read request, the read / write flag indicating a read request, and in response to the read / write flag indicating a read request and the read data address not being located in a dynamic random access memory associated with the first solid-state drive, the input / output hub sends the packet to the next solid-state drive, Wherein, in response to the request being a write request, the read / write flag indicates a write request, and in response to the read / write flag indicating a write request and the dynamic random access memory associated with the first solid-state drive being full, the input / output hub sends the packet to the next solid-state drive in the ring topology, and the packet includes data to be written.

19. The architecture of claim 18, wherein: The steps for processing a received packet include: receiving, by the next solid-state drive, the packet; verifying that the next solid-state drive is different from the first solid-state drive, that a read / write flag indicates a write request and that a dynamic random access memory associated with the next solid-state drive is not full; requesting a controller of the next solid-state drive for a write address of a dynamic random access memory associated with the next solid-state drive; writing the data in the packet to a write address of a dynamic random access memory associated with the next solid-state drive; updating the packet by setting a read / write flag to indicate a write acknowledgement; and The packet is sent to the input / output hub.

20. The architecture of claim 18, wherein: The steps for processing a received packet include: receiving, by the next solid-state drive, the packet; verifying that the next solid state drive is different from the first solid state drive and that the read / write flag indicates a read request; requesting, from a controller of the next solid-state drive, a read data address of a dynamic random access memory associated with the next solid-state drive based on an identifier of the first solid-state drive and an identifier of the packet; updating the packet by setting a read / write flag to indicate a read acknowledgement and replacing the data to be written with the data read from the read data address; and The packet is sent to the input / output hub.

Images