WO2008121572A1

WO2008121572A1 - Detecting port configurations

Info

Publication number: WO2008121572A1
Application number: PCT/US2008/057630
Authority: WO
Inventors: David R. French; Matthew Yellen; Steven D. Sardella; Ashok Tamilarasan
Original assignee: Emc Corporation
Priority date: 2007-03-30
Filing date: 2008-03-20
Publication date: 2008-10-09

Abstract

Port configurations are detected. It is detected that a cable has been plugged into a port of a data storage system. The cable has an embedded memory device. Data is read from the embedded memory device. Based on the data, it is determined whether the port is to be configured as a front end port for connecting to at least one host or as a back end port for connecting to data storage equipment.

Description

DETECTING PORT CONFIGURATIONS

BACKGROUND

As is known in the art, large host computers and servers (collectively referred to herein as "host computer/servers") require large capacity data storage systems. These large computer/servers generally include data processors, which perform many operations on data introduced to the host computer/server through peripherals including the data storage system. The results of these operations are output to peripherals, including the storage system.

One type of data storage system is a magnetic disk storage system. Here a bank of disk drives and the host computer/server are coupled together through an interface.

The interface includes "front end" or host computer/server controllers (or directors or storage processors) and "back-end" or disk controllers (or directors). The interface operates the controllers (or directors) in such a way that they are transparent to the host computer/server. That is, data is stored in, and retrieved from, the bank of disk drives in such a way that the host computer/server merely thinks it is operating with its own local disk drive. One such system is described in U.S. Pat. No. 5,206,939, entitled "System and Method for Disk Mapping and Data Retrieval", inventors Moshe Yanai, Natan Vishlitzky, Bruno Alterescu and Daniel Castel, issued Apr. 27, 1993, and assigned to the same assignee as the present invention. Storage Area Network (SAN) and Network Attached Storage (NAS) are conventional data storage technologies. Typically, the SAN technology is a technology for connecting a plurality of storage systems and a plurality of hosts to each other by using a network dedicated for communications between the hosts and the storage systems in order to implement I/O operations having a high speed and a small latency. In accordance with the SAN technology, an I/O operation between a host and a storage system is carried out in block units. A block is a fixed-length data management unit identified by an address. A block is obtained as a result of dividing the capacity of a storage system into smaller portions each having a predetermined size corresponding to the fixed length. A database is a representative of applications for which the I/O operation carried out in block units is suitable. By consolidating a plurality of database volumes into a single storage system so as to allow their management to be executed in a uniform manner, the management cost of the computer system can be reduced. In addition, the SAN technology provides a dedicated network having high reliability and allows communications to be carried out with a high degree of efficiency. Thus, the SAN technology can also be used as a technique providing an effective communication path for transmitting data in volume units. The transmission of data in volume units is carried out to copy a volume to a remote storage system for the purpose of making a backup for the volume and for the purpose of providing a countermeasure to against accidents on the volume.

On the other hand, typically NAS technology is a technique providing a storage system having a file-server function for rendering file services to a plurality of hosts existing in a LAN (Local Area Network). I/O operations between the storage system provided by the NAS technology and the hosts are carried out in file units. In general, a file is identified by using an identifier, which is a character string. A file is a data management unit having a variable length. A representative of applications for which I/O operations carried out in file units are suitable is an application of allowing a plurality of hosts to share a file. By adopting the NAS technology, it is possible to implement a system allowing a plurality of web servers to share a service of the same content and a system allowing a plurality of office PCs to share a text.

A typical data storage system, e.g., a SAN system, is shipped with a fixed number of front-end and backend ports, of a fixed type.

SUMMARY

One or more implementations of the invention may provide one or more of the following advantages.

Users may be provided with enhanced flexibility in frontend and/or backend port assignments and/or configuration. An I/O module may be inserted and removed dynamically (e.g., without rebooting a corresponding storage processor), avoiding significant impact on storage performance. Whenever more ports are needed, new I/O modules may be inserted and configured without compromises required by conventional systems.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features and advantages of the invention will be apparent from the following description of particular embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.

FIG. l is a block diagram of aspect of a data storage system. FIGS. 2-7 are flow diagrams of procedures for use with the data storage system. DETAILED DESCRIPTION

