Abstract: A system for ensuring availability using volume server sets in a storage environment employing distributed block virtualization includes a plurality of volume servers, one or more volume clients, one or more physical block devices and a volume server manager. The volume server manager may be configured to designate the plurality of volume servers as a volume server set with an associated volume server set management policy, and to verify each volume server in the volume server set has access to storage within each block device. In addition, the volume server manager may be configured to designate a first volume server of the volume server set to aggregate storage within the block devices into a logical volume, to make the logical volume accessible to the volume clients, and to share configuration information about the volume with the other volume servers of the volume server set.

Abstract: Systems, methods, apparatus and software can configure, support, and make use of a coordinator virtual device to determine which node or nodes of a cluster should be ejected from the cluster as a result of a cluster partition or other error event. Fencing software operating on the cluster nodes monitors the cluster for a cluster partition (split-brain) event, and when such an event occurs, software on the nodes attempts to gain control of the coordinator virtual device. A node that succeeds in gaining control of the coordinator virtual device survives. Nodes failing to gain control of the coordinator virtual device remove themselves or are removed from the cluster. The coordinator virtual device can be established by a virtual device configuration server which provides coordinator virtual device access to cluster nodes acting as virtual device configuration clients.

Abstract: Systems, methods, apparatus and software can make use of separated I/O processors and strategy processors (implemented in hardware and/or software) to perform virtual device I/O operations. I/O processors operating on cluster nodes, storage appliance ports, or other devices can receive I/O operation requests directed to virtual devices, e.g., volumes or virtual logical units. Information about the request is forwarded to a strategy processor, operating independently or as part of larger volume management software where corresponding physical device I/O operations are determined. The physical device I/O operations can include additional information about the operations, e.g., tag information and summary information, for use in processing the virtual device I/O request. The physical device I/O operations are sent back to the I/O processor which executes the operations and/or passes the operation on to the appropriate storage device.

Abstract: System and method for resynchronizing mirrored volumes in a storage system. According to one embodiment, a system may include a first volume located at a primary site and associated with a first storage management device, and a second volume located at a secondary site and associated with a second storage management device, where the secondary site is coupled to the primary site via a data link, and where the second volume is configured as a mirror of the first volume. The first storage management device may be configured to convey to the second storage management device an indication of a data block written to the first volume subsequent to a failure of the data link. Dependent upon the indication, the second storage management device may be configured to create a snapshot of the data block as stored on the second volume prior to resynchronization of the data block.

Abstract: A system employing asymmetric distributed block virtualization includes a volume server, a plurality of volume clients, and one or more physical block devices. The volume server aggregates storage in the physical block devices into a logical volume and makes the logical volume accessible to the volume clients for input/output (I/O) operations. In order to manage different I/O access requirements (such as read-only access versus read-write access) of the volume clients, the volume server maintains a different I/O access policy for each volume client to control the kinds of input/output operations that the volume client is allowed to perform on the logical volume.

Abstract: A method, computer program product, computer system and system that enable symmetrical data change tracking with respect to a set of data and a copy of the set of data, referred to as a snapshot or a second set of data. The data and the copy may be independently updated after the two sides are “split.” A join may be performed of the two sides of the split to resynchronize the data. For the first set of data, an accumulator map tracks changes to the first set of data and a volume map tracks changes to the first set of data with respect to a second set of data. For the second set of data (the snapshot), a second accumulator map tracks changes to the second set of data and a second volume map tracks changes to the second set of data with respect to the first set of data.

Abstract: After a first device (e.g., a host node in a shared data clustered system that stores a two-way mirrored volume) in a network creates or modifies a description of a layout for a data volume, the first device transmits separate copies of the data volume layout description to a pair of second devices, respectively, for storage in respective memories thereof. The first device may be a host node, and the pair of second devices may be first and second data storage systems. The first device and the pair of second devices are configured so that I/O transactions are transmitted between the first device and either of the pair of second devices. In other words, the first device is contained in a network layer that is different from the network layer that contains the pair of second devices.

Abstract: Systems and methods for storage area network switch port failure recovery. A system may include several hosts, storage devices and a storage area network (SAN) switch. The SAN switch may include several ports, where each host is coupled to a respective host port and each storage device is coupled to a respective storage port. The SAN switch may also include virtualization logic configured to map several of the storage devices as a volume presented to the hosts via the respective host ports, and an input/output (I/O) tracking mechanism configured to store information about write operations in progress at each of the ports. In response to a failure of a given port occurring while write operation(s) to the volume received via one or more of the respective host ports are in progress, the SAN switch may be configured to initiate consistency recovery of the volume using the stored information.

Abstract: A system employing asymmetric distributed block virtualization includes a volume server, a plurality of volume clients, and one or more physical block devices. The volume server aggregates storage in the physical block devices into a logical volume and makes the logical volume accessible to the volume clients for input/output (I/O) operations. In order to manage different I/O access requirements (such as read-only access versus read-write access) of the volume clients, the volume server maintains a different I/O access policy for each volume client to control the kinds of input/output operations that the volume client is allowed to perform on the logical volume.

Abstract: A system for managing input/output (I/O) errors in a storage system employing asymmetric distributed block virtualization includes a volume server, a plurality of volume clients, and one or more physical block devices. The volume server aggregates storage in the physical block devices into a logical volume and makes the logical volume accessible to the volume client. A designated route may be used to send I/O requests from the volume client to a physical block device during normal operation. If the volume client loses connectivity on the designated route, the volume client may route an I/O request to the physical block device via an alternate route. In one specific embodiment, the volume client may route an I/O request to the physical block device via the volume server.

Abstract: Systems, methods, apparatus and software can make use of separated I/O processors and strategy processors (implemented in hardware and/or software) to perform virtual device I/O operations. I/O processors operating on cluster nodes, storage appliance ports, or other devices can receive I/O operation requests directed to virtual devices, e.g., volumes or virtual logical units. Information about the request is forwarded to a strategy processor, operating independently or as part of larger volume management software where corresponding physical device I/O operations are determined. The physical device I/O operations can include additional information about the operations, e.g., tag information and summary information, for use in processing the virtual device I/O request. The physical device I/O operations are sent back to the I/O processor which executes the operations and/or passes the operation on to the appropriate storage device.

Abstract: A method, computer program product, computer system and system that enable symmetrical data change tracking with respect to a set of data and a copy of the set of data, referred to as a snapshot or a second set of data. The data and the copy may be independently updated after the two sides are “split.” A join may be performed of the two sides of the split to resynchronize the data. For the first set of data, an accumulator map tracks changes to the first set of data and a volume map tracks changes to the first set of data with respect to a second set of data. For the second set of data (the snapshot), a second accumulator map tracks changes to the second set of data and a second volume map tracks changes to the second set of data with respect to the first set of data.

Abstract: Systems, methods, apparatus and software can make use of separated I/O processors and strategy processors (implemented in hardware and/or software) to perform virtual device I/O operations. I/O processors operating on cluster nodes, storage appliance ports, or other devices can receive I/O operation requests directed to virtual devices, e.g., volumes or virtual logical units. Information about the request is forwarded to a strategy processor, operating independently or as part of larger volume management software where corresponding physical device I/O operations are determined. The physical device I/O operations can include additional information about the operations, e.g., tag information and summary information, for use in processing the virtual device I/O request. The physical device I/O operations are sent back to the I/O processor which executes the operations and/or passes the operation on to the appropriate storage device.