Browse Prior Art Database

Blade Serverblade USB Storage Solution

IP.com Disclosure Number: IPCOM000019258D
Original Publication Date: 2003-Sep-08
Included in the Prior Art Database: 2003-Sep-08
Document File: 4 page(s) / 57K

Publishing Venue

IBM

Abstract

The Serverblade design has a problem in trying to share storage between different server blades. The individual blades have the capability of storing data individually, but there is no way of sharing this data between the blades unless it is across some sort of network. Sharing it across the internal network is one option, but this requires setting up network access and configure users/permissions on this data. Plus it also creates problems with who is the server of the data and such. This makes for a messy solution. Having external storage is also an option, but this requires an extra server to maintain and control the data. This is do-able, but costly and there is the network performance to consider when accessing the server. This invention is meant to describe a mechanism for attaching drive(s) to the Serverblade design such that all machines have direct access to the data on the drive (no network server required) and such that all machines can share data on the drives.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 4

Blade Serverblade USB Storage Solution

       This invention utilizes the USB controllers that are already part of the individual blades. Since the design of the Serverblade entity does not readily allow for user attached hot-swap devices, these USB hosts are not currently in use. USB attachable hard drives are already common knowledge. This invention details how to share a USB drive across several machines, such that it performs like a directly-attached drive, but can be shared without the performance loss of going through a server.

     **Note that USB could just as easily be replaced by Firewire. Figure 1 gives an overview of the idea. The individual blades are at the top of the design. This design could work with any number of blades, but the complexity of the design grows in direct proportion to the number of blades. Each blade is assumed to have an on-board (or on-blade) controller that is USB 2.0 compliant. This provides the best performance and the best arbitration for the next stage of the design. The next stage is a single microcontroller solution that has many sub-parts. The purpose of this microcontroller is to handle the incoming requests from the USB buses and arbitrate between them on access to the disk array.

     The complexity of this design resides in the microcontroller. The microcontroller has N number of USB slave attachments (one for each blade), a SCSI controller for accessing the SCSI array (this could be a ServeRAID style controller), cache for storing requests to the drives and an embedded processor for handling all of the above. There may even be a firmware option for allowing the processor to have code updates available. This Multi-Master Unit will reside on the backplane of the Serverblade and

1

[This page contains 3 pictures or other non-text objects]

Page 2 of 4

provide a connection to an SCSI storage array. (This storage array could occupy a slot of the BladeCenter or attach to the chassis by other means.)

     To each blade the unit looks like an external attached drive, but the microcontroller handles the requests...