TWI912560B - System and method for triggering a visual indicator of a faulty memory drive - Google Patents

Abstract

There is provided a system having a server unit with a host processor and a service processor, a first bus interface and a second bus interface, a data storage unit with a plurality of drives grouped into a first and second group, a first serial-to-parallel-input/output (S2PIO) device connected to the first group, and a second S2PIO device connected to the second group. The system is configured to acquire, by the service processor from the host processor, an indication of a faulty memory drive in the data storage unit, the indication being indicative of a target link amongst the first link and the second link, and a position of the faulty memory drive in the target group. The system is configured to transmit, by the service processor using the target link, a command to a target S2PIO device for triggering a visual indicator associated with the faulty memory drive.

Description

System and method for actuating a visual indicator of a damaged memory disk

This technology relates to data storage solutions, and more specifically, to a system and method for actuating a visual indicator of a damaged memory disk.

Due to the massive amounts of digital data created daily, storage requirements for storing this data are constantly increasing. For example, there may be a need to store various types of user data, organizational data, and/or application data. This increases the demand for data storage capacity. Cloud storage systems can provide users and/or organizations with the data storage capacity to meet these ever-increasing storage requirements.

Generally speaking, cloud storage is a model of computer storage where digital data is stored in a logical area. The physical storage that actually stores the digital data can span multiple servers that may be located in different locations (i.e., different data centers) and are typically managed by a company that hosts the cloud storage service. Users and/or organizations typically purchase or lease storage capacity from cloud storage service providers to store their digital data. The cloud storage service provider is then responsible for keeping the digital data available and accessible, while ensuring that the physical storage is protected against data loss.

U.S. Patent Application No. 2020/0028902 discloses a housing comprising a plurality of nodes, a network switch, and a programmable device configured to manage a shared resource of the housing.

The developers of this technology have understood certain technical shortcomings associated with previous technologies.

The developers of this technology have recognized that some solutions employ a bus interface between a baseboard management controller (BMC) of a server unit and a BMC of a storage unit, particularly for sending commands to actuate visual indicators of faulty drives. However, BMC-BMC communication is inefficient due to its susceptibility to timeouts, retries, and other factors stemming from the complexity of the multi-layered communication protocols used to establish BMC-BMC communication.

In summary, a server unit's BMC (Browser Control Center) is located on the server's motherboard and is used to monitor the physical status of the server unit. It is a dedicated microcontroller that can be embedded on the motherboard of a computer (such as a server unit). A BMC also manages the interface between system management software and platform hardware. A BMC can have its own firmware and volatile memory. It should be noted that different types of sensors built into the server unit can report parameters to the BMC, such as temperature, cooling fan speed, power status, and operating system (OS) status. The BMC can monitor the sensors and, if any parameter is not kept within preset limits (indicating a potential fault in the system), can send an alarm via the network to a system administrator. Administrators can also communicate remotely with the BMC to take corrective actions, such as resetting the system or restarting the power to get a crashed OS running again. These capabilities can reduce the total cost of owning or operating a system.

The developers of this technology have designed a system comprising a server unit, a data storage unit, and a bus architecture for providing more efficient communication between the server unit and the data storage unit. More specifically, in a bus architecture implemented according to a non-limiting embodiment of this technology, the BMC-BMC communication link present in other known solutions is no longer required, with the bus architecture positioned between the server unit and the data storage unit. The bus architecture disclosed herein particularly allows for the actuation of visual indicators for disk drive failures without communication between the BMC of a server unit and the BMC of a data storage unit.

In one first general embodiment of the present art, a system is provided, comprising: a server unit including a host processor for generating input/output (I/O) operations and a service processor for monitoring the physical status of the server unit; and a first bus interface for transmitting the I/O operations from the host processor to a data storage unit for execution. The data storage unit includes: a plurality of memory disks for performing the I/O operations, wherein the plurality of memory disks are grouped into a first group and a second group, and wherein a given memory disk from a respective group (i) is associated with a respective location in the respective group, and (ii) has a respective visual indicator indicating the status of the given memory disk; a first serial-to-parallel input/output (S2PIO) device connected to the first group for controlling the visual indicators of the respective memory disks from the first group; and a second S2PIO device connected to the second group for controlling the visual indicators of the respective memory disks from the second group. The system includes a second bus interface for transmitting commands from the service processor to one of the first and second S2PIO devices, wherein the second bus interface includes a first link between the service processor and the first S2PIO device and a second link between the service processor and the second S2PIO device. The system is configured to: obtain an indication of a damaged memory disk in the data storage unit from the host processor via the service processor. The indication indicates a target link of the first and second links and the location of the damaged memory disk in a target group. The target link is connected to one of the first S2PIO devices and the second S2PIO device, and the target S2PIO device is connected to a target group associated with the damaged memory disk in the first and second groups. The system is configured to transmit a command to the target S2PIO device via the target link through the server processor, wherein the command is used to cause the target S2PIO device to actuate a visual indicator associated with the damaged memory disk based on the location of the damaged memory disk in the target group.

In some embodiments of the system, the first S2PIO and the second S2PIO each have a unique identifier. The system is further configured to transmit an indication of one of the unique identifiers of the target S2PIO to the service processor via the target S2PIO. The unique identifier of the target S2PIO and the location of the damaged memory disk in the target group form a unique identifier for the damaged memory disk in the data storage unit.

In some embodiments of the system, the service processor of the server unit is a baseboard management controller (BMC) of the server unit.

In some embodiments of the system, the first bus interface is a serial AT Attached (SATA) bus interface.

In some embodiments of the system, the second bus interface is an inter-integrated circuit (I2C) bus interface, wherein the first link is a first I2C link and the second link is a second I2C link.

In some embodiments of the system, the data storage unit is a clustered disk (JBOD) unit.

In some embodiments of the system, the plurality of memory disks includes at least one of a hard disk drive (HDD) and a solid-state drive (SSD).

In some embodiments of the system, the S2PIO device is a general-purpose I/O (GPIO) expander device.

In some embodiments of the system, the GPIO expander device is a PCA9995.

In some embodiments of the system, the S2PIO device is a complex programmable logic device (CPLD).

In some implementations of the system, the S2PIO is a programmable gate array (FPGA).