Described below is a technique that provides users with the flexibility to build and configure their data storage systems with only the I/O modules required for their application. It also provides users investment protection by allowing them to upgrade to new I/O technology (e.g., 1OG iSCSI) without requiring a hardware conversion. The online (non-disruptive) dynamic detection and handing of the insertion/removal of I/O modules simplifies future upgrades. In accordance with the technique as described below, a data storage system can detect and handle dynamic insertion and removal of I/O modules and detect the type of I/O module that is inserted. With this approach, the configuration can be changed by the user easily. The user can insert an I/O module as needed and the software dynamically detects the insertion of the I/O module and the type of the I/O module. Conventionally, I/O modules were fixed and could not be removed and inserted easily by the user. In particular, conventionally a storage processor (SP) had to be brought down and the module needed to be cold swapped. An aspect of the technique described herein provides for dynamic detection of

Fibre Channel (FC) front end (FE) and back end (BE) port configurations on a data storage system. The technique provides users the flexibility to assign ports on an FC I/O module to either the front end to support more host connections or to the back end for more storage capacity. Accordingly, the user can reduce or minimize the number of FC I/O modules required to customize the system for the user's application. A port on an FC I/O module remains unassigned and unconfigured until a Small Form-factor Pluggable (SFP) device is inserted into the port. The system software automatically determines the type of connectivity based on the information stored in the resume PROM on the optical or copper SFP connector. (In at least one implementation, resume PROMs in the I/O module and SFP connector have electrical power even if the I/O module is not yet powered up, so that the SPs can read the resume PROMs before the I/O module is powered up.) If an optical SFP is inserted into an open FC I/O port, the port is assigned to the front end and enabled for host connectivity. If a copper SFP is inserted into the port, the port is configured as a back end loop. (Signal performance settings may be affected by the determination as well, as described in U.S. patent application serial no. 11/394,698, filed March 31, 2006, entitled MANAGING COMMUNICATIONS SETTINGS, attorney docket no. EMC-06-028, which is assigned to the same assignee as the present invention, and which is hereby incorporated herein by reference.)

Referring now to FIG. 1 , for example, the technique may used in or with a data storage system 10. The data storage system 10 includes a plurality of, here for example, two chassis or enclosures 14, 16 as shown. Enclosure 14 is sometimes referred to herein as a Disk Processor Enclosure (DPE) and enclosure 16 is sometimes referred to herein as a Disk Array Enclosure (DAE). DPE 14 has slots in which DPE 14 includes I/O modules 18a, 18b, 18c, 18d having respective SFP ports 520a, 520b, 520c, 52Od that may be coupled to the pair of host computer/servers or to the DAE 16 as described below. The DPE 14 also includes a pair of storage processors 20a (SPA), 20b (SPB) coupled to each other with storage processor 20a being connected to I/O modules 18a, 18c and storage processor 20b being connected to I/O modules 18b, 18d as shown. The storage processors 20a, 20b of DPE 14 may be coupled by a pair of FE cables 505a, 505b to a respective pair of host computer/servers (not shown), and may be connected to the DAE 16 through a pair of BE cables 130a, 130b, respectively, as shown.

Each I/O module and cable SFP connector may have respective non-volatile memories herein referred to as resume PROMs. The basic functionality of the resume PROM is described in co-pending U.S. patent application serial no. 10/330,806, entitled "A Method and Apparatus for Preserving Data in a High Availability System", to Sardella et al. (hereinafter "806 application"), which is assigned to the same assignee as the present application, and which is incorporated in its entirety herein by reference. As described in the 806 application, each resume PROM has various fields that are useful for system management. The resume PROM, accessed over I2C for example, has clear contents describing what the module or SFP is supposed to be.

One or both SPs may run software as described below, including system software, software drivers, and software modules.

