Obtaining configuration information from host devices which store data into and load data from a data storage array

[0001] A typical data storage array includes one or more storage processors and an assembly of disk drives. During operation, each storage processor stores data into and loads data from the disk drive assembly on behalf of one or more external host (or server) devices.

[0002] One conventional data storage array offers a management utility which enables an administrator to monitor and control various aspects of the data storage array. The management utility includes a lower-level object manager which communicates with array software that maintains a database of Initiator records, i.e., records representing all of the physical connections between SCSI (small computer system interface) devices and ports of the data storage array. The management utility further includes a provider module which operates as a front-end to the lower-level object manager.

[0003] During operation, the provider module periodically obtains an identification of all of the physical connections from the lower-level object manager which retrieves this information from the database of Initiator records. Upon receipt of such identification, the provider module polls all of the physical connections leading to all of the external host devices for current configuration information. In response to such polling, all of the external host devices provide their current configuration information back to the data storage array. The provider module then is able to determine whether any of the external host devices have made a configuration change to a physical connection based on a comparison between the current configuration information and earlier-received configuration information from the external host devices. For example, a particular external host device may have effectuated a LUN (logical unit number) mapping change since the last time the provider module polled that external host device.

[0004] The provider module displays any detected configuration changes to the administrator (i.e., on a computer display). A product which operates in a manner similar to that described above is a utility of the Navisphere® Management Suite which is provided by EMC Corporation of Hopkinton, Mass.

[0005] The above-described conventional management utility provides a thorough and comprehensive approach to acquiring configuration information from the external host devices, and may be well-suited for a variety of conventional situations. However, some data storage array customers may wish to scale the number of external host devices to significantly high numbers (e.g., hundreds or even thousands of external host devices). Unfortunately, as the number of external host devices increases, the burden of periodically polling all of the external host devices for configuration information increases significantly.

[0006] Moreover, if the conventional management utility is almost at full capacity, it may not be possible to add more external host devices as well as concurrently maintain the same polling interval. That is, in situations in which there are already an excessively large number of external host devices relative to existing processing power limitations, it may be difficult or impossible for the management utility to finish polling all of the external host devices in a targeted amount of time (e.g., one minute, five minutes, etc.). Unfortunately, the only convenient solution in such situations may be to increase the polling period for polling all of the external host devices and risk missing timely detection and reporting of a configuration change.

[0007] In contrast to the above-described conventional polling approach which involves polling all physical connections and receiving current configuration information from all of the external host devices at periodic intervals, an improved technique is directed to polling only hosts which have undergone a configuration change. Such a ‘smart polling’ technique alleviates the need to periodically poll all hosts some of which have not undergone a configuration change. Rather, each poll of a host which has undergone a configuration change is efficient in the sense that it retrieves meaningful information which includes some changed information. Moreover, the improved technique scales well in the sense that additional hosts do not necessarily increase the polling burden. To the contrary, the polling burden is affected by the frequency of undergoing configuration changes. As a result, particular polling interval targets/goals that are set by a user in order to minimize time to detect configuration changes (e.g., completing a poll of only hosts with configuration changes in one minute, five minutes, etc.) are easily achievable.

[0008] One embodiment is directed to a technique of obtaining configuration change information from host devices which are constructed and arranged to store data into and load data from the data storage array. The technique involves receiving a set of change notices from a set of host devices. Each change notice is received by electronic circuitry of the data storage array when a respective host device of the set of host devices undergoes a configuration change. The technique further involves providing a set of requests from the electronic circuitry of the data storage array to the set of host devices based on the set of change notices. The technique further involves acquiring configuration change information from the set of host devices in response to the set of requests. Such a ‘smart polling’ technique alleviates the need to communicate with all of the host devices. Rather, the electronic circuitry needs to communicate only with the set of host devices (i.e., one or more host devices which have recently undergone a configuration change). Accordingly, the polling burden on the electronic circuitry is significantly less than a conventional polling approach which involves polling all external host devices.

[0015] Improved techniques are directed to polling only host devices which have undergone a configuration change. Such techniques alleviate the need to periodically poll all host devices some of which have not undergone a configuration change. That is, each poll is efficient in the sense that it retrieves meaningful information which includes some changed information. Furthermore, such techniques scale well in the sense that additional external host devices do not necessarily increase the polling burden. Rather, the polling burden is affected by the frequency of undergoing configuration changes. Accordingly, particular polling interval targets/goals (e.g., completing a poll of changed host devices in one minute) are more easily achievable.