In a second broad embodiment of the present invention, a computer implementation method is provided for actuating an indicator of a damaged memory disk. The method can be performed by a system. The system includes: a server unit comprising a host processor for generating input/output (I/O) operations and a service processor for monitoring the physical status of the server unit; and a first bus interface for transmitting the I/O operations from the host processor to a data storage unit for execution. The data storage unit includes a plurality of memory disks for performing the I/O operations, wherein the plurality of memory disks have been grouped into a first group and a second group. A given memory disk from a respective group (i) is associated with a respective location in the respective group, and (ii) has a respective visual indicator indicating the state of the given memory disk. The system includes a first serial-to-parallel input/output (S2PIO) device connected to the first group for controlling visual indicators of respective memory disks from the first group, and a second S2PIO device connected to the second group for controlling visual indicators of respective memory disks from the second group, and a second bus interface for transmitting commands from the server to the first and second S2PIO devices, wherein the second bus interface includes a first link between the server and the first S2PIO device and a second link between the server and the second S2PIO device. The method includes: obtaining an indication of a damaged memory disk in the data storage unit from the host processor via the server. The indication indicates a target link of the first link and the second link, and a position of the damaged memory disk within a target group. The target link is connected to a target S2PIO device of the first S2PIO device and the second S2PIO device, and the target S2PIO device is connected to a target group associated with the damaged memory disk within the first and second groups. The method includes transmitting a command via the target link to the target S2PIO device using the server processor, wherein the command causes the target S2PIO device to actuate a visual indicator associated with the damaged memory disk based on the position of the damaged memory disk within the target group.

In some embodiments of the method, the method further includes transmitting an indication of one of the unique identifiers of the target S2PIO to the service processor via the target S2PIO. The unique identifier of the target S2PIO and the location of the damaged memory disk in the target group form a unique identifier of the damaged memory disk in the data storage unit.

In a third broad embodiment of the present art, a system is provided comprising: a server unit including a processor for generating input/output (I/O) operations and a baseboard management controller (BMC) for monitoring a physical state of the server unit; and a bundled disk (JBOD) coupled to the server unit via a SATA bus for receiving the I/O operations from the processor. The JBOD includes a plurality of memory disks for performing the I/O operations, and the plurality of memory disks are grouped into a first group and a second group. A given memory disk from each group (i) is associated with a respective location within the respective group, and (ii) has a respective visual indicator indicating a state of the given memory disk. The system includes a first general purpose input/output (GPIO) connected to the first group for controlling visual indicators of respective memory disks from the first group, and a second GPIO connected to the second group for controlling visual indicators of respective memory disks from the second group. The system includes a BMC connected to the first GPIO for transmitting commands from the BMC to a first I2C bus of the first GPIO; and a BMC connected to the second GPIO for transmitting commands to a second I2C bus of the second GPIO. The system is configured to obtain an indication of a damaged memory disk in the JBOD from the processor via the BMC. The indication specifies a target I2C bus, either the first or the second I2C bus, and a location of the damaged memory disk within a target group. The target I2C bus is connected to a target GPIO, either the first or the second GPIO, and the target GPIO is connected to a target group associated with the damaged memory disk within the first and second groups. The system is configured to transmit a command via the BMC to the target GPIO using the target I2C bus, wherein the command causes the target GPIO to actuate a visual indicator associated with the damaged memory disk based on the location of the damaged memory disk within the target group.

In some embodiments of the system, the first GPIO and the second GPIO each have a unique identifier, and the system is further configured to transmit one of the unique identifiers of the target GPIO to the BMC via the target GPIO. The unique identifier of the target GPIO and the location of the damaged memory disk in the target group form a unique identifier of the damaged memory disk in the JBOD.

In the context of this specification, "client device" refers to any computer hardware capable of running software appropriate for the relevant task at hand. Therefore, some (non-limiting) examples of client devices include personal computers (desktops, laptops, laptops, etc.), smartphones and tablets, and network devices (such as routers, switches, and gateways). It should be noted that the device used as a client device in this context may be used as a server for other client devices. The use of "client device" does not preclude the use of multiple client devices for receiving/sending, performing, or causing any task or request to be performed, or the result of any task or request, or the steps of any method described herein.

In the background section of this manual, the term "information" is used to refer to any type or nature of information that can be stored in a database. Therefore, information includes (but is not limited to) audiovisual works (images, films, recordings, demonstrations, etc.), data (location data, numerical data, etc.), text (opinions, comments, questions, messages, etc.), documents, spreadsheets, word lists, etc.

In the context of this manual, the term "component" means software that is both necessary and sufficient to achieve the specific functions referred to (for a specific hardware context).

In the background section of this manual, the statement "computers can use information storage media" is intended to include media of any nature and type, including RAM, ROM, disks (CD-ROM, DVD, floppy disk, hard disk drive, etc.), USB keys, solid-state drives, tape drives, etc.

In the background of this specification, the terms "first," "second," "third," etc., are used as adjectives only to distinguish these modified nouns from one another and not to describe any particular relationship between them. Therefore, for example, it should be understood that the use of the terms "first server" and "third server" is not intended to imply, for example, any particular order, type, timing, hierarchy, or sequence of servers, nor is it intended to imply that any "second server" must necessarily exist in any given situation. Furthermore, as discussed elsewhere in the background, references to a "first" element and a "second" element do not preclude the two elements from being the same real-world element. Therefore, for example, in some cases, a "first" server and a "second" server may be the same software and/or hardware, while in others they may be different software and/or hardware.

Each embodiment of this technology has at least one of the purposes and/or forms mentioned above, but not necessarily all of them. It should be understood that some forms of this technology arising from an attempt to achieve the purposes mentioned above may not satisfy these purposes and/or may satisfy other purposes not specifically described herein.

The additional and/or alternative features, forms and advantages of the embodiments of the present invention will become clear from the following description, accompanying drawings and the accompanying invention application scope.

This detailed description is intended only to illustrate one example of the art. It is not intended to define the scope of the art, nor does it set forth its boundaries.

Furthermore, unless such a modification is described (i.e., unless an example of modification is explained), it should not be interpreted as impractical without modification and/or that the described content is the only way to implement the specific form of the present technology. Additionally, it should be understood that this detailed description provides simple implementations of the present technology in certain examples, and in such cases, they are presented in this manner to aid understanding. Various implementations of the present technology can have greater complexity.