In general, the data storage system has a flexible I/O FE/BE port technique. This technique supports user pluggable FC and iSCSI I/O modules, and allows a user to select which FC ports are FE and BE during initial configuration, e.g., by supporting auto-detection of optical and copper SFPs as noted above and described below. FE and BE ports are then marked and/or indicated, e.g., for usability and/or diagnosability. Undefined FC ports can be added dynamically as BE or FE ports. In accordance with the technique, the data storage system has physical ports and virtual FE and BE ports. A physical port refers to a hardware slot and location in the data storage system. Each physical port has a type (e.g., FC or iSCSI port) associated with it. A virtual port maps to a physical slot and port location. In at least one implementation, there can only be one virtual BE 0 port (VBEO), and it must be mapped to physical slot 0, port 0. User interface based management software reports associations between physical and virtual FE/BE ports. In at least one implementation, cables are labeled to indicate slot/port information, I/O modules are labeled with port numbers, and chassis are labeled with slot numbers. Software controlled port identification may be provided, so that user interface based management software allows the user to flash an LED corresponding to an I/O port. In one or more implementations, VBEO references a fixed physical slot and port location, e.g., slot 0, port 0, and/or SPA & SPB have symmetrical I/O module and

FE/BE port configurations.

With respect to automatic determination of I/O ports, on initial power-up power on self test software (POST) verifies that I/O modules are functional, and in a discovery process system software determines from one of the SPs whether the system is running in a SAN or NAS configuration. IfNAS, ports with SFP to SFP cables are assigned to FE.

If SAN, iSCSI ports are defined as FE ports, and FC ports are defined as FE or

BE ports. In particular, if an optical SFP is detected, the port is defined as an FE port, and if a copper SFP is detected, the port is defined as a BE port. FC ports without optical or copper SFPs are defined as "unknown".

In at least one implementation, port numbering is based on order found in the discovery process, and it is determined whether SPA and SPB have identical I/O modules in the same slot location. (In at least some implementations, symmetry between SPA and SPB with respect to I/O modules and ports is not required technically but is imposed to allow the user to self-determine, in at least cases, whether setup is correct, e.g., by visually checking for symmetry.) The port configuration may be saved with an explicit command in user interface based management software. The highest physical FC and iSCSI FE ports discovered may be assigned as replication software ports and saved (if additional FE ports or I/O modules are added, the replication software ports remain fixed). Ports configurations may be persistent through power failures, reboots, hardware failures, I/O module repairs, and/or non-disruptively adding SFPs or I/O modules.

With respect to non-disruptive expansion, in which new I/O modules are added into empty slots of both SPs (must be the same type of I/O module), each SP requires reboot (one at a time to avoid data unavailability). New I/O modules are recognized and appropriate port mappings are assigned if SFPs are inserted. Existing port assignments and mapping do not change, and replication software port assignment does not change

In at least one implementation, with respect to I/O module change (to a new I/O type), in which an I/O module is replaced with a different type of I/O module (e.g., an FC I/O module is replaced with an iSCSI I/O module), the new I/O module is faulted. In other implementations, a procedure is executed to force new physical to virtual port mapping and cleanup stale configuration data; this is not a normal upgrade path, but is used only for recovery. Another supported procedure to enable the changed module may be a full configuration wipe (including destructive reimaging and restoring the factory state).

Automatic expansion online is handled. With respect to adding SFPs to an existing FC I/O module, a user interface based management software wizard guides users through following steps. It is requested that the same type of SFP be inserted into the same open (unknown) port on both SPs. System software reports the inserted SFPs to the wizard. User interface based management software checks for symmetrical I/O port configurations, issues a command to persist the new port configuration, and issues a coordinated reboot of the SPs. A port mapping database is updated, and the ports are enabled.

With respect to adding any type of I/O module to an open slot (not a conversion), another user interface based management software wizard guides users through following steps. It is requested that the same type of SFP be inserted into the same open (unknown) port on both SPs. User interface based management software checks for symmetrical I/O module configurations, issues a command to persist the new port configuration, and issues a coordinated reboot of the SPs. POST checks the I/O modules.

