Patent Application
20070038679
The invention relates generally to storage area networks, and more particularly to dynamic configuration updating in a storage area network.
Enterprise grid computing involves sharing heterogeneous resources (based on different platforms, hardware/software architectures, and computer languages) located in different places and belonging to different administrative domains over a network. For example, grid computing can employ unused resources (CPU cycles and/or disk storage) of many separate computers connected by a network (e.g., including a local network, a wide area network, or the Internet) to distribute and execute computerized processes across these resources. The collection of these disparate computers is treated as a virtual cluster embedded in a distributed telecommunications infrastructure. Generally, grid computing has various design goals, including solving problems too big for any single supercomputer, providing applications with better utilization of resources, and providing consistent interfaces to heterogeneous resources.
Such large scale computing and data requirements can present a data storage challenge, which can be at least partially addressed by a storage area network (SAN). A SAN may be implemented as a high-speed, special purpose network that interconnects different kinds of data storage devices with associated data servers on behalf of a large network of users. Typically, a SAN includes high-performance switches as part of the overall network of computing resources for an enterprise. The SAN is usually clustered in close geographical proximity to other computing resources, such as mainframe computers, but may also extend to remote locations for backup and archival storage using wide area network carrier technologies.
However, the mapping of applications to host computers is dynamic in a grid computing environment. Therefore, configuration changes in the SAN (e.g., zoning, other security parameters, and quality of service parameters) should be accepted and propagated quickly and efficiently throughout a fabric of a SAN. Unfortunately, existing SANs do not adequately support efficient dynamic configuration updates and therefore introduce large communication requirements and long delays for SAN reconfigurations, both of which can disrupt SAN service. Furthermore, existing approaches are not well suited for automation.
Implementations described and claimed herein address the foregoing problems by communicating differential configuration update commands that can be applied quickly to active zone sets and zone set libraries, without requiring propagation of entire zone sets or libraries through a fabric of the SAN. In one implementation, ordered differential configuration update commands are applied to ordered zone set data structures to minimize update instruction communication requirements and optimize configuration update operations. In another implementation, differential configuration update commands are applied to active zone set data structures (e.g., in an active zone set or a zone set library) to optimize configuration update operations.
In some implementations, articles of manufacture are provided as computer program products. One implementation of a computer program product provides a computer program storage medium readable by a computer system and encoding a computer program. Exemplary storage media may include without limitation magnetic and optical disks, EEPROMS, flash memory, RAM, and other storage devices.
Other implementations are also described and recited herein.
Within the SAN 104, one or more switches 112 provide connectivity, routing and other SAN functionality. A SAN can comprise a set of one or more fabrics, which are generally collections of interconnected switches that have established communications among them to facilitate communication between any pair of devices attached to those switches.
Some such switches 112 may be configured as a set of blade components inserted into a chassis. The chassis has a back plane or mid-plane into which the various blade components, such as switching blades and control processor blades, may be inserted. Alternatively, one or more switches may be modular in nature, such that individual port modules (having data ports and an internal switching fabric) and possibly individual switch modules (providing additional switching capacity to various port modules) are interconnected together to provide a highly scalable switch configuration.
A management client 114 can be used to manage server provisioning, which may include changes to the SAN configuration (such as zoning changes). The management client 114 may be coupled into one or more servers (e.g., via the LAN or a dedicated Ethernet connection) and one or more switches within the SAN (e.g., via the SAN or a dedicated Ethernet connection). In an enterprise grid computing environment, these configuration changes should be propagated and applied throughout the fabric quickly and efficiently. For example, if an application is moved to a different server, the storage configuration relating to that server should change quickly to allow a new server to access storage needed by a migrated application. Alternatively, if a new switch is added to the SAN, the storage configuration in the SAN may alter quickly to take advantage to the new switching functionality. Accordingly, in reaction to a configuration change in the SAN, the management client 114 issues a differential configuration update command. Components of the management client 114 can then implement differential configuration changes (e.g., zoning) in response to this command and then propagate the command into the fabric to individual switches, which also implement the differential changes.
In one implementation, each configuration module maintains an internal data structure in the form of a hierarchical configuration object, which store characteristics of various devices and logical parameters of the SAN. For example, zoning is a method of subdividing a SAN into disjoint zones or subsets of nodes on the network. SAN nodes outside a zone are invisible to nodes within the zone. A zone defines a group of devices in a SAN that can communicate with and access each other. Although zones help isolate devices and processes that should not communicate, an individual device can be in multiple zones so that shared resources can be accessed by many devices in different zones.
Zoning is enforced by an active zone set maintained by the switches in the SAN, and by various configuration modules managing the devices in the SAN. Zoning is typically characterized by a hierarchical structure. For example, in one architecture, a zone set includes one or more zones, each zone including two or more zone members, such as servers and/or storage devices. When a zone set is activated, all zones within the zone set are activated simultaneously. A zone member is identified by either the physical port number to which it is attached to a switch or by its World Wide Name (WWN). The WWN is unique throughout the world, and various forms of WWNs are defined in the ANSI standard Fiber Channel Framing and Signaling (FC-FS).
In one type of zoning, zoning is enforced by fabric routing tables maintained by switches in the storage network. If a port of a switch is not authorized to communicate with another port in the switch, the routing table entry for the port is disabled so that communication does not occur. Another type of zoning (e.g., name server zoning) employs a name server database maintained in the switch. The name server database stores WWNs and device registered information to identify individual devices during the zoning process. When zoning changes in a fabric, each device in the name server database receives a registered state change notification (RSCN). In response to the RSCN, a device may query the name server database to determine its connectivity to other devices. All device query results are filtered by the querying device's zoning.
Multiple zone sets can be maintained for a given SAN. For example, when two operating systems must use a single device, such as a tape device in distinct Windows NT and Unix zones, different zone sets can be activated when each operating system needs to backup data. When a server running Windows NT needs to use the tape device, a first zone set is activated so that only the Windows NT service can access the tape device. Likewise, when a server running UNIX needs to use the tape device, a second zone set is activated so that only the UNIX service can access the tape device. This zoning approach allows user's to choose different zoning configurations based on specific communication needs (e.g., between applications and associated storage across a fabric).
When two or more fabrics are combined to form a single fabric, all fabrics exchange zoning configuration among them, and when possible, all zoning configuration data is merged together. After the multiswitch fabric is operational, changes in zone membership are propagated to and validate by every switch in the fabric. When a management application requests activation of a new zone set, the fabric initiates a Fabric Change Authorization (e.g., as defined in the FC-SW specification). This change authorization is transparent to users but ensures that zoning is consistent throughout the fabric.
Managers and switches can support the Fibre Channel-Security Protocol (FC-SP), a security protocol for Fibre Channel Protocol (FCP) and fiber connectivity (Ficon). FC-SP is a project of Technical Committee T11 of the International Committee for Information Technology Standards (INCITS). The FC-SP specification includes protocols to enhance Fibre Channel security in several areas, including authentication of Fibre Channel devices, cryptographically-secure key exchange, and cryptographically secure-communication between Fibre Channel devices. FC-SP is focused on protecting data in transit throughout the Fibre Channel network and does not address the security of data which is stored on the Fibre Channel network.
With the context of a SAN that supports FC-SP, the management client 200 can specify a configuration change instruction to the SAN containing the switches 202, 204, 206, and 208. The configuration change instruction can take the form of an instruction containing a complete configuration description including one or more differential changes from the current configuration state or an instruction that includes only the differential changes from the current configuration state. In either case, a differential configuration update command is derived from the differential configuration change instruction and applied to one or more hierarchical configuration objects in the configuration module 212. For example, given a complete configuration description (e.g., an complete zone set object), a configuration module can compare current and desired zone sets to generate a differential configuration change instruction that can be applied to the active zone set and/or zone set library maintained by the configuration module 212. It should also be understood that the described technology can also be applied to SANs that do not specifically support FC-SP.
One exemplary hierarchical configuration object may be an active zone set object including a zone set identifier, two or more zone identifiers, and two or more zone members (i.e., devices) in each zone. Alternatively, the zone set object may be non-active and reside in a library or database of multiple zone sets, which may be activated by command of the manager 210. Furthermore, the differential configuration update command may be propagated from switch to switch in order to update the active zone set or zone set library in each switch and therefore updating the zoning configuration maintained by said switches within the fabric.
The differential configuration update command 300, for example, may request that a zone set be altered to reflect or accommodate the change in the storage network. In one implementation, the differential configuration update command 300 includes information relating to the differences between desired storage network configuration state and the current storage network configuration state. For example, the differential configuration update command 300 may specify that a new storage device be added as a member of a particular zone, thereby enabling communications with the new storage device by other member devices in the zone. In addition, in some implementations, multiple differential changes may be specified in a single differential configuration update command.
Data communicated in an exemplary differential configuration update command may include a zone set identifier and a directive, wherein the directive specifies the differential configuration change instructed by the differential configuration update command. Exemplary directives may include without limitation: “add” (a zone to a zone set or a distributed zone set library), “remove” (a zone from a zone set or a distributed zone set library), “modify” (a zone set), and “rename” (a zone set). Depending on the type of directive, the differential configuration update command may also include zone identifiers, zone member identifiers, security parameters, Quality of Service (QoS) parameters, and other configuration parameters.
Furthermore, a differential configuration update command applied to security parameters (e.g., instead of zoning parameters) can consist of a set of added or removed port, switch, fabric binding settings. Such settings can restrict a given port, switch or fabric to be communicatively connected to a specified device or list of switches. Similarly, QoS parameters can change priority settings of a given set of ports.
In the illustrated implementation, the configuration module 302 maintains (as represented by dashed box 320) both a library 304 (e.g., a database) of zone set objects 316 and an active zone set 306, embodied by zone set object 318. In an alternative implementation, the configuration module 302 maintains a single zone set object, even if the zone set is the active zone set, and merely references the zone set object (e.g., from the library 304 or from a zone set reference value in the configuration module 302. In other implementations, either the library 304 and/or the active zone set object 306 may not be maintained by a configuration module at all. For example, in one implementation, differential configuration update commands are propagated directly to the switches in the fabric to alter active zone set objects and/or libraries maintained by the switches.
Based on the differential configuration update command 300, the configuration module 302 can identify the one or more specified zone sets, determine an index (or pointer) to the specified zone set object in the library 304 and effect the specified directive within that zone set object (represented by the “Δ change” token and a dotted arrow 308 in
In another implementation, the configuration module 302 can determine whether one of the specified zone sets is the active zone set (e.g., a simple comparison of zone set identifiers). If so, a similar indexing operation can yield an index (or pointer) to the specified elements (e.g., zone objects or zone member objects) within or referenced by the active zone set object maintained by the configuration module 302 and effect the specified directive within that zone set (represented by the “Δ change” token and a dotted arrow 310 in
Stage Fabric Configuration (SFC) requests are class F frames addressed from the domain controller of the managing switch (or configuration module) to the domain controller of a managed switch to stage the configuration changes in each switch. For example, SFC operation requests can instruct the recipient to activate, deactivate, or alter a zone set or a zone set library. Similar commands may be communicated between management software and a switch or between a manager and a configuration module, although different protocols and formats are contemplated. In the case of differential configuration requests, two exemplary SFC operation requests include:
The exemplary Delta Update Active Zone Set request represents an exemplary differential configuration update command for an active zone set and includes an ordered or sorted payload:
In one implementation, the Affected Zone Objects in the list are ordered based on their zone names (identifiers), as identified in the zone objects (see below).
An exemplary Affected Zone Object has the following format:
An exemplary Zone Modification List has the following format:
An exemplary Member Modification Object has the following format:
The exemplary Delta Update Distributed Zone Set Database request represents an exemplary differential configuration update command for a library and includes an ordered or sorted payload:
In one implementation, the Affected Zone Set objects and Affected Zone Set Alias objects in the list are ordered based on their zone set and alias names (identifiers), as identified in the zone set and zone set alias objects (see below).
An exemplary Affected Zone Set Object has the following format:
An exemplary List of Zone Names has the following format:
An exemplary List of Affected Zone Modifications has the following format:
An exemplary Affected Zone Alias Format Object has the following format:
An exemplary Alias Modification Object has the following format:
An exemplary Alias Modification Object has the following format:
It should be understood that the requests and data structures described herein are merely exemplary and that alternative and additional requests and data structures may be employed.
An accessing operation 606 accesses the zone set object and/or element object based on the reference. An altering operation 608 modifies the node in accordance with a directive in the differential configuration command. For example, a new zone member can be inserted in a specified zone in a hierarchical configuration object. The modification can occur at multiple levels of hierarchy in the zone set object. A propagation operation 610 derives differential configuration update command data and transmits it to a switch in the fabric. Propagation can then occur throughout the fabric to all other switches therein. Each switch receiving the differential configuration update command data can then be updated with the configuration change.
It should be understood that the operations described with regard to
An altering operation 706 replaces the active hierarchical configuration object with the hierarchical configuration object in the scratch memory buffer, thereby updating the configuration in the switch, for example. In one implementation, the altering operation 706 designates the hierarchical configuration object in the scratch memory buffer as the active configuration object (e.g., the active zone set). A propagation operation 708 derives differential configuration update command data and transmits it to a switch in the fabric. Propagation can then occur throughout the fabric to all other switches therein. Each switch receiving the differential configuration update command data can then be updated with the configuration change.
The I/O section 804 is connected to one or more user-interface devices (e.g., a keyboard 816 and a display unit 818), a disk storage unit 812, and a disk drive unit 820. Generally, in contemporary systems, the disk drive unit 820 is a DVD/CD-ROM drive unit capable of reading the DVD/CD-ROM medium 810, which typically contains programs and data 822. Computer program products containing mechanisms to effectuate the systems and methods in accordance with the described technology may reside in the memory section 804, on a disk storage unit 812, or on the DVD/CD-ROM medium 810 of such a system 800. Alternatively, a disk drive unit 820 may be replaced or supplemented by a floppy drive unit, a tape drive unit, or other storage medium drive unit. The network adapter 824 is capable of connecting the computer system to a network via the network link 814, through which the computer system can receive instructions and data embodied in a carrier wave. Examples of such systems include SPARC systems offered by Sun Microsystems, Inc., personal computers offered by Dell Corporation and by other manufacturers of Intel-compatible personal computers, PowerPC-based computing systems, ARM-based computing systems and other systems running a UNIX-based or other operating system. It should be understood that computing systems may also embody devices such as Personal Digital Assistants (PDAs), mobile phones, gaming consoles, set top boxes, etc.
When used in a LAN-networking environment, the computer system 800 is connected (by wired connection or wirelessly) to a local network through the network interface or adapter 824, which is one type of communications device. When used in a WAN-networking environment, the computer system 800 typically includes a modem, a network adapter, or any other type of communications device for establishing communications over the wide area network. In a networked environment, program modules depicted relative to the computer system 800 or portions thereof, may be stored in a remote memory storage device. It is appreciated that the network connections shown are exemplary and other means of and communications devices for establishing a communications link between the computers may be used.
In accordance with an implementation, software instructions and data directed toward dynamically updating configuration of a SAN and other operations may reside on disk storage unit 809, disk drive unit 807 or other storage medium units coupled to the system. Said software instructions may also be executed by CPU 806.
Each ASIC provides, among other functions, a switched datapath between a subset of the user ports 902 and the 16 extender ports 904. For a stand-alone port module, its extender ports are cabled together. For a stacked configuration, the extender ports of the port modules are cabled together. For a racked configuration, the extender ports of the port modules and the switch modules are cabled together. In one implementation, the extender ports are cabled using four parallel bi-directional fiber or copper links, although other configurations are contemplated.
It should be understood that processors on other devices may also execute the operations described herein.
In accordance with an implementation, software instructions and data directed toward dynamically updating configuration of a SAN and other operations may reside DRAM or flash memory or other storage medium units in the device. Said software instructions may also be executed by a PIP or HLP.
The embodiments of the invention described herein are implemented as logical steps in one or more computer systems. The logical operations of the present invention are implemented (1) as a sequence of processor-implemented steps executing in one or more computer systems and (2) as interconnected machine or circuit modules within one or more computer systems. The implementation is a matter of choice, dependent on the performance requirements of the computer system implementing the invention. Accordingly, the logical operations making up the embodiments of the invention described herein are referred to variously as operations, steps, objects, or modules. Furthermore, it should be understood that logical operations may be performed in any order, unless explicitly claimed otherwise or a specific order is inherently necessitated by the claim language.
The above specification, examples and data provide a complete description of the structure and use of exemplary embodiments of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended. Furthermore, structural features of the different embodiments may be combined in yet another embodiment without departing from the recited claims.