Referring to Figure 1, a system 100 is depicted. System 100 is configured for a non-limiting embodiment of the present invention. It should be clearly understood that the depicted system 100 is merely one illustrative embodiment of the present invention. Therefore, the following description is intended only as one illustrative example of the present invention. This description is not intended to define the scope or limits of the present invention.

In some cases, examples believed to be modifications to System 100 may also be described below. This is done solely to aid understanding and, again, does not define the scope or limit of the art. Such modifications are not exhaustive and, as those skilled in the art will understand, other modifications may be feasible. Furthermore, the absence of such description (i.e., the absence of examples of modifications described) should not be interpreted as the absence of modifications and/or as the only way to implement the elements of the art. As those skilled in the art will understand, this may not be the case. Additionally, it should be understood that System 100 may provide simplified implementations of the art in certain examples, and in such cases, they are presented in this manner to aid understanding. Those familiar with this technology should understand that various implementation schemes of this technology can have greater complexity.

System 100 includes a request source 102, a communication network 103, and a processing subsystem 108. How the components listed above in System 100 are implemented according to various non-limiting embodiments of the present art will now be described. Request Source

Request source 102 may be an electronic device associated with an end user (e.g., a client device) or, alternatively, any other subsystem of system 100 configured to provide user requests to system 100. It should be clearly understood that while Figure 1 depicts only a single example of request source 102, system 100 may have multiple examples of request source 102. As illustrated herein, request source 102 is part of system 100; however, in some embodiments of the art, request source 102 may be external to system 100 and connected via a communication link (without component symbols).

In fact, a typical implementation of System 100 can contain a large number of request sources 102, such as hundreds, thousands, millions of instances and similar.

In some embodiments of this technology, where system 100 is used in a business-to-customer (B2C) environment, request source 102 may be, for example, a given client device associated with a given user of system 100, such as a smartphone. For example, system 100 may potentially provide cloud storage services to the given user's given client device.

In other embodiments of this technology, where system 100 is used in a business-to-business (B2B) environment, request source 102 may, for example, provide user requests to one of the stator systems in system 100, such as a remote server. For example, in some embodiments of this technology, system 100 may provide fault-tolerant data processing and/or storage services to one of the stator system operators.

In summary, request source 102 may be a client device or another subsystem that can be given either inside or outside of system 100, regardless of whether system 100 is implemented as a B2C or a B2B system (or any other variation of the system for that matter).

As mentioned above, request source 102 is configured to issue a plurality of requests 180, each of which will be referred to as request 180 below. The nature of request 180 will depend on the type of request source 102 and the specific implementation of this technology.

In some embodiments of this art, request source 102 is also configured to receive a plurality of responses 181, each of which will be referred to below as a response 181. Generally speaking, in response to request 180 being processed (or potentially unprocessed) by system 100, system 100 may generate a response 181 destined for the request source 102 associated with each request 180. The nature of the response 181 will depend in particular on the type of request source 102, the type of each request 180, and whether system 100 processes (or potentially unprocesses) each request 180.

In one example, during the processing of request 180, system 100 may be configured to request additional data from request source 102 to continue or complete the processing of request 180. In this case, system 100 may be configured to generate a response 181, which is in the form of a data request message instructing system 100 to request additional data to continue or complete the processing of request 180.

In another example, if system 100 successfully processes each request 180, system 100 may be configured to generate a response 181 in the form of a success message indicating that each request 180 has been successfully processed.

In a further example, if system 100 fails to successfully process each request 180, system 100 can be configured to generate a response 181 in the form of a failure message indicating that the processing of each request 180 has failed. In this case, request source 102 can be configured to perform additional actions, such as (but not limited to) re-issuing request 180, performing a diagnostic analysis to identify the cause of the failure of system 100 to process request 180, issuing a new request or similar request destined for system 100. Communication Network

Request source 102 is communicatively coupled to communication network 103 for providing request 180 to system 100 and for receiving response 181 from system 100. In some non-limiting embodiments of the present invention, communication network 103 may be implemented as the Internet. In other non-limiting embodiments of the present invention, communication network 103 may be implemented differently, such as any wide area communication network, local area communication network, a private communication network, and the like. How a communication link (without separate component symbols) between request source 102 and communication network 103 is implemented will depend in particular on how request source 102 is implemented.

By way of example only and not as a limitation, in the embodiments of the present art in which claim 102 is implemented as a wireless communication device (such as a smartphone), the communication link may be implemented as a wireless communication link (such as (but not limited to) a 3G communication network link, a 4G communication network link, Wi-Fi or abbreviated as WiFi®, Bluetooth® and the like). In the embodiments in which claim 102 is implemented as a remote server, the communication link may be wireless (such as Wi-Fi or abbreviated as WiFi®, Bluetooth® or the like) or wired (such as an Ethernet-based connection).

It should be noted that communication network 103 is configured to transmit, in particular, a request data packet including request 180 from request source 102 to request preprocessing subsystem 104 of system 100. For example, this request data packet may include computer-executable instructions written in a declarative programming language representing request 180. Communication network 130 is also configured to transmit, in particular, a response data packet including response 181 from system 100 to request source 102. For example, this response data packet may include computer-executable instructions representing response 181.

However, upon careful consideration, in some embodiments of this technology, where the request source 102 is a stator subsystem of system 100, for example, the communication network 103 may be implemented in a manner different from that described above, or in some cases, even omitted, without departing from the scope of this technology. Processing Subsystem

As mentioned above, system 100 also includes processing subsystem 108. Generally speaking, processing subsystem 108 is configured to process and store data based on request 180.

To process and store data, the processing subsystem 108 includes a plurality of server racks 150, each of which will be referred to below as a server rack 150. According to various embodiments of the present invention, some or all of the plurality of server racks 150 may be located in a single location or distributed across different locations. For example, some or all of the plurality of server racks 150 may be located in a single data center and/or distributed across a plurality of data centers.

Generally speaking, a given server rack is a cabinet that encloses various hardware devices and is typically used to house and organize the hardware in a way that optimizes the equipment and utilizes the floor space within the data center. In some cases, enclosing the hardware in a server rack adds extra security against theft or accidental damage. In other cases, enclosing the hardware in a server rack allows for better control of airflow and thus improved cooling of the hardware.