[0016] FIG. 1 shows a data storage environment 20 in which there is polling of only host devices which have undergone a configuration change. The data storage environment 20 includes a data storage array 22, host devices 24(1), 24(2), 24(3), . . . (collectively, host devices 24) and a communications fabric 26 which enables the data storage array 22 and the host devices 24 to communicate electronically. Such an environment 20 is able to take the form of a SAN (storage area network), LAN (local area network), or combination thereof.

[0017] Although the communications fabric 26 shows individual point-to-point pathways 28 between the data storage array 22 and the host devices 24, it should be understood that a variety of communications media are suitable for use (e.g., copper, fiber optic, wireless, combinations thereof, etc.). Additionally, as illustrated by the cloud 30, a variety of alternative topologies (e.g., nodal, hub and spoke, ring, irregular hops, combinations thereof, etc.) and communications protocols (TCP/IP, block-based, etc.) are suitable for use as well.

[0018] Each host device 24 includes multiple host bus adapters (HBAs) 32 which connect that host device 24 to the data storage array 22 through the communications fabric 26. Examples of suitable HBAs 32 include SCSI, Fibre Channel, eSATA, IDE, Ethernet, FireWire, and USB devices among others.

[0019] Each host device 24 further includes a respective host agent 34 which is constructed an arranged to provide configuration information to the data storage array 22. As will be explained in further detail shortly, the configuration information provided by the host agents 34 (e.g., see host agents 34(1), 34(2), 34(3), . . . ) is maintained by the data storage array 22 during array operation.

[0020] By way of example only, the data storage environment 20 further includes an I/O device 36 which provides management access to a user. The I/O device (or subassembly) 36 serves as a data storage system management interface that enables a user to control the data storage environment 20. In some arrangements, the I/O device 36 connects directly to the data storage array 22 (e.g., as a console). In other arrangements, the I/O device 36 connects to the data storage array 22 through the communications fabric 26. As yet another alternative, the user utilizes a user interface on one of the host devices 24 as the I/O device 36.

[0021] The data storage array 22 includes a storage subassembly 42, a storage processing component 44, a host interface 46, an upper layer component 48 and an admin layer component 50. The storage processing component 44 (e.g., electronic circuitry operating as one or more storage processors) is constructed and arranged to process data storage and retrieval requests 54 from the host devices 24. The storage subassembly 42 is constructed and arranged to store host data 56 on behalf of the host devices 24 in a non-volatile manner.

[0022] The host interface 46 is configured to provide access to the data storage array 22 from external locations (from the host devices 24, from the I/O device 36, etc.). Along these lines, the host interface 46 includes multiple ports 62(1), 62(2), 62(3), 62(4), . . . (collectively, ports 62) which are constructed and arranged to connect with the communications fabric 26. In particular, each port 62 is capable of communicating with one or more host devices 24. For example, port 62(1) communicates with multiple HBAs 32 of each host device 24(1), 24(2) through respective communications pathways 28 of the fabric 26. Similarly, port 62(2) communicates with multiple HBAs 32 of each host device 24(1) and 24(2). Accordingly, the data storage array 22 is able to provide high availability, e.g., load balancing and fault tolerant redundancy.

[0023] In some arrangements, the upper layer component 48 and the admin layer component 50 are formed by one or more specialized applications running on the same electronic circuitry that carries out the data storage operations for the array 22, i.e., the components 48, 50 run on the same processors that form the storage processing component 44. In other arrangements, the upper layer component 48 and the admin layer component 50 reside on electronic circuitry which is separate from the storage processing circuitry.

[0024] As further shown in FIG. 1, the admin layer component 50 includes a specialized admin engine 72 (e.g., a back-end object manager module, a lower-level object manager in combination with the array software, etc.) and a database 74 of records 76. The admin engine 72 is constructed and arranged to maintain the database 74 of records 76 so that the records 76 accurately represent particular operating aspects of the data storage array 22, e.g., physical connections between particular ports 62 of the data storage array 22 and the HBA devices 32 of the host devices 24. The upper layer component 48 is constructed and arranged to access to the admin layer component 50 as well as provide a graphical user interface (GUI) to a user through the I/O device 36.

