Patent Application
20130036212
The present invention relates to data storage generally and, more particularly, to a method and/or apparatus to backup, restore, and/or replicate configuration settings in a storage area network environment using a management interface.
Organizations shipping and installing storage products have shown concern towards easy management and/or provisioning of installed storage devices. Along with manufacturing hardware and associated management software, vendors often provide a storage management interface (SMI) agent developed based on Storage Network Industry Association (SNIA) standards. SNIA promotes the use of a SMI to allow management of devices from different vendors easy and affordable. The concept of SMI overcomes interoperability of devices from different vendors.
Conventional solutions make use of Application Programming Interfaces (APIs) available from each vendor. Complications involved with such a solution involve the interoperability with different vendor devices. Each vendor tends to implement a separate management API. Separate interfaces make it difficult for a storage administrator to bring a new device into an existing site because the solution might not have adequate support for the APIs provided by the new device. Even though the new device may be cost effective to the organization, and have better performance compared to installed devices, the rigidness of such a solution sometimes deters administrators from using the new device.
It would be desirable to implement a data storage management system that may communicate with all devices in a storage area network (SAN) and/or have the capability to re-build a SAN without manual intervention once new hardware is setup.
A method for backing up components in a mixed vendor network using a common administration computer, comprising the steps of (A) sending a plurality of first requests to a plurality of components of a first network, (B) storing responses to the first requests in the common administration computer and (C) sending a plurality of second requests to a plurality of components in a second network in response to the stored plurality of first requests. The first network comprises components from a first manufacturer. The second network comprises components from a second manufacturer. The second network replicates the first network in response to the plurality of second requests.
The objects, features and advantages of the present invention include providing a storage management solution that may (i) allow easy migration of configuration/data from a network of a first manufacturer to a network of a second manufacturer where the hardware of the second manufacturer is supported by SMI, (ii) be applicable to a network attached storage (NAS) or any other environment that conforms to SMIS standards, (iii) enable the replication of the configuration settings from a NAS to a SAN system to allow a customer to migrate from a NAS setup to a block array based on changes in the application environment, (iv) incorporate a process for starting with a clean configuration on the setup to be used for the restoration, (v) use the SMIS standard to trigger a clean configuration on each of the components before the restoration actually happens, (vi) allow users/administrators to use SMIS standards to create back up objects and/or restoration objects regardless of vendor mismatches and/or other mismatches on both of the setups to be backed up and/or the setup on which the restoration is to be installed, (vii) be extended to include backing up data by creating snapshots on the live data and/or migrating the data to the new configuration, and/or (viii) provide easy maintenance of the code since the structures and/or Extensible Markup Language (XML) calls in the code may be similar for many components regardless of the source vendor.
These and other objects, features and advantages of the present invention will be apparent from the following detailed description and the appended claims and drawings in which:
a and 5b are a flow diagram of a general operation of the present invention.
The present invention may use one or more standard based SMI agents provided by different vendors to implement backup and/or recovery operations. The system may allow a backup and/or restore of configuration settings for each component in the SAN using SMIS. The system may also replicate the configuration on clean (e.g., new) setups with the same and/or similar components. Such backup, restoration, and/or replication may be done from a variety of vendor storage products from a first vendor to a variety of vendor storage products from a second vendor, where the SMIS may be used to manage the storage products.
Consider an example of a two array system. One array may be implemented with components from a first vendor and another array may be implemented with components from a second vendor. The second array may implement a new array, perhaps with new premium features not available or the first array. The following steps may be used to implement a transition.
1. A user may use an SMIS interface to collect the metadata DATA structure (e.g., Array Profile, Switch Profile, Host Profile, etc.) from the existing array system.
2. The user may use an SMIS interface to pass the collected DATA structure to a new array system to (a) create a backup of the system, (b) restore the configuration, and/or (c) replicate the array system.
Such an objective may be extended from a variety first arrays to a variety of second arrays that the SMIS interface may manage. The backup and/or restore process may also extend to various components, such as hosts, switches, HBAs and/or any other components that conform to SMIS.
The invention may make use of the SMI providers distributed by each vendor to replace faulty hardware with new hardware from a different vendor. The new hardware may be interoperable with other devices participating in the SAN to be handled without modifying the tool to add support for the new hardware. The interoperability between different devices may result in a unified management solution. The invention may prove to have better request and/or response time by using the CIM model. The invention may capture details of a number of devices participating on the SAN independently of the particular hardware and/or data transfer protocols implemented.
In one example, the present invention may be used to implement a disaster recovery solution to communicate with APIs from different vendor devices to retrieve information and/or perform management oriented operations. The invention may be interoperable with the APIs provided by various vendors. The present invention may overcome issues arising from dependency on vendor specific APIs.
Referring to
The system 100 may provide a software stack (to be described in more detail in connection with
The SAN 102 may include one or more servers 120 (e.g., physical servers hosting one or more operating systems (OS) and/or ESX servers with guest OSes), one or more fiber channel switches 122, a host bus adapter (HBA) in the servers 120, a storage array 124 connected to the switch 122, and a management box. The server 120 may host the backup and/or recovery plugin.
The system 100 may backup certain aspects of the network 102 and/or the network 104. For example, the network 102 may include (i) FS/Partitions, (ii) Registry Settings (if applicable), (iii) Virtual Machines and/or settings (if applicable), and (iv) etc. The HBA may include (i) driver settings, (ii) FW/Driver Versions, (iii) LUN masking, (iv) etc. The switch 122 may include a configuration database that includes one or more of (i) zoning, (ii) VSAN, (iii) switch speed, port speed, (iv) port settings, (v) switch setting, and/or (vi) etc. A storage array may include (i) LUNs <->Raid Levels, (ii)) snapshots, mirrors, volume copies—premium features sets at the array, (iii) configuration database, (iv) cache settings, (v) battery setting, and (vi) etc. The system 100 may provide restore options to create the backed up components and/or corresponding objects on a new setup. The new setup may be similar (or different) in terms of vendor components and/or the same setup.
The devices in the SAN 102 may have a SMI provider configured to broadcast CIM services to facilitate discovery. Zones on the switches 122 may be created with aliases that follow a specific nomenclature (e.g., Host1HBA1Port0, Host1HBA1Port1, etc., Zone1, zone2, etc., zoneset1, zoneset2, etc.). The plugin may or may not be responsible for backing up and/or restoring the user data. A user may ensure that the components to be restored have a clear configuration.
Referring to
The following components may be defined (i) Plugin Components (e.g., Software Stack), (ii) an SLP (Service Locator Protocol) module that queries the network using a specific template to discover the various CIM services that get advertised, (iii) a CIM client (e.g., built using SMI 1.5 standards (or other SMI revisions) that have the capability to issue CIM-XML commands), (iv) the CIM XML analyzer 206 (e.g., module may have the capability to strip the data from the XML responses received and store it in a relational database) and/or (v) the relational database 208 that may store values retrieved from multiple hosts, fabrics and/or storage arrays in tables in a format that may be accessed and/or retrieved easily without bogging down the host machine (e.g., MySQL).
The software stack 200 may be configured to operate with a CIM Model of the SMI providers on the various devices in SAN 102 and/or the SAN 104. The software stack 200 may be installed on the management server 106. When a user initiates a backup of the configuration, the discovery module 202 may be initiated from a graphical user interface (GUI) or command line interface (CLI) of the plugin software stack 200. The stack 200 may discover devices in the subnet by sending queries to the network searching for CIM Services with particular attributes. For example, a query may retrieve the following information from the network:
Using the above details as an example, the CIM client 204 may login to a device and perform additional CIM operations to retrieve configuration details.
The following list provides examples of URLs of the services available on the network when an SLP query is issued to discover services in a network:
The following list provides an example of attributes retrieved after querying the wbem service of an array: [root@ rhe14i386 bin] #./slptool findattrs service:wbem:http://172.23.9.152:5988 (template-url-syntax=http://172.23.9.152:5988),(service-id=PG:1263315022656-127-0-0-1),(service-hi-name=Pegasus),(service-hi-description=Pegasus LSI CIM Server Version 2.9.1),(template-type=wbem),(template-version=1.0),(template-description=This template describes the attributes used for advertising Pegasus CIM Servers.),(InteropSchemaNamespace=interop),(FunctionalProfilesSup ported=Basic Read,Basic Write, Schema Manipulation, Instance Manipulation,Association Traversal,Query Execution,Qualifier Declaration,Indications),(MultipleOperationsSupported=FALSE),(Aut henticationMechanismsSupported=Basic), (AuthenticationMechanismDes criptions=Basic), (CommunicationMechanism=CIM-XML), (ProtocolVersion=1.0) (Namespace=root/PG_Internal, interop, ro ot/cimv2, root, root/LsiArray13), (RegisteredProfilesSupported=SNIA: Server, SNIA:Array:Device Credentials, SNIA:Array:Software Update, DMTF:Physical Asset, SNIA:Array:Job Control,SNIA:Array:Generic Initiator Port,SNIA:Array:Physical Asset, SNIA:Array:Disk Sparing, SNIA:Array:Erasure, SNIA:Array:Storage Server Asymmetry, SNIA:Array:Software Inventory, SNIA:Array, SNIA:Array:Proxy Server Management,DMTF:Indication:Profile Registration, SNIA:Array:Access Points, SNIA:Array:Multiple Computer System, SNIA:Array:Block Services, SNIA:Array:Copy Services,SNIA:Array:Disk Drive Lite, SNIA:Array:Extent Composition,DMTF:Indication,DMTF:Physical Asset:Array,SNIA:Array:Masking and Mapping,DMTF:Software Update:Array, SNIA:Array:Indications, SNIA: Server:Indication, SNIA:A rray:Block Server Performance,DMTF:Software Update, SNIA: Profile Registration,SNIA:Server:Software,SNIA:SMI-S,SNIA:Array:Generic Target Ports,SNIA:Array:Storage Enclosure)
Similarly the attributes for the other components (e.g., switch, HBA, server, etc. may also be retrieved). The information collected may be used to define information for a master table. An example of a master table in a general format stored in the relational database 208 is shown in the following TABLE 1:
A second phase may build a configuration database (e.g., an initial backup operation). The plugin 200 may have the CIM client 204 built in (e.g., developed according to SMI 1.5 standards). The CIM client 204 may have the capability to issue CIM-XML requests 110 to the CIM services discovered in the discovery phase.
To retrieve the configuration details on the storage array 102, the client 204 may perform CIM operations on two or more classes of the following profiles. First, the client may retrieve details of the physical objects in the storage array (e.g., storage array details, drives, controllers, trays, ESMs, battery, host ports and drive ports) by enumerating appropriate classes from the storage array profile and/or a sub-profiles (e.g., disk drive, Physical Package, battery profile, FC Initiator and Target Port, and Disk Sparing respectively).
Next, the client 204 may then perform another set of enumeration and associated operations to retrieve the logical objects from the storage array 102 (e.g., storage pools, storage volumes, storage partitions, LUN mappings, snapshots, volume copies, remote volume mirrors, premium features, and Hot Spares, etc.) by enumerating appropriate classes in the storage array profiles and/or sub-profiles (e.g., Storage Array Profile, Block Services Profile, LUN Masking and Mapping Profile, Copy Services Profile, Disk Sparing Profile, etc.).
An example of a cim_computersystem class is shown below. The class definition listed may be same for all providers (e.g., storage array, switch and host). The vendor provider may populate the properties with a value(s) appropriate to the product.
To retrieve the configuration details for a host, the client 204 may perform the following operations to retrieve the configuration details. With respect to the physical objects in the host (e.g., HBA, Ports and Disks), the client 204 may perform enumeration operation on the classes in the FC HBA, Storage HBA and Host Discovered Resources Profiles. The logical configuration entities (e.g., Partition information, Persistent binding, logical storage resources) available through the OS and/or multipathing are retrieved by performing CIM operations on appropriate classes of the following profiles Disk Partition Profile, Storage HBA Profile, Host Discovered Resources Profile and SCSI Multipath Management Subprofile.
To retrieve the configuration details on the Fabric, the client 204 performs a series of CIM Operations on the classes of the following Profiles. The client 204 uses the following profiles to retrieve info about the physical entities of the switch (e.g., Switch details and Ports, Fabric profile, Switch profile, FDMI Subprofile, etc.). The logical entities (e.g., the configuration on the switch and/or zoning information) are retrieved by performing CIM Operations on the classes in the following profiles: Zone Control Subprofile, Enhanced Zone Control Subprofile, FDMI Subprofile and Fabric View Subprofile.
The data retrieved via the CIM Operations may be in the form of CIM XML responses stripped by the CIM XML analyzer 206 to obtain the raw data stored in the inbuilt relational database of the plugin 200. This creates a backup of the initial configuration in the database.
Referring to
Sample child tables may be implemented similar to the following examples. A particular implementation may decide which particular additional details are populated in the tables.
Similarly for the server/host also the following details can be captured.
Referring to
The blocks 404a-404n show examples of details of a particular device from the master table 402. For example, the block 404a may correspond to the “STORAGE” section of the master table 402. The table 404b may correspond to the column labeled “SWITCH” in the master table 402. The table labeled 404n may correspond to the column labeled “SERVER” or “HBA” in the master table 402. The table 404a shows particular parameters for the example of a storage device. For example, one column on the left shows the entry “MODEL”. The value on the right is shown as “49XX”. In general, each of the entries on the left column has a corresponding value on the right column. The TABLES 404b-404n provide additional details on the various components. The particular number of TABLES 404a-404n implemented may be varied to meet the design criteria of a particular implementation.
Referring to
Next, the method 500 moves to the state 532. The state 532 may determine whether the new and old configuration are the same. If so, the method 500 moves to the state 534. The state 534 generally takes no action and moves to a state 536 that ends the method 500. If the decision state 532 determines the new and old configuration are not the same, the method 500 moves to the state 538. The state 538 builds a CIM XML file. Next, the state 540 implements a build command. Next, the state 542 implements a CIM client send command. Next, the state 544 represents the last device to be analyzed. Next, the state 546 initiates a CIM XML response. Next, a decision state 548 determines whether a command component response is good. If not, the method 500 moves back to the state 538. If so, the method 500 moves to the state 550. The state 550 builds a CIM XML request. Next, a state 552 implements a device with CIM services. Next, the state 554 implements a CIM XML response. Next, the state 556 implements a CIM XML analyzer. Next, the state 558 strips the data from the responses. In parallel, a state 560 may extract configuration information from the database. Next, the state 562 determines if the configurations are the same. If not, the method 500 moves back to the state 538. If so, the method 500 moves to the state 564. The state 564 saves the data of the new configuration in the database. Next, the state 566 issues a restoration complete command. Next, the state 568 ends the process.
In an event of a device failure, a user may trigger the restoration procedure on the plugin 200. Another discovery session may be initiated where the plugin 200 queries the subnet for new devices. The discovery phase may return the URL of the CIM service and associated profiles the device has support for that can be used for restoration work. Using the URL obtained, the CIM client 204 may log into the device and via CIM XML requests retrieves device specific information from it. The CIM XML analyzer 206 may perform two operations here a) strip the raw data off the XML and b) queries the database 208 to retrieve the initially stored device specific details. The analyzer 206 may compare the URL and device types to figure out if the device is a new hardware device. If the URL/Device Type is the same the configuration details of the devices, a mismatch may occur. The configuration with the initially stored details the CIM XML analyzer may build a CIM command to recreate the objects on the new device.
The plugin 200 may create the logical objects based on the result of the comparison. For example, for a storage array, the plugin 200 may create the volume groups, volumes, snapshots, volume copies etc on the un-configured storage array. The same process may be followed for the other components.
The plugin 200 will not normally perform any firmware, driver, or BIOS upgrades on any of the components, although such upgrades are possible. The plugin 200 normally perform a comparison and report the mismatches. A user may use information from the plugin 200 to determine whether to perform upgrade. In certain cases, an automatic upgrade may be performed.
The CIM client 204 may execute the command on the device. If the particular CIM XML response 112 indicates a success, the CIM XML request module 110 builds another request to confirm if the object creation was successful on the device. The CIM client 204 may send the CIM XML request to the device. The CIM XML analyzer 206 may perform two tasks (a) capture the CIM XML response 112 and strip the raw data off the XML and (b) queries the database to retrieve the data stored initially.
The two configurations may be compared to see if they are substantially identical. If the comparison is a success, the database 208 may be updated with the new configuration. If the comparison fails, control returns to the point where the CIM client 204 issues commands to recreate the objects. If the comparison of the URL/device type fails, a new device is normally present and the device specific details would be captured and/or stored in the database 208. Subsequently, the configuration details of the new device would be compared with the initial data. The comparison normally fails if the new device does not have any configuration. The CIM XML analyzer 206 may proceed to create the CIM XML commands to create the objects based on the initial data and/or transfer control to the CIM Client to execute the request. If the CIM XML request fails with a bad response, the process of creating the command to create the objects on the device is re-initiated.
The following is a sample of a CIM XML Request. The CIM XML Analyzer module 206 may use the requests to develop the CIM command.
Below is a sample CIM XML response CIM XML analyzer 206 strips from the response received from the device provider.
These request and response samples are based on SNIA SMI standards which will used to create the components on the new configuration. The system 100 may be useful in any backup/restore environment when a user creates a system configuration similar to the backed up setup.
The functions performed by the diagrams of
The present invention may also be implemented by the preparation of ASICs (application specific integrated circuits), Platform ASICs, FPGAs (field programmable gate arrays), PLDs (programmable logic devices), CPLDs (complex programmable logic device), sea-of-gates, RFICs (radio frequency integrated circuits), ASSPs (application specific standard products), one or more monolithic integrated circuits, one or more chips or die arranged as flip-chip modules and/or multi-chip modules or by interconnecting an appropriate network of conventional component circuits, as is described herein, modifications of which will be readily apparent to those skilled in the art(s).
The present invention thus may also include a computer product which may be a storage medium or media and/or a transmission medium or media including instructions which may be used to program a machine to perform one or more processes or methods in accordance with the present invention. Execution of instructions contained in the computer product by the machine, along with operations of surrounding circuitry, may transform input data into one or more files on the storage medium and/or one or more output signals representative of a physical object or substance, such as an audio and/or visual depiction. The storage medium may include, but is not limited to, any type of disk including floppy disk, hard drive, magnetic disk, optical disk, CD-ROM, DVD and magneto-optical disks and circuits such as ROMs (read-only memories), RAMS (random access memories), EPROMs (electronically programmable ROMs), EEPROMs (electronically erasable ROMs), UVPROM (ultra-violet erasable ROMs), Flash memory, magnetic cards, optical cards, and/or any type of media suitable for storing electronic instructions.
The elements of the invention may form part or all of one or more devices, units, components, systems, machines and/or apparatuses. The devices may include, but are not limited to, servers, workstations, storage array controllers, storage systems, personal computers, laptop computers, notebook computers, palm computers, personal digital assistants, portable electronic devices, battery powered devices, set-top boxes, encoders, decoders, transcoders, compressors, decompressors, pre-processors, post-processors, transmitters, receivers, transceivers, cipher circuits, cellular telephones, digital cameras, positioning and/or navigation systems, medical equipment, heads-up displays, wireless devices, audio recording, storage and/or playback devices, video recording, storage and/or playback devices, game platforms, peripherals and/or multi-chip modules. Those skilled in the relevant art(s) would understand that the elements of the invention may be implemented in other types of devices to meet the criteria of a particular application.
While the invention has been particularly shown and described with reference to the preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made without departing from the scope of the invention.