The server rack 150 includes a plurality of trays 200, each of which will be referred to below as a tray 200. Generally speaking, a given tray 200 allows a human operator to remove hardware located in the given tray for testing, maintenance and replacement.

In some cases, a given pallet may contain a hardware component referred to herein as a "server". In other cases, a given pallet may contain a hardware component referred to herein as a "data storage unit". Thus, server rack 150 may include a plurality of server-dedicated pallets, each containing one or more servers, and a plurality of data storage-dedicated pallets, each containing one or more data storage units.

Referring to Figure 2, a left-front top perspective view is depicted of a data storage unit 202 positioned within a tray 200. In at least one embodiment of the present art, the data storage unit 202 may be implemented as a "JBOD," which uses an architecture that can independently process or can be combined into a plurality of logical volumes using a volume manager or a cross-device file system. Needless to say, the tray 200 is configured to move between a closed position and one or more extended positions, in which only a front panel (without component symbols) is accessible to a human operator, and in the extended positions, additional components of the JBOD within the tray 200 become accessible to a human operator.

Data storage unit 202 includes a plurality of memory disks 210, each of which will be referred to below as a memory disk 210. A memory disk 210 may be implemented as a solid-state drive (SSD), a hard disk drive (HDD), or the like. Upon careful consideration, a memory disk 210 may be a given disk-type drive or a stationary (static) disk drive. Upon careful consideration, the plurality of memory disks 210 may include at least some HDDs and at least some SSDs. In one embodiment of the present invention, the plurality of memory disks 210 may include 28 memory disks. In other embodiments, more or fewer than 28 memory disks may be included in data storage unit 202 without departing from the scope of this technology.

Data storage unit 202 includes a host board 220 that maintains and provides communication among the various hardware components of data storage unit 202. As depicted in this embodiment, host board 220 houses a server processor 230 of data storage unit 202 and is adapted for connecting a fan (not labeled) and a power supply (not labeled) and several buses 250.

It should be noted that the memory disk 210 has a visual indicator 215. In general, the visual indicator 215 is used to indicate the status of the respective memory disk 210 to a human operator. Typically, two visual indicators 215 can be positioned on the memory disk and can be implemented via light-emitting diodes (LEDs) and other suitable components.

When memory disk 210 requires maintenance or replacement, for example, system 100 can configure and actuate a given visual indicator 215 for one of memory disks 210, so that a human operator knows which memory disk 210 is being detected in a given server room, and more specifically, in server rack 150. The additional hardware components of subsystem 108 and how subsystem 108 configures and actuates a given visual indicator for a damaged memory disk will now be discussed in more detail with reference to FIG3.

Figure 3 schematically represents a data storage unit 202, a server unit 302, and a bus interface 300 for implementing communication between the data storage unit 202 and the server unit 302 in the processing subsystem 108. As mentioned above, the server unit 302 may be located in a server rack 150 and/or in a given server-dedicated tray in another server rack in the same server room and/or a different server room.

Server unit 302 includes a "host" section 303. In general, host section 303 may be referred to as the main processing section of server unit 302. Host section 303 includes a host processor 310. Upon careful consideration, more than one host processor 310 may be part of the host section 303 of server unit 302. Host section 303 also includes several other hardware components 320, including (but not limited to): a plurality of volatile memory disks, a plurality of non-volatile memory disks, a plurality of network interfaces, a plurality of PCIe interfaces for connecting external PCIe devices, and the like. The host unit 303 also includes connectors 351 and 352 for providing communication between the host unit 303 and the data storage unit 202 via a bus interface, which will be discussed in more detail below.

The host processor 310 is configured to run an operating system (OS) 315 of the server unit 302. In general, a given OS is a software component that performs several tasks of the server unit 302, such as (for example) file management, memory management, program management, handling input and output, and controlling peripheral devices, such as memory disks and printers.

OS 315 can be an "off-the-shelf" OS without specific restrictions. However, in some implementations, OS 315 can be implemented as a Linux-based OS. In other implementations, OS 315 can be implemented as a Debian-based OS.

The host processor 310 running OS 315 is also configured to execute a disk drive health management application 317. In summary, the disk drive health management application 317 is configured to monitor "health data" obtained by the host processor 310 from a plurality of memory disks 210 and is configured to analyze this health data to determine the health status of one or more of the memory disks 210. For example, the health data analyzed by the disk drive health management application 317 may include indications of temperature, voltage, and current obtained from the respective memory disks 210 (and/or their groups). In the case of an HDD, the health data analyzed by the disk drive health management application 317 may also include indications of several worn sectors on a given HDD.

There is no specific restriction on which disk drive health management application is used, and the choice of a given disk drive health management application can depend particularly on different implementations of this technology. Disk drive health management application 317 is configured to analyze health data to determine the health status of different disk drives and identify one or more damaged disk drives among them, regardless of which specific disk drive health management application is used. In the background of this technology, the host processor 310 can utilize disk drive health management application 317 to issue one or more commands to actuate a visual indicator of a damaged disk drive. The use of disk drive health management application 317 by the host processor 310 to issue such one or more commands will be discussed in detail below.

Server unit 302 also includes a server processor 330. In some embodiments, the server processor 330 may be implemented as a baseboard management controller (BMC) of server unit 302. In general, the BMC of server unit 302 is located on the server's motherboard and is used to monitor the physical status of server unit 302. It is a dedicated microcontroller that can be embedded on the motherboard of a computer (such as a server unit). A BMC can also manage the interface between system management software and platform hardware. A BMC may have its own firmware and volatile memory. It should be noted that various types of sensors built into server unit 302 (and other computer systems potentially in processing subsystem 108) can report parameters to the BMC (e.g., components of server unit 302 and/or other computer systems in processing subsystem 108), such as temperature, cooling fan speed, power status, and operating system (OS) status. The BMC can monitor the sensors and send an alert to a system administrator via the network if any parameter fails to remain within preset limits (indicating a potential fault in the system). The administrator can also communicate remotely with the BMC to take corrective actions, such as resetting the system or restarting the power to get a crashed OS running again. These capabilities can reduce the total cost of owning or operating a system.