[0025] Particular operating details will now be provided with reference to FIG. 1. During operation, the storage processing component 44 carries out data storage and retrieval requests 54 on behalf of the host devices 24. Such requests 54 preferably include standard load and store operations (e.g., READ, WRITE, READ-MODIFY-WRITE, etc.).

[0026] Furthermore, when a new host device 24 is added to the environment 20 and occasionally when an existing host device 24 undergoes a configuration change, the host agent 34 running on that host device 24 sends a change notice message 82 to the data storage array 22. Preferably, the change notice message 82 resides in a standard communication between that host device 24 and the array 22, i.e., in a manner which leverages existing standard in-band communication protocols thus alleviating the need to introduce a new proprietary format. The data storage array 22 (either the admin engine 72 or the array software) receives the change notice message 82 and modifies a particular database record 76 corresponding to a physical connection 28 to that host device 24.

[0027] During a particular polling time interval (e.g., one minute, five minutes, etc.), the data storage array 22 may receive other change notice messages 82 from the same host device 24 or perhaps different host devices 24 in response to other configuration changes. In response to each change notice message 82, the data storage array 22 makes an appropriate modification to its database 74.

[0028] At the end of the polling time interval, the upper layer component 48 asks the admin layer component 50 to identify which host devices 24 have recently undergone a configuration change. The admin engine 72 identifies these host devices 24 to the upper layer component 48 by accessing the database 74. The upper layer component 48 then sends requests 84 for configuration information only to those host devices 24 through the host interface 46. That is, the upper layer component 48 ‘polls’ only the host devices 24 which have undergone a configuration change.

[0029] When a host device 24 receives a request 84 for configuration information, the host agent 34 of that host device 24 responds to the request 84 with its current configuration information 86. The upper layer component 48 receives the configuration information 86 and stores the configuration information 86 in memory 88 in a persistent manner. The upper layer component 48 also makes the newly received configuration information 86 available to the user through the I/O device 36.

[0030] This process continues in an ongoing manner (e.g., each minute) so that the data storage array 22 remains apprised of configuration changes in the data storage environment 20. Since the upper layer component 48 only polls the host devices 24 which have undergone a configuration change, there are likely only a few requests 84 and responses 86 to be processed since host devices 24 typically do not make configuration modifications very often. Accordingly, there is a comparatively lighter polling burden vis-à-vis conventional polling approaches which poll all external host devices regardless of whether a host has undergone a configuration change. Further details will now be provided with reference to FIG. 2.

[0031] FIG. 2 is a block diagram which illustrates a process for updating the database 74 of records 76. As shown in FIG. 2, when a host device 24 undergoes a configuration change, the host agent 34 running on the host device 24 sends a communication 100 containing a framed block of host data 102 to the data storage array 22 (also see the change notice message 82 of FIG. 1). A suitable format for this block of host data 102 is a standard format such as CTLD (Control, Tag/Type, Length and Data) encoding, among others.

[0032] One of the fields within the framed block 102 is a change timestamp field 104. The value within this field 104 indicates whether the host device 24 has undergone a configuration change. In some arrangements, the host agent 34 may include a non-null value (e.g., a set bit or bits) within this field 104 to indicate that a configuration change has occurred (i.e., a change notice) and a null value to indicate that no configuration change has occurred (or vice versa).

[0033] In other arrangements where the clocks of the host device 24 and the array 22 are synchronized, the host agent 34 places the time of the last configuration change in the change timestamp field 102 so that, when the represented time is after the last polling time, the array 22 knows that a configuration change has occurred at the host device 24. If the represented time is before the last polling time, the array 22 knows that no configuration change has occurred since receiving a prior communication 100. Other arrangements are suitable for use as well (e.g., specific messages, custom bit patterns, and so on).

[0034] Upon receipt of the communication 100, the storage array 22 updates its database 74. In particular, the storage array 22 stores timestamp information 106 in a timestamp field of the record 76 which corresponds to the host device 24 (e.g., the record 76 representing a particular communications pathway 28 leading to the host device 24). At this same time, the storage array 22 is capable of storing other information contained within the block 102 in that record 76 (see FIG. 2 for illustrative examples of such information).