Thus, detection of intended port configurations is enhanced. In conventional systems, the back end and front end are in fixed locations and do not change, and the port numbers assigned to each of the ports also do not change. Generally, in accordance with the technique described herein, the FE and BE ports are configured based on the I/O modules and SFPs that are connected. Thus, FE ports and BE ports are not generally fixed, i.e., any port or nearly any port can be assigned to be an FE or BE port. (In at least one implementation, back end 0 (BEO) is in a known fixed location.) As noted above, the port numbers are assigned by system software, and the port number and port type are initialized based on the type of cable that is plugged in. In particular, software controls how a port is determined to be FE or BE, and assigns a corresponding port number. In particular, a system software environmental management module (EM) supports flexible I/O ports, and receives support from other modules. EM sets up the port number and port type, intercommunicates with an FC driver (DMD) (e.g., dual mode driver from EMC Corporation of Hopkinton, Massachusetts) and provides information to user interface based management software about the ports. Thus, system software is responsible for determining a particular port to be FE or BE and also for assigning a logical port number. Once a part is configured this data is persisted so that the SP does not change the port number on each boot. This data is as important as volume (LUN) and other configuration information, and losing the port information could lead to data unavailability (DU)/data loss (DL). In at least one implementation, the information is stored in the database which protected, e.g., by data replication.

A miniport driver initializes the hardware I/O ports. System software, which determines the port type and port number, starts after the miniport driver; therefore, to communicate the information to the miniport driver, the system writes the settings to DMD registry entries and reboots the SP. On the next boot, DMD reads the registry and initializes the port according to the registry settings. The software depends on the following drivers and software modules to provide support to handle flexible I/O modules/ports. DMD notifies system software on SFP events for all ports (FE and BE). DMD takes the ports offline if incorrect SFP cables or I/O modules are plugged in. A general purpose operating system (OS) environmental monitor (OSEM) provides information about the status of an I/O module (e.g., insertion status, power status, type) and provides notification of any state change on the I/O module. An NT back end driver (NTBE) is the interface between configuration manager software (CM) and DMD. This layer hides all the OS specific details from CM and converts commands from CM to OS calls to be issued to DMD. This layer also accepts unsolicited messages from DMD and packages them for CM. On boot up NTBE sees all the devices exported by DMD and issues an input/output control request (IOCTL) to read the port configuration information. Conventionally, NTBE saves information about the device objects for a particular port only if it is a BE port based on the data returned from a CPD IOCTL GET CONFIG INFO IOCTL. Also conventionally, NTBE stores the system software bus (e.g., PCI Express bus) to port mapping, CM issues commands on a bus number basis, and NTBE converts the bus number to actual device objects and issues the command. In contrast, in accordance with the technique described herein, CM relies on the SFP information and is notified about SFP events for all ports (i.e., FE, BE, and uncommitted ports). Thus, in accordance with the technique described herein, NTBE and CM communicate in terms of port number instead of bus number. When CM needs to send events to BE bus, it converts them to the appropriate port number and sends them to NTBE which then re-formats them and forwards the commands to DMD. The software also depends on particular data structures including the following. IOM_TYPE defines all the possible I/O module types, such as FC I/O module, iSCSI I/O module, and SAS I/O module. PORTJlOLE all the possible roles the port can take, such as FE and BE. PORT_SUBROLE defines the sub-role the port can take, such as replication software port. IOMJPORTJSTATE defines the possible states for the I/O module and ports in the I/O module. A default state is indicated by

IOMJ^>ORT_STATEJJNiNITIALIZED = 0. IOM JPORT_STATE JJNKNO WN is applicable only for the ports, to handle the case in which the I/O module is powered down and it is not known what is plugged in. A state IOM_PORT_STATE_EMPTY indicates that nothing is plugged in and the port is un-initialized. A state IOM_PORT_STATE_MISSING indicates that nothing is plugged in but the port is initialized. With respect to states IOM_PORT_STATE_ENABLED, IOM_PORT_STATE_F AULTED, everything is fine with the I/O module.

PORT_SUBSTATE provides extra information about the port state, specifically, when the state is IOM_PORT_STATE_F AULTED. Substates include PORT_SUBSTATE JJNINITI ALIZED, PORT_SUBSTATE_GOOD, and the following. A substate PORT_SUBSTATE JNCORRECT_SFP JLYPE indicates that the port was initialized but an incorrect SFP was inserted that does not match the persisted information. PORT_SUBSTATE JNCORRECT JOM indicates that the port was initialized but an incorrect I/O module is inserted and thereby the port will also be incorrect. PORT_SUBSTATE _MISSING_SFP indicates that the port was initialized but an SFP is not plugged in. PORT_SUBSTATE _MISSINGJ0M indicates that the port was initialized but an I/O module is not present.