By way of example only, server processor 330 may be used to (i) control the host power status (power on, power off) and to allow remote power on and power off of server unit 302 via commands from an external system transmitted over the network, (ii) monitor host health (temperature, hardware errors and anomalies) via various hardware sensors (such as temperature sensors, voltage and current sensors, and airflow sensors), (iii) provide remote access to the keyboard, mouse and video monitor of host unit 303 via the network, and (iv) control cooling fans and the like depending on the temperature of the server components.

In at least some embodiments, the server processor 330 of the BMC implemented as server unit 302 may be referred to as a dedicated computing device within server unit 302, and may be powered independently of host unit 303 and powered when power is applied to server unit 302 and before host unit 303 is powered on.

As described above with reference to Figure 2, storage unit 202 includes a server processor 230, multiple memory disks 210, and connectors 353 and 354. Similar to the server processor 330 of server 302, the server processor 230 of data storage unit 202 can be implemented as the BMC of data storage unit 202. The server processor 230 is configured to monitor the physical status of data storage unit 202, and therefore, can perform functions similar to those performed by the server processor 330 in server unit 302 within data storage unit 202. However, the functionality of the server processor 230 in the data storage unit 202 may also exclude some functions of the server processor 330 in the server unit 302, such as (for example) providing access to a keyboard, a mouse and a monitor.

The developers of this technology have recognized that some solutions employ a bus interface between a BMC in a server unit and a BMC in a storage unit, particularly for sending commands to actuate visual indicators of a damaged disk drive. However, BMC-BMC communication is inefficient due to its susceptibility to timeouts, retries, and other factors stemming from the complexity of the multi-layered communication protocols used to establish BMC-BMC communication.

The developers of this technology have designed a system comprising a server unit, a data storage unit, and a bus architecture for providing more efficient communication between the server unit and the data storage unit. More specifically, in a bus architecture implemented according to a non-limiting embodiment of this technology, the BMC-BMC communication link present in other known solutions is no longer required, with the bus architecture positioned between the server unit and the data storage unit. As will become clear from the further description herein, the new bus architecture designed by the developers of this technology particularly allows the actuation of a visual indicator of a damaged disk drive without communication between the BMC of a server unit and the BMC of a data storage unit.

Referring back to the description in Figure 3, it should be noted that the plurality of memory disks 210 are "grouped" into groups comprising a first group 360 of memory disks 210 and a second group 370 of memory disks 210. For simplicity, other memory groups from the plurality of memory disks 210 have been omitted. In one embodiment, the data storage unit 202 may contain seven groups of memory disks 210 without departing from the scope of this art.

In the background of this technology, each group of memory disks is connected to a separate serial-to-parallel input/output (S2PIO) device. In general, a given S2PIO device is a given device that is connected to a serial bus interface on one hand and has several parallel I/O connections on the other hand.

In some embodiments, a given S2PIO device may be a given general purpose I/O (GPIO) expansion device. In general, a GPIO is an unauthorized digital signal pin on an integrated circuit or electronic circuit board that can be used as an input or output.

In one implementation, a PCA9555 can be used as a GPIO expansion device without departing from the scope of this technology. The PCA9555 is a 24-pin CMOS device from NXP Semiconductors, providing 16-bit GPIO expansion for I2C bus/SMBus applications and developed to enhance I2C bus I/O expansion capabilities. The I/O expander provides a simple solution when additional I/O is required for ACPI power switches, sensors, buttons, LEDs, fans, etc. The PCA9555 consists of two 8-bit configuration (input or output selection) registers; input, output, and polarity inversion (active high or active low operation) registers. I/O can be implemented as input or output by writing to the I/O configuration bits. Data for each input or output is stored in the corresponding input or output register. The polarity of a register can be read using a polarity inverter register. The PCA9555 open-drain interrupt output can be activated when any input state differs from the state of its corresponding input port register and is used to indicate to the system controller that an input state has changed. These hardware pins (A0, A1, A2) vary the fixed I2C bus address and allow up to eight devices to share the same I2C bus/SMBus.

However, in other embodiments, S2PIO can be implemented as a given complex programmable logic device (CPLD), a field programmable gate array (FPGA), and the like, without departing from the scope of this art. Upon careful consideration, a given S2PIO device can be configured to convert data received via a respective serial bus to the state that its I/O pins should have, change the state of its I/O pins, and convert data indicating the current state of its I/O pins to data to be loaded via the respective serial bus.

As depicted, the first group 360 is connected to a first S2PIO device 380 via link 385, and the second group 370 is connected to a second S2PIO device 390 via link 395. It should be noted that a given memory disk has a relative position within its respective group. For example, in a given group of four drives, a given drive may be a first, second, third, or fourth drive, depending on which links connect it to its respective S2PIO device. For example, if a given drive is connected to a first group of links within its respective S2PIO device, then the drive can be considered the first drive in its respective group of four drives. In the same example, if a given drive is connected to a second set of links in one of the respective S2PIO devices, then the drive can be considered as the second drive in each of the four drive groups. Which drive in a drive group has which relative position is less important than the fact that each drive has a unique relative position in its respective drive group.

The first S2PIO device 380 and the first group 360 of the memory disk 210 are connected to a connector 353 via their respective bus interfaces for communication with the server unit 302. The second S2PIO device 390 and the second group 370 of the memory disk are connected to a connector 354 via their respective bus interfaces for communication with the server unit 302. It should be noted that the memory disk 210 is connected to the server unit 302 via a first bus interface 304, and the S2PIO device is connected to the server unit 302 via a second bus interface 305.

In some embodiments of this technology, the first bus interface 304 may be a Serial AT Attached (SATA) bus interface. In general, SATA is a computer bus interface that connects a host bus adapter to a mass storage device (such as an HDD, optical drive, or SSD). In other embodiments, the first bus interface may be implemented as a SCSI, SAS, or PCIe bus.

In the illustrated example, the first group 360 of memory disk 210 can be connected to host processor 310 via a first SATA link 341 through connectors 351 and 353. In the same example, the second group 370 of memory disk 210 can be connected to host processor 310 via a second SATA link 342 through connectors 352 and 354.

The first bus interface 304 is configured to transmit I/O operations between the host processor 310 and the memory disk 210. The first bus interface 304 is also configured to transmit health data between the memory disk 210 and the host processor 310 for management and analysis by the disk drive health management application 317.