[0035] It should be understood that the storage array 22 alternatively may simply set a bit of that record 76, i.e., a ‘change’ bit, to indicate that a host device 24 has undergone a configuration change. However, storing timestamp information 106 in the database record 76 is preferable since it alleviates the need to reset the ‘change’ bit in a subsequent operation.

[0036] It should be further understood that the data block 102 informing the data storage array 22 of a configuration change is capable of being a notification which is sent from the host agent 34 to the array 22 specifically in response to the host device 24 undergoing the configuration change. Alternatively, the data block 102 informing the data storage array 22 of a configuration change is capable of being included in a routine transmission which is sent from the host agent 34 to the data storage array 22 for some other purpose (e.g., the change notice 82 rides piggy-back with other notifications within the data block 102). In either situation, the change notice 82 preferably travels in an ‘in-band’ manner through the communications pathways 28 (e.g., using the same protocols as other routine host/array communications). Although ‘out-of-band’ messaging is acceptable for use, sending the change notices 82 through such secure pathways alleviates the need for special changes to a computer network (e.g., see the cloud 30 in FIG. 1) or other parts of the communications infrastructure that could otherwise weaken or compromise security of the data storage environment 20. Further details will now be provided with reference to FIG. 3.

[0037] FIG. 3 shows a process 120 for detecting which host devices 24 have undergone a configuration change and thus should be ‘smartly polled’ for configuration information. It should be understood that the process 120 continues in an ongoing manner, e.g., during a poll period or cycle. To this end, the upper layer component 48 periodically receives an electronic signal 120 to poll host devices 24 which have recently undergone a configuration change. Furthermore, the last polling time 122 is available and routinely updated.

[0038] Each time the upper layer component 48 receives the signal 120, a new poll cycle begins. Here, the upper layer component 48 provides a command 124 to the admin engine 72 (also see the admin layer component 50 of FIG. 1). The command 124 directs the admin engine 72 to provide a list of changed records. In response to the command 124, the admin engine 72 accesses the database 74 for records 76 which indicate those host devices 24 which have undergone a change since the last polling time 122. In some arrangements, the upper layer component 48 receives any records which have been detected to have changed (i.e., not just records with changes in their timestamp fields), and the upper layer component 48 determines which of those received records have a changed timestamp in the record's timestamp field 125 based on a comparison between the contents of the records' timestamp fields 125 and the last polling time 122. To this end, the upper layer component 48 may simply compare the contents of the timestamp field 125 of each record 76 with the last polling time 122. If the timestamp is ahead of (i.e., chronologically after) the last polling time 122, the admin engine 72 concludes that the host device 24 corresponding to that record 76 has undergone a configuration change since the last polling time and adds the record to a list 128 of changed records. However, if the timestamp is chronologically before the last polling time 122, the admin engine 72 concludes that the host device 24 corresponding to that record 76 has not undergone a configuration change since the last polling time and does not add the record to the list 128 of changed records. Additionally, in these arrangements, the upper layer component 48 updates the last polling time 122 with the current time, i.e., the current time is now the new last polling time 122.

[0039] In other arrangements, the upper layer component 48 receives only the records which have changes in their timestamp fields from the admin engine 72 (i.e., just records with changes in their timestamp fields). Here, after the admin engine 72 has identified all of the host devices 24 which have undergone a configuration change since the last polling time 122, the admin engine 72 provides the list 128 of changed records to the upper layer component 48. Additionally, the admin engine 72 updates the last polling time 122 with the current time, i.e., the current time is now the new last polling time 122.

[0040] The upper layer component 48 then polls only the set 130 of host devices 24 on the list 128. This polling burden is typically very small since host devices 24 do not often undergo configuration changes. Accordingly, the polling period may be kept to a relatively short amount of time (e.g., one minute, five minutes, etc.) thus minimizing the risk that a configuration change will go undetected for more an extended period of time. Further details will now be provided with reference to FIG. 4.

[0041] FIG. 4 shows a process 140 for caching host configuration data 160 obtained through smart polling to alleviate the need to poll all of the host devices 24 after a restart. Such operation greatly speeds up startup time of the data storage array 22.