PORT_SUBSTATE JOM_NOT_PRESENT indicates that the port is uninitialized and an I/O module is not inserted. PORT_SUBSTATE J0M_READ_ERR0R indicates that an I/O module had a resume PROM read error and so the port is also faulted. PORT_^SUB STATE_SFP_NOT_PRESENT indicates that the port is uninitialized, but an SFP is not inserted. PORT_SUBSTATE

_EXCEEDED JVlAX JLIMITS indicates that the number of ports exceeded the allowed limits. PORT_SUBSTATE_SFPJIEAD_ERROR indicates that the SFP information could not be read. PORT_^SUBSTATE JOM JOWERED J)FF indicates that the I/O module is powered off. PORT_SUBSTATE_PORT_NOT_PRESENT indicates that the port is not present in the module. In at least one implementation, the maximum number of ports per I/O module is defined as four but an iSCSI I/O module has only two ports, so PORT_SUBSTATE_PORT_NOT_PRESENT is used for the two ports that do not exist. I0M_SUB STATE gives extra information about the I/O module substate, specifically, when the state is IOM_PORT_STATE_F AULTED. IOM_SUBSTATE_NOT_PRESENT indicates that the I/O module is not present. IOM_SUBSTATE PROM READ ERROR indicates that there was an error reading the resume PROM on the I/O module. IOM_SUBSTATE JNCORRECTJOM indicates that at least one of the ports was initialized in this I/O module but a wrong I/O module was plugged in. Other indicators include IOM_SUBSTATE _GOOD and IOM_SUBSTATE _NOT_PRESENT. IOM_SUBSTATE_POWERUP_F AILED indicates that an attempt to power up the I/O module was made but it failed. I0M_SUB STATE_PO WEREDJ)FF indicates a case in which the I/O module was inserted when the SP was up and running and it will be in a powered off state.

PORT_PROTOCOL is used so that the port protocol information is persisted in the database in case the user removes an I/O module with ports configured as FC

FE and replaces it with iSCSI module. In some implementations IOM_TYPE may be used, but PORTJPROTOCOL is appropriate in the case a combination I/O module is used that can support multiple protocols. P0RT_PR0T0C0L_UNKN0WN = 0, PORT PROTOCOL FC, PORT PROTOCOL ISCSI, PORT PROTOCOL SAS indicate unknown protocol, FC, iSCSI, and SAS, respectively.

I0M_P0WER defines the power status of the I/O module, e.g., indicated by I0M_P0WER_0N or IOMJPOWER_OFF. I0M_P0WERJJNA VAILABLE indicates that the power status is unavailable. This is the default setting if the I/O module is not inserted. If an attempt was made to power up the I/O module but it failed, IOM_POWER_POWERUP_FAILED is indicated. A basic boot-up sequence is now described.

With reference to FIG. 2, a pipe is opened to diplex threads for BE O and OS (step 2010). In at least some implementations, pipes include TCP/IP connections in which particular ports are bound. Diplexing is described in United States Patent No. 5,901,151 to Bleiweiss, et al. entitled "System for orthogonal signal multiplexing", which is hereby incorporated herein by reference in its entirety.

NTBE registers callbacks for all the ports DMD exposes (step 2020). For each of the ports exposed, NTBE issues

CPD JOCTL GET HARD WARE INFO to build a table that converts a PCI device to the physical port number for the particular device object (step 2030). This is performed so that system software can determine a physical port from which an event is coming. Information is gathered about the I/O modules that are currently inserted on the SP (step 2040).

Once details about the I/O module type are known, for each port in an FC I/O module only, CM sends an IOCTL to NTBE to register a callback to notify for any unsolicited events NTBE receives from DMD and needs to inform CM about (step 2050).

For each of the FC ports (determined based on information gathered above), an IOCTL is issued to DMD to get the SFP information/status (step 2060).

At this point, the Bus number to Port number mapping is known only for Bus 0 which is on Port 0.

If Bus 0 speed is not configured, the peer SP is rebooted (step 2070).

Poll commands are issued to only Bus 0 through Port 0 pipe (step 2080).

The poll command is processed and the enclosures are added (step 2090).