In some embodiments of this technology, the second bus interface 305 may be an inter-integrated circuit (I2C) bus interface. In general, I2C is widely used to attach lower-speed peripheral ICs to a synchronous, multi-master, multi-slave, packet-switched, single-ended serial communication bus of a processor and/or microcontroller. It should be noted that a subset of I2C buses is called a System Management Bus (SMBus). One purpose of SMBus is to promote robustness and interoperability. Therefore, modern I2C systems incorporate some policies and rules from SMBus, sometimes supporting both I2C and SMBus with minimal reconfiguration via command or output pins. In other embodiments, the second bus interface may be implemented via CANbus or RS-422 (ANSI/TIA/EIA-422-B).

In the illustrated example, the first S2PIO device 380 can be connected to the server processor 330 of the server unit 302 via a first I2C link 343 passing through connectors 351 and 353. In the same example, the second S2PIO device 390 can be connected to the server processor 330 of the server unit 302 via a second I2C link 344 passing through connectors 352 and 354.

The second bus interface 305 is configured to transmit commands from the server processor 330 of the server unit 302 and their respective S2PIO devices. The commands transmitted via the second bus interface 305 may include commands to actuate the visual indicators of their respective memory disks 210. The second bus interface 305 is also configured to provide information about the current status of their respective S2PIO devices and their respective inputs and outputs (pins) to the server processor 330 of the server unit 302.

The following describes, with reference to Figure 4, how the processing subsystem 108 is configured to operate a visual indicator for actuating a given damaged disk drive. The host processor 310 is configured to receive health data 402 via the second SATA link 342 and to provide the health data 402 to the disk drive health management application 317. The health data 402 includes information indicating the health status of memory disks 210 in a corresponding target group of memory disks associated with the second SATA link 342. It should be noted that, specifically, the host processor 310, in a certain sense, "does not know" which memory disks 210 are associated with the second SATA link 342. In other words, the host processor 310 does not yet know which group of disk drives in the data storage unit 202 is the target group of the disk drives connected via the second SATA link 342.

The host processor 310 employs a disk drive health management application 317 to determine which (if any) of the memory disks 210 from the target group is a damaged memory disk. For example, the disk drive health management application 317 may determine, based on health data 402, that the second memory disk (the relative position of the disk drive within the group) from the target group is damaged. Again, it should be noted that the host processor 310 does not know whether the target group corresponding to the memory disk on the second SATA link 342 is the first group 360 or the second group 370; that is, the host processor 310 knows, based on health data 402, that the second memory disk (relative position) via the second SATA link 342 may be damaged.

Host processor 310 is configured to issue a command 404 to server processor 330 via a link 311. Command 404 is configured to instruct server processor 330 to actuate a visual indicator of the damaged memory disk. For example, command 404 may be transmitted via link 311 according to an OEM IPMI protocol. Command 404 includes information indicating: (i) a relative position of the damaged memory disk in a target group, and (ii) a link from which host processor 310 has obtained health data 402. In other words, command 404 includes information indicating that a second memory disk in a given group of memory disks connected via a second SATA link 342 (via connectors 352 and 354) is a damaged memory disk.

Server processor 330 is configured to process command 404 to (i) generate a command 406 for actuating a visual indicator of a second party in a target group from a memory disk, and (ii) identify a target I2C link through which command 406 is to be transmitted. In this example, server processor 330 may identify, based on command 404, that the target I2C link through which command 406 is to be sent is a second I2C link 342 (via connectors 352 and 354). Therefore, server processor 330 is configured to issue command 406 via the second SATA link 342. Command 406 is a low-level command carrying information about which I/O pin of the corresponding target S2PIO device should change its state.

Command 406 is received by the target S2PIO device and instructs that the state of a pin associated with a visual indicator of the second memory disk within the target group should be changed. The target S2PIO device changes the state of the corresponding pin, thereby actuating the visual indicator of the damaged disk drive. The actuated visual indicator assists the human operator in performing maintenance on the damaged disk drive by visually displaying the damage status of the disk drive.

It should be noted that each S2PIO device may have a unique identifier among the S2PIO devices associated with its respective group of memory disk 210 in data storage unit 202. After careful consideration, the target S2PIO device is configured to send information indicating its respective unique identifier back to the server processor 330. Therefore, the server processor 330 now "knows" which specific memory disk is the damaged memory disk. In fact, based on information provided by the target S2PIO device via the second I2C link 342, the server processor 330 may be configured to identify the target S2PIO device as a second S2PIO device 390 associated with the second group 370 of the memory disk. By combining information indicating the relative location of the damaged memory disk (from the second memory disk of the target group) within the target group, the server processor 330 can be configured to identify the damaged memory disk as the second memory disk 210 of the second group 370 from the memory disk connected to the second S2PIO device 390. In other words, the server processor 330 can determine an absolute location of the damaged memory disk by accessing information indicating: (i) which S2PIO device in the data storage unit 202 is the target S2PIO, and (ii) which memory disk in each target group is the damaged disk drive.

In some embodiments, after careful consideration, identifying a specific memory disk (the target I2C link and the relative position of the damaged disk drive within the target group) as a damaged disk drive allows the server processor 330 of server unit 302 to provide support to human operators during maintenance.

For example, suppose a human operator decides to disconnect a damaged memory disk and replace it with a new one, but mistakenly disconnects the wrong memory disk for replacement. In this example, it is also assumed that the human operator disconnects the third memory disk in the second group 370 instead of the second memory disk. The target S2PIO device (the second S2PIO device 390) can be configured to read the current state of its pins and determine that the pins of the third memory disk in its disk drive group have been disconnected. This information can be transmitted via the second I2C link 342 to the server processor 330, and then via link 311 to the host processor 310. The disk drive health management application 317 can be configured to compare the acquired information with information identifying a damaged disk drive. In this example, the disk drive health management application 317 can determine that a memory drive other than the damaged one has been disconnected from the target disk drive group. The disk drive health management application 317 can be configured to issue one or more remedial actions to notify the human operator of this effect.

In some embodiments of this technology, after careful consideration, system 108 can be configured to execute a method 500, which is shown as a schematic block representation of method 500 in Figure 5. The various steps of method 500 will now be described in detail. Step 502: Obtain an instruction from a damaged memory disk in the data storage unit via the server processor's autoprocessor.