[0042] To this end, the upper layer component 48 is constructed and arranged to the cache host configuration data 160 such as logical unit number (LUN) mapping information in one or more mechanisms capable of static representation. An example includes extensible markup language (XML) files 162 which are maintained in a non-volatile cache 164, e.g., also see the memory 88 in FIG. 1. Thus, upon a restart of the data storage array 22, the upper layer component 48 simply reads the host configuration data from the cache 164 and does not need to poll the host devices 24 for this information. Rather, the array 22 continues to smartly poll only host devices 24 that have sent change notices 82 as described earlier with reference to FIGS. 1 through 3.

[0043] In one arrangement, the admin engine 72 is constructed and arranged to store the LUN mapping information of all of the host devices 24 in a single XML file 162. Such an arrangement provides convenient initial parsing and compression, but may require updating the whole XML file even if there is only one host device change.

[0044] In another arrangement, the admin engine 72 constructed and arranged to store the LUN mapping information of all of the host devices 24 in separate XML files 162 (see ellipsis in the cache 164 of FIG. 4). That is, there is one XML file per host device 24. Such an arrangement is easy to update, but requires the array 22 to parse the many XML files 162 upon startup, i.e. as many XML files 162 as there are host devices 24. Further details will now be provided with reference to FIG. 5.

[0045] FIG. 5 is a flowchart of a procedure 200 which is performed by the data storage array 22 in an ongoing manner. In step 202, the data storage array 22 receives a set of change notices 82 from a set of host devices 24 (also see FIG. 1). These change notices 82 are acquired since the last smart polling event when respective host devices 24 undergo a configuration changes.

[0046] In step 202, the data storage array 22 provides a set of requests 84 to the set of host devices 24 (e.g., one or more hosts but less than all of the host devices 24 in the environment 20) based on the set of change notices 82. Recall that the data storage array 22 sends requests 84 only to those host devices 24 which have undergone a configuration change thus minimizing the polling burden.

[0047] In step 204, the data storage array 22 acquires current configuration information 86 (i.e., configuration change information) from the set of host devices 24 in response to the set of requests 84. This information is stored in the database 74 as well as rendered to the user through the I/O device 36 (FIG. 1).

[0048] The procedure 200 is continued in an ongoing manner, e.g., repeated each polling period as defined by a standard polling time such as one minute. Such ‘smart polling’ alleviates the need to communicate with all of the host devices 24. Rather, the array 22 needs to communicate only with the host devices 24 which have recently undergone a configuration change.

[0049] As mentioned above, an improved technique is directed to polling only host devices 24 which have undergone a configuration change. Such a ‘smart polling’ technique alleviates the need to periodically poll all host devices 24 some of which have not undergone a configuration change. Rather, each poll of a host device 24 which has undergone a configuration change is efficient in the sense that it retrieves meaningful information which includes some changed information. Moreover, the improved technique scales well in the sense that additional host devices 24 do not necessarily increase the polling burden. To the contrary, the polling burden is affected by the frequency of undergoing configuration changes. Accordingly, particular polling interval targets/goals that are set by a user in order to minimize time to detect configuration changes (e.g., completing a poll of changed host devices in one minute, five minutes, etc.) are easily achievable.

[0050] While various embodiments of the invention have been particularly shown and described, 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.

[0051] For example, it should be understood that the admin layer component 50 is capable of being formed by a bottom-half of a management utility in combination with operating environment software of the storage array. In such arrangements, the joint presence of these parts serves as the admin layer component 50. Portions of the Navisphere®Management Suite and the FLARE® operating environment provided by EMC Corporation of Hopkinton, Mass. are examples of a management utility and operating environment, one or both of which, are capable of being enhanced to operate either individually or together as the admin layer component 50.

[0052] In other arrangements, the admin layer component 50 operates separately from the operating environment. In such arrangements, the admin layer component 50 preferably is fully self-sustained as a module running above the operating environment.

[0053] Additionally, it should be understood that the above-described operation covers situations in which the data storage array 22 polls host devices 24 for change data. It should be understood that the techniques described above are also suitable for use in other situations such as when an error pertaining to storage is detected by a host device 24, among others. Such modifications and enhancements are intended to belong to various embodiments of the invention.