A discovery command is issued to DMD to discover all the devices on Bus 0 (step 2100).

Database information is read (step 2105).

At this point, all the information needed for I/O port mapping and handling is present: I/O module information, SFP information and persistent data about the port information. A registry entry is read that indicates whether the port settings need to be persisted (step 2110).

All the instance parameters in the registries are read to determine whether there are any uncommitted ports (step 2120).

In the case of the first boot-up of a new storage system (or, equivalently, a destructive re-installation of the system software), after the basic boot-up sequence is executed, the following sequence is executed.

Since this is a brand new array (or its equivalent) and registry settings indicate the port settings need to be persisted, the port information is uninitialized and system software should assign port numbers based on the SFPs plugged in (step 2130). For each I/O module that is inserted and powered up, if the I/O module is iSCSI, ports are assigned to be FE and the logical port number is set to be the next available port number for this type (step 2140). If the I/O module is FC, the port is assigned to be FE or BE based on the SFP that is plugged in for this port, and the next available logical number is assigned based on the type for this port (step 2150).

At this point, a completion portion of the sequence is executed, as follows. If there is at least one FE port, the highest numbered FE port is assigned to be the replication software port (step 2160).

System configuration information with the updated port information is written to the database (step 2170).

For each port that is configured, the instance parameter registry entries are updated with the port information (step 2180). The registry entry that indicates the port information needs to persist is cleared

(step 2190).

The registry entry is flushed, and if the peer SP was told to hold in reset, the peer SP is reset and this SP is rebooted (step 2200).

When the peer SP boots up, the database is already initialized, and the peer SP executes in accordance with a non-disruptive re-imaging sequence described below.

When the SP boots up, it executes the basic boot-up sequence and continues to boot.

With respect to non-disruptive re-imaging, after the basic boot-up sequence is executed, the following sequence is executed. In this case, the database information, is present, but the DMD registry settings have been wiped out.

For each I/O module that is present and powered up: (1) For each uncommitted port, it is determined by reading an instance parameter registry entry whether this port is initialized in the database; if so, it is written to the registry, and (2) if the registry and database are not uninitialized for this port and the persistent bit is set in the registry, the following steps are executed.

If this is an iSCSI module, the ports are assigned to be FE and the logical port number is set to be the next available port number for this type. If the I/O module is FC, the port is assigned to be FE or BE based on SFP that is plugged in for this port, and the next available logical number is assigned based on the type for this port. The sequence concludes with the same completion portion described above.

With respect to handling the addition of SFPs, the system performs as follows. With respect to FIG. 3, in the case of adding an SFP to an uninitialized port during run time (step 3010), the following sequence is executed. DMD notifies NTBE using the call back function registered during bootup for the particular port (step 3020). NTBE sends an unsolicited message to CM for the port number which had the SFP inserted (step 3030). CM handles the event and logs a message about the SFP being inserted, indicating the port number and SFP type in the extended status of the message (step 3040). CM updates the local data structure about the new SFP that was inserted (step 3050).

With respect to FIG. 4, in the case of adding an SFP to an uninitialized port when an SP is down (step 4010), the following sequence is executed. When the SP boots up, it goes through the basic boot-up sequence (step 4020). If the registry setting is set to persist the information, the system executes much as the first boot-up of a new storage system (step 4030). If the peer SP is running, it is necessary to inform the peer SP about the port assignment, and the database updates are coordinated with the peer SP (step 4040). With respect to FIG. 5, in the case of adding an SFP to an initialized port during run time (step 5010), the following sequence is executed. DMD notifies NTBE using the call back function registered during bootup for the particular port (step 5020). NTBE sends an unsolicited message to CM for the port number which had the SFP inserted (step 5030). CM handles the event and logs a message to the ULOG about the SFP being inserted, indicating the port number and the SFP type in the extended status of the message (step 5040). CM updates the local data structure about the new SFP that was inserted.

In the case of adding an SFP to an initialized port when an SP is down, the basic boot up sequence is executed and then a boot-up follow through sequence, described below, is executed.