Method 500 begins in step 502 with a server processor obtaining an instruction from a host processor for a damaged memory disk in a data storage unit.

In one example, during step 502, the host processor 310 may be configured to transmit command 404 to the server processor 330 (see Figure 4). It should be noted that command 404 is transmitted from the host processor 310 of server unit 302 to the server processor 330 of server unit 302. Upon careful consideration, the host processor 310 may be a given processor within a given host portion of a given server unit, and the server processor 330 may be a BMC of a given (same) server unit.

Command 404 carries an indication of a damaged memory disk 410 in data storage unit 202. It should be noted that the plurality of memory disks in data storage unit 202 (used for performing I/O operations) are grouped into separate groups of memory disks 210. A given memory disk from a given group is associated with a respective location within that group (e.g., the first, second, third, and fourth locations in a group of four memory disks) and has at least one respective visual indicator for displaying the status of a given memory disk. A given group of disk drives is connected to a respective S2PIO device of the visual indicator for monitoring and controlling the respective memory disks in the given group. In one example, a given S2PIO device may be a GPIO expansion device. It is claimed that in some embodiments, visual indicators within a given group of drives may be controlled via their respective S2PIO devices rather than a local BMC (such as the BMC of the respective data storage unit). A given group of drives is also connected to a given host processor of a server unit. In one example, a given group of drives may be connected to a given host processor via one or more SATA bus links. A given S2PIO device is connected to a given server processor of the same server unit. In one example, a given GPIO expansion device may be connected to the BMC of the server unit via a respective I2C link.

Command 404 may carry an instruction. The instruction is, for example, an instruction to one of the first and second links of a given bus interface (such as an I2C bus interface). The target link is connected to one of the target S2PIO devices in data storage unit 202. The target S2PIO device is connected to a target group associated with the damaged memory disk 410 in the memory disk group of data storage unit 202. The instruction also indicates the location of the damaged memory disk 410 within the target group. Once the health disk drive management application 317 acquires and analyzes the health data 402, the host processor 310 can generate command 404. For example, health data 402 can be obtained via a given link from another bus interface (such as a SATA bus interface). Step 504: Transmit a command to the target S2PIO device via the target link using the server processor.

Method 500 continues to step 504 by transmitting a given command from the server processor to the target S2PIO device via the target link. The given command is used to cause the target S2PIO device to actuate a visual indicator associated with the damaged memory disk based on the position of the damaged memory disk in the target group. It should be noted that the target link indication obtained at step 502 can be used by the server processor 330 to determine which link of the given bus interface (e.g., I2C bus interface) should carry the given command, and the indication of the location of the damaged memory disk in the target group obtained at step 502 can be used by the server processor 330 to indicate to the target S2PIO device that received the given command which visual indicator it is connected to should be actuated.

In some embodiments, the target S2PIO can be configured to transmit one of the unique identifiers of the target S2PIO to the server processor 330 via the target link. It should be noted that the unique identifier of the target S2PIO and the location of the damaged memory disk 410 in the target group form a unique identifier for the damaged memory disk 410 in the data storage unit 202. The unique identifier of the damaged memory disk 410 can be used to monitor the detection and/or replacement of the damaged memory disk 410.

It should be noted that server unit 302 and data storage unit 202 are connected via a first bus interface (such as a SATA bus interface) and a second bus interface (such as an I2C bus interface). The SATA bus interface can connect the host processor 310 to the disk drives in the disk drive group, and the I2C bus interface can connect the server processor 330 to an S2PIO device. Upon careful consideration, the plurality of memory disks may include at least one of an HDD and an SSD.

Those skilled in the art will understand the modifications and improvements to the above-described embodiments of this art. The foregoing description is intended to be illustrative and not restrictive. Therefore, the scope of this art is intended to be limited only by the scope of the appended invention claims.

100: System 102: Request Source 103: Communication Network 108: Processing Subsystem 150: Server Rack 180: Request 200: Tray 202: Data Storage Unit 210: Memory Disk 215: Visual Indicator 220: Motherboard 230: Server Processor 250: Bus 300: Schematic Representation 302: Server Unit 303: Host Section 304: First Bus Interface 305: Second Bus Interface 310: Host Processor 311: Link 315: Operating System (OS) 317: Disk Drive Health Management Application 320: Hardware Components 330: Server Processor 341: First Serial AT Attachment (SATA) Link 342: Second Serial AT Attachment (SATA) Link 343: First Inter-Integrated Circuit (I2C) Link 344: Second Inter-Integrated Circuit (I2C) Link 351: Connector 352: Connector 353: Connector 354: Connector 360: First Group 370: Second Group 380: First Serial-to-Parallel Input/Output (S2PIO) Device 385: Link 390: Second Serial-to-Parallel Input/Output (S2PIO) Device 395: Link 402: Health Data 404: Command 406: Command 410: Damage Memory Disc 500: Method 502: Steps 504: Steps

To better understand this technology and its other forms and further features, refer to the following description, which is to be used in conjunction with the accompanying drawings, wherein:

Figure 1 depicts one of the non-limiting embodiments of the present technology.

Figure 2 depicts a left front-view perspective view of a tray containing one of the data storage units of the system in Figure 1.

Figure 3 depicts one of the data storage units of Figure 2, which is connected to one of the server units of the system in Figure 1 via a bus interface.

Figure 4 is a schematic representation of a program in the server unit of Figure 3, which is used to actuate a visual indicator on a memory disk, one of the data storage units.

Figure 5 is a schematic block diagram of one of the methods that can be performed in some embodiments of the present technology.

202: Data Storage Unit

230: Server

300: Indicative representation

302: Server Unit

303: Server Section

304: First bus interface

305: Second Bus Interface

310: Server Processor

311: Chain

315: Operating system (OS)

317: Disk Drive Health Management Application

320: Hardware Components

330: Server

341: First Serial Atomic Attached (SATA) Link

342: Second Serial ATA (SATA) Link

343: First Integrated Circuit (I2C) Link

344: Inter-Integral (I2C) Link

351: Connector

352: Connector

353: Connector

354: Connector

360: Group 1

370: Group Two

380: First Serial-to-Parallel Input/Output (S2PIO) Device

385: Chain

