Patent Application
20160197994
In various computing environments, a server may access block level storage that is located external to the server. The block level storage may be part of a storage array located in a chassis that is separate from the server chassis, for example. The term block level storage may refer to a number of storage devices (e.g., hard drives) that are consolidated and presented (e.g., to servers) as a single logical storage volume. A server that connects to a storage volume may see the storage volume as though it were an individual hard drive in the server. A server (also referred to as a host) may connect to any number of storage arrays, for example, either directly or via a storage area network (SAN). A SAN may be a dedicated network that provides access to consolidated, block level storage.
The following detailed description references the drawings, wherein:
Servers/hosts may physically connect to and communicate with (e.g., regardless of whether directly or via a SAN) storage arrays using various transport protocols, for example, Fibre Channel, SSA, SAS, UAS, iSCSI, SCSI Parallel Interface or the like. This communication layer may be referred to as the “transport protocol layer.” On top of the transport protocol layer, servers/hosts may communicate using a command set for communicating with various peripheral devices. For example, the SCSI (Small Computer System Interface) command set or a similar command set may be used. This communication layer may be referred to as the “application layer” or the “command layer.”
To ensure redundancy and resiliency, a computing environment may provide a host with access to a storage array via multiple independent physical paths. The host may, if configured properly, detect that all of these paths connect to the same storage volume, and the host may make decisions about which path to use. In various situations, e.g., if a primary chosen path becomes unavailable, the host may instead make use of an alternate/redundant path. This ability for a server to communicate with the same storage volume via multiple physical paths may be referred to as “multipathing.”
As mentioned above, a host may implement “multipathing” to access a single storage volume (e.g., in a storage array) via multiple physical paths. For a host to take advantage of multipathing, the host may have to be configured properly. For example, the host may need to run multipathing software, and the multipathing software may need to be configured property. Unfortunately, it is common for host administrators to fail to configure their hosts properly, and it may not be apparent to the host administrator, at least at the time of setup, that the host is misconfigured. For example, looking at the transport layer (e.g., Fibre Channel or iSCSI), it may appear that the host is connected to the storage volume via a particular path (e.g., a newly-added, redundant path). Still, various issues (e.g., configuration issues in the host) may prevent the host from property communicating with the storage volume via that path. For example, the host may not be running any multipathing software, or the host may not be running the correct multipathing software. Alternatively, the host administrator may not have configured the multipathing software correctly to detect a new/redundant path or the administrator may not have run an appropriate re-scan to see the new/redundant path. Alternatively, the host and/or host software may simply have a bug that prevents proper detection of the new/redundant path.
Various ways of detecting that a path is configured correctly may be implemented in the host. In these situations, the host (e.g., via software and/or the host administrator) may determine which storage volumes the host can “see” via which paths, and the host may report these results to the appropriate storage arrays that include the detected storage volumes. Such reports may be reviewed by administrators of the storage arrays. An issue with these solutions is that storage arrays/array administrators are dependent upon the host/host administrator to report correctly. However, because a main reason that hosts do not communicate correctly with storage arrays is because of misconfiguration at the host, array administrators may not trust the host to report correctly. After all, proper reporting may require a properly configured communication path. Nor may arrays/array administrators want to wait for the host to report before confirming that the host is in proper communication. Additionally, host administrators may not want to install and/or configure software to perform the scanning and reporting.
Various other ways of detecting a path from a host at the storage array may only analyze the path connection at the transport layer (e.g., Fibre Channel, iSCSI, etc). For example, storage arrays may include features that detect, via transport-layer knowledge, when hosts are physically connected via a particular path. However, transport-layer knowledge is insufficient to determine whether the hosts are properly communicating with the storage volume of the storage array via the particular path, for example, whether the operating system (OS) of the host has scanned the storage volume via the particular path and/or whether the multipathing software of the host has detected the storage volume via the particular path. Various other ways of detecting a path from a host at the storage array may look for input/output (I/O) operations (e.g., reads, writes, etc.) coming from the host. However, looking for I/O operations may be insufficient in cases where the host is making no or light use of the storage volume initially or has decided to reserve the path for failover use rather than currently active use.
The present disclosure describes storage array based confirmation of successful detection and use of a path. The present disclosure describes a solution by which a storage array can determine whether a connected host has correctly detected and is capable of properly using a particular path (e.g., a newly-added, redundant path) to a storage volume of the storage array. This solution may be implemented entirely in the storage array and may require no modification to the host (e.g., to report which storage volumes/paths the host sees). In this respect, an administrator of the storage array may confirm that the host is not only visible at the transport layer, but has successfully detected and is capable of properly using the storage volume via the particular path. The storage array/administrator does not have to rely on the host to report. The present disclosure allows for a more certain determination that the host is correctly configured, and lessens the need for the array administrator and host administrator to both be involved with checking the status of connections.
The present disclosure may utilize various heuristics about expected host behavior to determine that the host has detected a path and is trying to property use it to access the storage volume. According to the present disclosure, the storage array may watch for various commands (e.g., SCSI commands) that flow at a layer above the transport protocol layer (e.g., at the command layer). Using this solution, the storage array may detect, for example, that the operating system (OS) of the host has scanned the storage volume via the particular path, and that the multipathing software of the host has detected the storage volume via the particular path and is capable of making proper use of it. This information about properly detected and used paths may be useful to the storage array in various situations, for example, when a new redundant path is added between a host and a storage volume. This information may also be used by the storage array when a particular path to a storage volume is removed (e.g., temporarily), for example, to determine first that an alternate/redundant path to the storage volume is fully working before the other path is removed.
Storage area network (SAN) 120 may be a dedicated network that facilitates access by hosts (e.g., 102, 104, 106) to consolidated, block level storage (e.g., in storage arrays 110, 112, 116). SAN 120 may include various cables, switches, routers and the like to connect various hosts to various storage arrays. In the examples where at least one host (e.g., 102) is directly connected to at least one storage array (e.g., 110), the particular host may be connected to the particular storage array without routing through SAN 120. As one specific example, if host 102 and storage array 110 are directly connected, the two connections coming from the controller nodes of storage array 110 may route directly to host 102.
Host 102 may communicate with at least one storage array (e.g., 110), for example, via SAN 120. Hosts 104 and 106 may be similar in several respects to the description of host 102 provided herein. Host 102 may be any type of computing device that is capable of connecting to and using remote storage such as storage array 110. Host 102 may be, for example, an application server, a mail server, a database server or various other types of servers. Host 102 may have more than one physical path to storage array 110, e.g., as shown in
Storage array 110 may communicate with at least one host (e.g., host 102), for example, via SAN 120. Storage arrays 112 and 116 may be similar in several respects to the description of storage array 110 provided herein. For example, storage arrays 112 and 116 may include similar components to those shown in storage array 110 in
Storage array 110 may be any storage system that contains multiple storage devices (e.g., hard drives). For example, storage array 110 may be a RAID (redundant array of independent disks) system with multiple spinning disk hard drives. As another example, storage array 110 may be a storage system with multiple optical drives or multiple tape drives. The multiple storage devices (e.g., hard drives) of storage array 110 may be consolidated and presented to servers (e.g., to host 102) as a single logical storage volume (e.g., storage volume 126). Storage volume 126 may, if the host is configured correctly, appear to host 102 as essentially a single local hard drive, even though storage volume 126 may include multiple storage devices. Host 102 may have multiple physical paths to access the same storage volume 126, for example, a first path through controller node 122, and a second path through controller node 124.
Storage array 110 may include at least one controller node (e.g., 122, 124), also referred to as a storage controller.
Each controller node (e.g., 122, 124) may be implemented as a computing device, for example, any computing device that is capable of communicating with at least one host (e.g., 102) and with at least one storage volume (e.g., 126). In some examples, multiple controller nodes (e.g., 122 and 124) may be implemented by the same computing device, for example, where each controller node is run by a different virtual machine or application of the computing device. In general, the controller nodes (e.g., 122, 124) may monitor the state of the storage devices (e.g., hard drives) that make up the storage volume 126, and may handle requests by hosts (e.g., 102) to access the storage volume 126 via various physical paths. In the example of
Path confirmation modules 132, 134 may each include a series of instructions encoded on a machine-readable storage medium and executable by a processor (e.g., processor 410 of
Path confirmation module 202 may determine whether a connected host has correctly detected and is capable of property using a particular path (e.g., a newly-added, redundant path) to a storage volume 220 (e.g., similar to storage volume 126 of
Command monitoring module 210 (also referred to as command monitor) may monitor commands that flow from various hosts (e.g., host 222) to storage volume 220. Host 222 may be similar to host 102, for example. Module 210 may monitor commands that flow via a layer that is above or on top of the transport protocol layer. For example, module 210 may monitor commands that flow via the “application layer” or “command layer.” As mentioned above, communications at the command layer use a command set (e.g., the SCSI command set).
Command analyzing module 212 (also referred to as command analyzer) may analyze the commands that are seen (above the transport protocol layer) by command monitoring module 210. Command analyzing module 212 may detect particular commands (e.g., SCSI commands) and/or sequences of commands to determine whether the host (e.g., 222) has correctly detected and is capable of property using a particular path to a storage volume 220. If it is determined that a host (e.g., 222) has correctly detected and is capable of properly using a particular path to a storage volume 220, it may be said that the particular path is “active.” Command analyzing module 212 may watch for various commands, such as the SCSI commands shown below in Table 1 below. Table 1 lists various example commands along with a short description of each command. Some of these commands may be initiated by the OS of the host, and some may be initiated by the multipathing software of the host. In general, the commands that module 212 watches for may be commands that are commonly initiated when a host is attempting to connect to a newly added storage volume or a newly added path to a storage volume.
In the example of Table 1, each of the shown commands may provide an indication that the host has discovered and/or is property using the particular path at a layer that is above the transport layer (e.g., at the command layer). When command analyzing module 212 sees more than one of these commands, module 212 may determine with a higher degree of confidence that the host has discovered and/or is property using the particular path. In other words, each of the above commands alone may provide a positive indication, but as module 212 sees more of the above commands (e.g., in the order shown in Table 1), the likelihood increases that the host is properly connected. For example, seeing more of these commands may allow module 212 to confirm that multipathing software in the host has discovered the storage volume and is performing interrogation to determine the exact nature of the new path to the storage volume. It should be understood that the commands shown in Table 1 represent just one example of a pattern of commands that module 212 may detect. Module 212 may be capable of detecting various other heuristics and/or patterns of commands that flow at a communication layer above the transport protocol layer.
Command analyzing module 212 may at some point, while analyzing commands for a particular host and path, determine that module 212 has seen enough information to determine that the host and path are active (i.e., the host is property connected to the storage volume via the path). For example, module 212 may maintain at least one threshold, and once module 212 sees enough evidence (e.g., commands above the transport layer) to surpass the threshold, module 212 may determine that the host and path are active. Module 212 may then indicate active hosts and paths to path status tracking module 214.
Path status tracking module 214 (also referred to as path status tracker) may track and/or store the active status for various hosts/paths, e.g., both for the local controller node (e.g., 200) and for other controller nodes of the same storage array. Path status tracking module 214 may receive host/path active indications from module 212 for the local controller node. This may include active indications for paths that pass through the local controller node (e.g., 200). Module 214 may also receive host/path active indications from at least one other controller node (e.g., 224) of the same storage array. This may include active indications for paths that pass through the other controller node(s). Likewise, module 214 may send host/path active indications to at least one other controller node (e.g., 224) of the same storage array such that the other controller node can track and/or store such information. In this respect, any controller node in a storage array may maintain or have access to information about all host-to-storage-volume paths that pass through the storage array. Thus, and administrator may connect to any controller node. e.g., via admin interface 204, and determine whether a particular path through the storage array is active.
In some examples, path status tracking module 214 may be located external to path confirmation module 202, and perhaps external to controller node 200. In these examples, each storage array (e.g., 110) may include a single path status tracking module 214, and each controller node (and path confirmation module) in the storage array may have access to the status tracking module. Each path confirmation module in the storage array may send its host/path active indications to the central status tracking module, and each path confirmation module may have access to the central status tracking module, for example, to respond to path queries, which are described in more detail below.
Path query and alert module 216 may communicate with path status tracking module 214 to determine whether various hosts/paths are active. In general, module 216 may check if a particular path is active and may, in some situations, generate an alert if an important path is not active. A part of module 216 that handles queries (e.g., from an administrator) may be referred to as the path query handler. A part of module 216 that handles responses and/or alerts may be referred to as the path alert handler. As one example, an array administrator (e.g., 205) may access controller node 200 (e.g., via admin interface 204) with the intention of taking down a particular path between a host and the storage volume of the storage array. As one specific example, the administrator may intend to perform an upgrade on the particular controller node 200, which may cause paths that pass through the controller node to temporarily be removed. In this situation, administrator 205 may access module 216 to inquire about whether it is safe to take down a particular path that passes from a host through controller node 200. Module 216 may then check whether there are any alternate paths that are active between the host and the storage volume (e.g., a path through a different controller node of the same storage array). If an alternate path is available and active, module 216 may essentially send the administrator a green light to take down the path through controller node 200, and the administrator may be confident that the host will not experience any disruption in service. If no alternate path is active, module 216 may send the administrator an alert that removing the path may cause a disruption of service.
In some examples, path query and alert module 216 may continuously or occasionally monitor the status of various paths (e.g., by communicating with module 214) and may alert an administrator of any issues, e.g., without the administrator having to query module 216. For example, module 216 may ensure that at all times any host that communicates with the storage volume of the storage array has two independent active paths to the storage volume. In this example, if at any time, module 216 detects that a host has dropped down to a single active path or no active paths, module 216 may alert the array administrator (e.g., via email, SMS, etc.). Thus, if, for example, an administrator is performing maintenance on a portion of a storage network (e.g., SAN 120), and accidentally removes a path between a host and a storage volume, at least one controller node of the associated storage array may alert the administrator.
Method 300 may start at block 302 and continue to block 304, where a controller node (e.g., 122) of a storage array (e.g., 110) may monitor (e.g., via module 210) commands (e.g., commands that flow above the transport protocol layer) that flow via a particular path from a host to a storage volume of the storage array. At block 306, the controller node may analyze (e.g., via module 212) the commands (e.g., single commands and/or sequences of commands) to determine whether the host is properly seeing and using the path to the storage volume. At block 308, the controller node may track and/or store (e.g., via module 214) active paths from various hosts to the storage volume, including the particular path mentioned above. In some examples, the tracking and storing of active paths may be done outside of the controller node, e.g., in a tracking and storing module that is central to the storage array and accessible to all controller nodes of the storage array, as described in more detail above.
At block 310, the controller node may receive (e.g., via module 216) a query from an administrator (e.g., 205) regarding whether a particular path is active or whether a particular path can be taken down (e.g., while still having an active alternate path). At block 312, the controller node may determine whether the particular path is active or whether there is an active alternate path (in the case of taking down a path). To perform block 312, module 216 may communicate with path status tracking module 214, for example. At block 314, the controller node may respond to and/or alert (e.g., via module 216) the administrator, for example, to confirm that a path/alternate path is active, or to warn that a path/alternate path is not active. Method 300 may eventually continue to block 320, where method 300 may stop.
At block 316, the controller node may monitor (e.g., via module 216) the status of various paths through the storage array, for example, automatically, without any queries from an administrator. At block 318, the controller node may detect (e.g., via module 216) that a particular host has only a single active path or no active paths to the storage volume. At block 314, the controller node may alert (e.g., via email, SMS, etc.) an administrator regarding the fact that a particular host has only a single active path or no active paths to the storage volume. Method 300 may eventually continue to block 320, where method 300 may stop.
Processor 410 may be one or more central processing units (CPUs), microprocessors, and/or other hardware devices suitable for retrieval and execution of instructions stored in machine-readable storage medium 420. In the particular embodiment shown in
Machine-readable storage medium 420 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions. Thus, machine-readable storage medium 420 may be, for example. Random Access Memory (RAM), an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disc, and the like. Machine-readable storage medium 420 may be disposed within host computing device 400, as shown in
Command monitoring instructions 422 may detect commands at a communication layer that is above a transport protocol layer. The commands flow via a path from a host to the storage volume. Command analyzing instructions 424 may determine whether at least one of the commands indicates that the host has detected or is capable of using the storage volume successfully via the path. This may mean that the path is “active.”
Method 500 may start at block 502 and continue to block 504, where controller node computing device 400 may monitor commands that flow via a path from a host to the storage volume. The commands may flow at a communication layer that is above a transport protocol layer. At block 506, controller node computing device 400 may determine whether at least one of the commands indicates that the host has detected or is capable of using the storage volume successfully via the path. This may mean that the path is “active.” At block 508, controller node computing device 400 may store an indication of whether the path is active or not. Method 500 may eventually continue to block 510, where method 500 may stop.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2013/058216 | 9/5/2013 | WO | 00 |