With respect to handling the removal of SFPs, the system performs as follows. In the case of removing an SFP from an uninitialized port during run time, the system executes the sequence described above for the case of adding an SFP to an uninitialized port during run time. In the case of removing an SFP from an initialized port during run time, the system executes the sequence described above for the case of adding an SFP to an uninitialized port during run time. If this port is a BE port, this case is handled the same way as cable removal is done conventionally. Also, in the case of removing an SFP from an initialized port when an SP is down, if this port is a BE port, this case is handled the same way as cable removal is done conventionally.

With reference to FIG. 6, with respect to handling the addition of I/O modules, the system performs as follows (step 6010). In the case of addition during run time, the OS EM detects the I/O module being inserted (step 6020). Since the I/O module is powered down, not much processing is being done. The resume PROM information is read to determine the I/O module type (step 6030).

With reference to FIG. 7, in the case of addition when an SP is down, after the basic boot up sequence is complete, the registry is checked to determine whether the port information needs to persist (step 7010). If the port information needs to be persisted, it is determined whether the I/O module is an FC module (step 7020). If so, it is determined whether there are any SFPs inserted or whether this is an iSCSI module (step 7030). If at least one SFP is inserted, one or more appropriate procedures described above are executed (step 7040).

With respect to handling the removal of I/O modules, the system performs as follows. In the case of removal during run time, if an I/O module is removed and it was not powered up at that time, no special handling is needed. Since the I/O module is powered down, the port would have been inaccessible and would have been handled the same as in the event the port was not present at boot up. If an I/O module is removed and it was powered up at the time, the SPs reboot immediately.

The boot-up follow through sequence, now described, may be executed by an SP once all of the above cases have been handled if necessary. Based on the database information, the pipes to the diplex thread are opened for the appropriate port number. For all backend buses, it is determined whether the port is physically present, a poll command is issued to that particular pipe, and the new enclosures found through the existing code are added.

For all the backend ports that exist, a discovery command is issued to DMD asking it discover all the devices. Further processing is executed, including conventional processing and optionally a datarate change process. The registry entry that indicates the port information needs to persist is cleared. Fault LEDs on the port and I/O module are turned on. In at least some implementations, other contents of the resume PROM may be used to help distinguish back end from front end connections.

In addition to FC and iSCSI I/O modules, other types of I/O modules may be treated accordingly, such as SAS modules. As can be seen from the description above, it is possible for a newly added I/O module to be brought up to full functional use fully automatically after insertion, i.e., without further interaction by the user, by automatic procedures including rebooting the SPs one at a time while the data storage system maintains continuous availability of data to the hosts. However, in at least some implementations, it may be advantageous to impose user interaction, e.g., for validation against business or licensing requirements. For example, a lower end system may have a limit on the number of ports, e.g., so that the cost of the system is scaled correctly to the amount of service expected.

Also, since I/O modules are not powered up immediately upon insertion but are powered up in a graceful way through rebooting the SPs, the process has many of the advantages of a non disruptive upgrade.

While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.

Claims

CLAIMSWhat is claimed is:

1. A method for use in detecting port configurations, the method comprising: detecting that a cable has been plugged into a port of a data storage system, the cable having an embedded memory device; reading data from the embedded memory device; based on the data, determining whether the port is to be configured as a front end port for connecting to at least one host or as a back end port for connecting to data storage equipment.

2. The method of claim 1, further comprising: leaving the port unassigned until the cable has been plugged into the port.

3. The method of claim 1, further comprising: providing standby electrical power to the embedded memory device.

4. The method of claim 1, farther comprising: based on the determination, marking the port.

5. The method of claim 1, further comprising: mapping the port to a virtual port.

6. A system for use in detecting port configurations, the system comprising: first logic detecting that a cable has been plugged into a port of a data storage system, the cable having an embedded memory device; second logic reading data from the embedded memory device; third logic determining, based on the data, whether the port is to be configured as a front end port for connecting to at least one host or as a back end port for connecting to data storage equipment.

7. The system of claim 8, further comprising: fourth logic leaving the port unassigned until the cable has been plugged into the port.

8. The system of claim 8, further comprising: fourth logic providing standby electrical power to the embedded memory device.

9. The system of claim 8, further comprising: fourth logic marking the port based on the determination.

10. The system of claim 8, further comprising: fourth logic mapping the port to a virtual port.