390: Second Serial-to-Parallel Input/Output (S2PIO) Device

395: Chain

Claims (12)

A system for actuating a visual indicator of a damaged memory disk, the system comprising: a server unit including a host processor for generating input/output (I/O) operations and a service processor for monitoring a physical status of the server unit; a first bus interface for transmitting the I/O operations from the host processor to a data storage unit for execution; the data storage unit comprising: a plurality of memory disks for performing the I/O operations, the plurality of memory disks being grouped into a first group and a second group. A given memory disk from a respective group (i) is associated with a respective location within the respective group, and (ii) has a respective visual indicator indicating the status of the given memory disk; a first serial-to-parallel input/output (S2PIO) device connected to the first group for controlling the visual indicators of the respective memory disks from the first group; a second S2PIO device connected to the second group for controlling the visual indicators of the respective memory disks from the second group; and a second bus interface for transmitting commands from the server to the first and second S2PIO devices, the second bus interface including: A first link, located between the server and the first S2PIO device, and a second link, located between the server and the second S2PIO device, wherein the system is configured to: obtain, via the server, an indication from the host processor of a damaged memory disk in the data storage unit, the indication indicating: (i) a target link of the first and second links, the target link being connected to a target S2PIO device of the first and second S2PIO devices, the target S2PIO device being connected to a target group associated with the damaged memory disk in the first and second groups; and (ii) The damaged memory disk is located in one of the target groups; and the server processor uses the target link to transmit a command to the target S2PIO device, the command causing the target S2PIO device to actuate a visual indicator associated with the damaged memory disk based on the location of the damaged memory disk in the target group, wherein the first S2PIO and the second S2PIO have their own unique identifiers, and wherein the system is further configured to: transmit an indication of one of the unique identifiers of the target S2PIO to the server processor via the target S2PIO. The unique identifier of the target S2PIO and the location of the damaged memory disk in the target group form a unique identifier of the damaged memory disk in the data storage unit. As in the system of Request 1, the server processor of the server unit is a baseboard management controller (BMC) of the server unit. The system of request item 1, wherein the first bus interface is a serial AT Attached (SATA) bus interface. The system of claim 1, wherein the second bus interface is an inter-integrated circuit (I2C) bus interface, and wherein the first link is a first I2C link and the second link is a second I2C link. The system in Request 1, wherein the data storage unit is a JBOD unit. The system of claim 1, wherein the plurality of memory disks includes at least one of a hard disk drive (HDD) and a solid-state drive (SSD). The system of Request 1, wherein the S2PIO device is a general purpose I/O (GPIO) expander device. For example, in the system of request item 7, the GPIO expander device is a PCA9995. The system of Request 1, wherein the S2PIO device is a complex programmable logic device (CPLD). The system of Request 1, wherein the S2PIO is a field-programmable gate array (FPGA). A computer implementation method for actuating an indicator of a damaged memory disk, the method being performed by a system comprising: a server unit including a host processor for generating input/output (I/O) operations and a service processor for monitoring the physical status of the server unit; a first bus interface for transmitting the I/O operations from the host processor to a data storage unit for execution; the data storage unit comprising: a plurality of memory disks for performing the I/O operations, the plurality of memory disks being grouped into a first group and a second group. A given memory disk from a respective group (i) is associated with a respective location within the respective group, and (ii) has a respective visual indicator indicating the status of the given memory disk; a first serial-to-parallel input/output (S2PIO) device connected to the first group for controlling the visual indicators of the respective memory disks from the first group; a second S2PIO device connected to the second group for controlling the visual indicators of the respective memory disks from the second group; and a second bus interface for transmitting commands from the server to the first and second S2PIO devices, the second bus interface including: A first link, located between the server and the first S2PIO device, and a second link, located between the server and the second S2PIO device, the method comprising: obtaining, via the server, an indication from the host processor of a damaged memory disk in the data storage unit, the indication indicating: (i) a target link of the first link and the second link, the target link being connected to a target S2PIO device of the first S2PIO device and the second S2PIO device, the target S2PIO device being connected to a target group in the first and second groups associated with the damaged memory disk; and (ii) A location of the damaged memory disk in the target group; The server processor transmits a command to the target S2PIO device via the target link, the command causing the target S2PIO device to actuate a visual indicator associated with the damaged memory disk based on the location of the damaged memory disk in the target group; and The target S2PIO transmits an indication of the unique identifier of the target S2PIO to the server processor, the unique identifier of the target S2PIO and the location of the damaged memory disk in the target group forming a unique identifier of the damaged memory disk in the data storage unit. A system for actuating a visual indicator of a damaged memory disk, the system comprising: a server unit including a processor for generating input/output (I/O) operations and a baseboard management controller (BMC) for monitoring a physical status of the server unit; a bundled disk (JBOD) coupled to the server unit via a SATA bus for receiving the I/O operations from the processor, the JBOD comprising: a plurality of memory disks for performing the I/O operations, the plurality of memory disks being grouped into a first group and a second group. A given memory disk from a respective group (i) is associated with a respective location within that respective group, and (ii) has a respective visual indicator indicating the state of the given memory disk; a first general purpose input/output (GPIO) connected to the first group for controlling the visual indicator of the memory disk from the first group; a second GPIO connected to the second group for controlling the visual indicator of the memory disk from the second group; a first I2C bus connecting the BMC to the first GPIO for transmitting commands from the BMC to the first GPIO; and a second I2C bus connecting the BMC to the second GPIO for transmitting commands to the second GPIO. The system is configured to: The BMC obtains an indication of one of the damaged memory disks in the JBOD from the processor. This indication indicates: (iii) one of the first and second I2C buses, connected to one of the first and second GPIOs, which is connected to a target GPIO associated with the damaged memory disk within the first and second groups; and (iv) the location of the damaged memory disk within the target group; and The BMC uses the target I2C bus to transmit a command to the target GPIO. The command causes the target GPIO to actuate a visual indicator associated with the damaged memory disk based on the location of the damaged memory disk in the target group. The first GPIO and the second GPIO have their own unique identifiers. The system is further configured to: transmit an indication of the unique identifier of the target GPIO to the BMC via the target GPIO. The unique identifier of the target GPIO and the location of the damaged memory disk in the target group form a unique identifier of the damaged memory disk in the JBOD.