Active-active scale-out for unified data path architecture

A technique for processing IO requests in a data storage system provides active-active access to pooled data objects from multiple storage processors. Data objects, which may include both block-based objects and file-based objects, are realized in the form of respective files stored in a set of clustered internal file systems of the data storage system. For providing active-active access to a data object, each of multiple storage processors operates such a clustered file system, which coordinates with a clustered file system on each of the other storage processors to present a consistent file system image having a single namespace across all such storage processors. On each storage processor, the clustered file system is built upon a clustered storage pool, which maintains consistency with each of the clustered storage pools running on each of the other storage processors, to present a consistent image of storage allocation across all storage processors.

BACKGROUND

Data storage systems are arrangements of hardware and software that include storage processors coupled to arrays of non-volatile storage devices. In typical operation, the storage processors service IO (Input/Output) requests that arrive from hosts. The IO requests specify files or other data elements (e.g., block-based data) to be written, read, created, or deleted, for example. The storage processors each run software that manages incoming storage requests and perform various data processing operations to organize and secure user data stored on the non-volatile storage devices.

Storage processors commonly operate in one of two modes: active-passive or active-active. In active-passive mode, one storage processor (“SP”) of a data storage system operates as an active SP and handles data processing tasks associated with servicing IO requests directed to a particular data object. Other SPs of the data storage system operate in passive mode. Such other SPs may receive IO requests directed to the data object but do not process them. Rather, the other SPs forward the IO requests to the active SP, which processes the IO requests to effect data operations on the data object, such as reading and writing. In active-active mode, by contrast, multiple SPs of a data storage system can process IO requests to effect data operations on the same data object. No forwarding of IO requests is required, and multiple SPs can perform operations on the same data object at the same time.

Certain conventional data storage systems provide active-active access to LUNs (logical unit numbers—although the acronym also describes the storage units themselves). Such LUNs are formed from RAID groups (RAID is an acronym for Redundant Array of Independent Disks) derived from non-volatile storage devices, such as magnetic disk drives, electronic flash drives, optical drives, and the like. Multiple SPs in a data storage system can access such LUNs to service read and write IO requests arriving at the data storage system simultaneously.

SUMMARY

Active-active arrangements provide advantages over active-passive ones in terms of both performance and ease of management. Performance of active-active arrangements tends to be higher because such arrangements benefit from parallel processing among multiple SPs. Also, storage management in active-active arrangements tends to be easier because administrators do not have to consider whether an SP is active or passive when configuring, deploying, and maintaining a data storage system, as all SPs in an active-active arrangement generally have the same capabilities.

Unfortunately, however, conventional active-active arrangements provide limited features. For example, the above-described conventional approach works only with fixed-sized LUNs. It does not work for pooled LUNs, whose sizes can be dynamically changed. Thus, the conventional active-active approach does not allow customers to benefit from the added value of pooled LUNs.

Also, efforts are underway to develop data storage systems having IO stacks with unified data paths for providing access to both block-based objects (e.g., LUNs and block based vVOLs—virtual volumes) and file-based objects (e.g., file systems and file-based vVOLs). Such IO stacks internally realize both block-based objects and file-based objects in the form of files, which belong to a set of underlying file systems.

What is desired is an active-active solution that leverages the unified data path to provide active-active access to both block-based objects and file-based objects and thus overcomes limitations in the prior approach.

In contrast with the above-described conventional active-active approach, which operates only with fixed-size LUNs, an improved technique provides active-active access to pooled data objects from multiple storage processors. Data objects, which may include both block-based objects and file-based objects, are realized in the form of respective files stored in a set of clustered internal file systems of the data storage system. For providing active-active access to a data object, each of multiple storage processors operates such a clustered internal file system, which coordinates with a clustered internal file system on each of the other storage processors to present a consistent file system image having a single namespace across all such storage processors. On each storage processor, the clustered internal file system is built upon a clustered storage pool, which maintains consistency with each of the clustered storage pools running on each of the other storage processors, to present a consistent image of storage allocation across all storage processors. The resulting arrangement thus allows each storage processor to access both block-based data objects and file-based data objects in an active-active manner, while maintaining consistency across all storage processors and allowing customers to benefit from the advantages of pooled data objects.

Certain embodiments are directed to a method of processing IO requests in a data storage system. The method includes operating, on each of a first storage processor and a second storage processor of the data storage system, a clustered storage pool, each clustered storage pool provisioning storage units to data objects and maintaining consistency such that changes to a clustered storage pool on one of the storage processors are reflected in the clustered storage pool on the other of the storage processors. The method further includes operating, on each of the first storage processor and the second storage processor, a clustered file system presenting a single namespace shared between the first storage processor and the second storage processor, the clustered file system provisioned with storage units from the storage pool and storing a data object realized in a form of a file of the clustered file system. The method still further includes, in response to receiving IO requests, providing read and write access to the data object by both the first storage processor and the second storage processor in an active-active arrangement.

Other embodiments are directed to a data storage system constructed and arranged to perform the method described above. Still other embodiments are directed to a computer program product. The computer program product stores instructions, which when executed by control circuitry of a data storage system, cause the control circuitry to perform the method described above. Some embodiments involve activity that is performed at a single location, while other embodiments involve activity that is distributed over a computerized environment (e.g., over a network).

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the invention will now be described. It is understood that such embodiments are provided by way of example to illustrate various features and principles of the invention, and that the invention hereof is broader than the specific example embodiments disclosed.

An improved technique provides active-active access to both pooled block-based data objects and pooled file-based data objects from multiple storage processors of a data storage system.

FIG. 1shows an example environment100in which embodiments of the improved technique hereof can be practiced. Here, multiple host computing devices (“hosts”), shown as devices110(1) through110(N), access a data storage system116over a network114. The data storage system116includes a first storage processor (“SPA”)120a, a second storage processor (“SPB”)120b, and storage180. The storage180is provided, for example, in the form of hard disk drives and/or electronic flash drives. In an example, such drives are dual-ported to provide fault tolerance and to better support active-active access from multiple sources. In an example, the SPs120aand120bare provided as circuit board assemblies, or “blades,” which plug into a chassis that encloses and cools the SPs. The chassis has a backplane for interconnecting the SPs, and additional connections may be made among SPs using cables. For instance, cable150provides a high-speed interconnect between SP120aand SP120b, using CMI or PCI Express, for example. It is understood that no particular hardware configuration is required, however, as any number of SPs can be provided and the SPs can be any type of computing device capable of processing host IOs.

The network114can be any type of network or combination of networks, such as a storage area network (SAN), local area network (LAN), wide area network (WAN), the Internet, and/or some other type of network, for example. In an example, the hosts110(1-N) connect to the SP120using various technologies. For example, the host110(1) connect to the SP120using Fibre Channel (e.g., through a SAN). The hosts110(2-N) connect to the SP120using TCP/IP, to support, for example, iSCSI, NFS, SMB 3.0, and CIFS. Any number of hosts110(1-N) may be provided, using any of the above protocols, some subset thereof, or other protocols besides those shown. As is known, Fibre Channel and iSCSI are block-based protocols, whereas NFS, SMB 3.0, and CIFS are file-based protocols. In an example, each of the SPs120aand120bis configured to receive IO requests112(1-N) according to both block-based and file-based protocols and to respond to such IO requests112(1-N) by reading or writing the storage180in an active-active mode.

The SPs120aand120bmay be similarly configured. Each of the SPs120aand120bis seen to include one or more communication interfaces122, a set of processing units124, and memory130. The communication interfaces122include, for example, adapters, such as SCSI target adapters and network interface adapters, for converting electronic and/or optical signals received from the network114to electronic form for use by the respective SP. The set of processing units124include one or more processing chips and/or assemblies. In a particular example, the set of processing units124includes numerous multi-core CPUs. The memory130includes both volatile memory (e.g., RAM), and non-volatile memory, such as one or more ROMs, disk drives, solid state drives, and the like. The set of processing units124and the memory130together form control circuitry, which is constructed and arranged to carry out various methods and functions as described herein. Also, the memory130includes a variety of software constructs realized in the form of executable instructions. When the executable instructions are run by the set of processing units124, the set of processing units124are caused to carry out the operations of the software constructs. Although certain software constructs are specifically shown and described, it is understood that the memory130typically includes many other software constructs, which are not shown, such as various applications, processes, and daemons.

As shown, the memory130includes an operating system134, such as Unix, Linux, or Windows™, for example. The memory130further includes a container132. In an example, the container132is a software process that provides an isolated userspace execution context within the operating system134. In various examples, the memory130may include multiple containers like the container132, with each container providing its own isolated userspace instance. Although containers provide isolated environments that do not directly interact (and thus promote fault containment), different containers can run on the same kernel (not shown) and can communicate with one another using inter-process communication (IPC) mediated by the kernel. Containers are well-known features of Unix, Linux, and other operating systems.

In the example ofFIG. 1, each of the SPs120aand120bis seen to include only a single container132. An IO stack140running within the container132on each of the SPs120aand120bprovides an execution path for host IOs (e.g., IO requests112(1-N)). The IO stack140includes a front end142and a back end144. In alternative arrangements, the back end144is located on another SP (e.g., in a modular arrangement) or is provided in a block-based array connected to the SPs120aand120b(e.g., in a gateway arrangement).

In an example, the storage180stores data blocks that make up data objects, such as LUNs, host file systems, vVOLs, VMDKs, VHDs, and so forth. The back end144on each of the SPs120aand120bperforms, inter alia, caching and RAID operations to support active-active operation. Coordination among back ends144is achieved by communicating among back ends144of the SPs120aand120b(e.g., via logical path160) to maintain cache coherency and coherency in RAID operations and thus to ensure that the back ends144operate together in a consistent manner. The front end142on each of the storage processors120aand120bperforms, inter alia, caching, pooling, file system, and mapping operations to support active-active operation. Coordination among front ends142is achieved by communicating among front ends142of the SPs120aand120b(e.g., via logical path156) to ensure that the front ends142operate together in a consistent manner. Physical communication over the logical paths156and160may take place over the interconnect150or through some other means, such as over a backplane, over the network114, and/or over some other network.

In operation, the hosts110(1-N) issue IO requests112(1-N) to the data storage apparatus116. The IO requests112(1-N) may include both block-based requests and file-based requests. The SPs120aand120beach receive the IO requests112(1-N) (or some subset of them) at the communication interfaces122and pass the IO requests to the respective IO stack140for further processing. At the front end142, processing may include mapping IO requests directed to LUNs, host file systems, vVOLs, VMDKs (virtual memory disks), and other data objects to respective files stored in a set of internal file systems of the data storage system116. Host IO requests for reading and writing block-based objects and file-based objects are thus converted to reads and writes of respective files. After processing by the front end142of each SP, the IO requests propagate to the back end144of the respective SP, where the back end144executes commands for reading and/or writing the storage180, agnostically to whether the data read and/or written is directed to a block-based object or a file-based object.

SPs120aand120bcan process IO requests directed to data objects in an active-active manner. For example, each of the SPs120aand120bmay receive and process read and write operations directed to the same data object at the same time. Neither of the SPs120aand120bis the exclusive owner of the data object; rather, both SPs120aand120bhave access to the data object and have the ability to perform data processing activities to service IO requests directed to the data object. Performance in this active-active arrangement is generally better than performance in active-passive schemes, which require a single SP to perform all data processing for a particular data object. Here, however, both SPs120aand120bmay operate in parallel to process IO requests directed to the same data object. Also, administrators benefit because they need not have to consider whether an SP is active and therefore optimized for use, or whether the SP is passive, and therefore not optimized for use (as IO requests must be forwarded). Configuration, deployment, and maintenance of data storage systems employing this active-active arrangement are therefore simplified.

FIG. 2shows an example front end142and back end144of the IO stack140in additional detail. Here, the front end142is seen to include protocol end points220, object-volume mapping224, volume-file mapping228, lower-deck (internal) file systems230, a storage pool232, a unified system cache234, and a basic volume interface236. The back end144is seen to include a host side adapter250, a RAID manager252, a back-end cache254, and hard disk drive/electronic flash drive support256.

At the back end144, the hard disk drive/electronic flash drive support256includes drivers that perform the actual reading from and writing to the storage180. The back-end cache254performs block-level caching of data of IO requests112. The RAID manager252accesses particular storage units (e.g., slices) written or read using RAID protocols. The host side adapter250provides an interface to the front end142, for instances in which the front end142and back end144are run on different machines or in different containers. When the front end142and back end144are co-located on the same SP, as they are inFIG. 1, the host side adapter250may be omitted or made to perform no operation.

The above-described features of the back end144are configured to support active-active access for reading from and writing to data objects stored in the storage180from multiple SPs. For example, the RAID manager252and back-end cache254on each SP are constructed and arranged to maintain consistency with the RAID manager252and back end-cache254on the other SP (or on multiple other SPs, in some arrangements). The back end144on each of the SPs communicates with the back end144of one or more other SPs (e.g., over logical connection160) to provide consistent metadata and to provide coordinated mirroring, locking, serializing, and/or other access control features, to ensure that each back end144participating in the active-active arrangement has a consistent view the RAID groups, FLUs, and back-end cache254of the data storage system116.

Continuing to the front end142, the basic volume interface236provides an interface to the back end144for instances in which the front end142and the back end144are run on different hardware or in different containers. The basic volume interface236may be inactive when the front end142and the back end144are co-located, as in the arrangement shown inFIG. 1.

The unified system cache234provides caching services for data stored in the lower-deck file systems230. In some examples, the unified system cache234directs data specified by host writes to local RAM or flash memory and thus avoids the need to access the storage180, which is typically more remote than local RAM or flash memory and takes more time to access. In some examples, the unified system cache234also directs data returned in response to read IO requests to be stored in local RAM or flash memory for fast access in the event that subsequent host IO requests require the same data. In some examples, local RAM or flash memory may store the only valid copy of host data, with writes to the storage180being deferred and, in cases where host data needs to be stored only transiently, avoided altogether.

The storage pool232organizes units of storage in the form of slices. A “slice” is a unit of storage space, such as 256 MB or 1 GB in size, which is derived from the storage180. The pool232may allocate slices to lower-deck file systems230for use in storing their files. The pool232may also deallocate slices from lower-deck file systems230if storage provided by previously allocated slices is no longer required. In an example, the storage pool232creates slices by accessing RAID groups formed by the RAID manager252, dividing the RAID groups into FLUs (Flare LUNs), and further dividing the FLUs to form the slices.

The lower-deck, or “internal” file systems230are built upon slices managed by a storage pool232and represent both block-based objects and file-based objects internally in the form of files of the file systems230. The data storage system116may host any number of lower-deck file systems230, and each lower-deck file system may include any number of files. In a typical arrangement, a different lower-deck file system is provided for each data object to be stored. Each lower-deck file system includes one file that stores the data object itself and in some instances includes other files that store snaps of the file that stores the data object. Each lower-deck file system230has an inode table. The inode table provides a different inode for each file stored in the respective lower-deck file system. The inode table may also store properties of the file(s), such as their ownership and block locations at which the file's/files' data are stored.

The volume-file mapping228maps each file representing a data object to a respective volume, which is accessible using block-based semantics. The volume-file mapping can be achieved in a variety of ways. According to one example, a file representing a data object is regarded as a range of blocks (e.g., 8K allocation units), and the range of blocks can be expressed as a corresponding range of offsets into the file. Because volumes are accessed based on starting location (logical unit number) and offsets in the volume, the volume-file mapping228can establish a one-to-one correspondence between offsets into the file and offsets into the corresponding internal volume, thereby providing the requisite mapping needed to express the file in the form of a volume.

The object-volume mapping layer224maps internal volumes to respective data objects, such as LUNs, host file systems, and vVOLs, for example. Mapping underlying volumes to host-accessible LUNs may simply involve a remapping operation from a format compatible with the internal volume to a format compatible with the LUN. Mapping internal volumes to host file systems, however, may be accomplished in part by leveraging from the fact that file systems are customarily built upon volumes, such that an underlying volume is part of the structure of a host file system. Host file systems, also called “upper-deck file systems,” are thus built upon the internal volumes presented by the volume-file mapping228to provide hosts with access to files and directories. Mapping of vVOLs can be achieved in similar ways. For block-based vVOLs, the object-volume mapping layer224may perform mapping substantially as it does for LUNs. File-based vVOLs may be mapped, for example, by converting host-specified offsets into vVOL files to corresponding offsets into internal volumes.

The protocol end points220expose the underlying data objects to hosts in accordance with respective protocols for accessing the data objects. Thus, the protocol end points220may expose block-based objects (e.g., LUNs and block-based vVOLs) using Fiber Channel or iSCSI and may expose file-based objects (e.g., host file systems, file-based vVOLs, and VMDKs) using NFS, CIFS, or SMB 3.0, for example.

FIG. 3shows portions of the front end142in additional detail. Here, data objects include a LUN310and an HFS (host file system)312. The object-volume mapping224includes a LUN-to-Volume mapping320and an HFS-to-Volume mapping322. The LUN-to-Volume mapping320maps the LUN310to a first volume324, and the HFS-to-Volume mapping322maps the HFS312to a second volume326. The Volume-to-File mapping228maps the first and second internal volumes324and328to respective files336(F1) and346(F2) in respective lower-deck files systems330and340. Through the various mappings, any set of blocks of the LUN310specified in an IO request112is mapped to a corresponding set of blocks within the first file336. Similarly, any file or directory of the HFS312specified in an IO request112is mapped to a corresponding set of blocks within the second file346. It is understood that the files336and346may be quite large to accommodate the sizes of the data objects they store.

The lower-deck file system330includes an inode table332, and the lower-deck file system340includes an inode table342. An inode334provides file-specific information about the first file336, and an inode344provides file-specific information about the second file346. The information stored in each inode includes location information (e.g., block locations) where data of the respective file are stored.

As shown, the storage pool232allocates slices360for providing storage for the first file336and for the second file346. Here, slices S1 through S4 store the data of the first file336, and slices S5 through S7 store the data of the second file346. The data that make up the LUN310are thus stored in the slices S1 through S4, whereas the data that make up the HFS312are stored in the slices S5 through S7. In some examples, the storage pool232causes free slices350to become allocated slices360, e.g., in response to additional storage demands in file F1 or F2. Likewise, the storage pool232may cause allocated slices360to become free slices350, e.g., in response to a reduction in the size of file F1 or F2.

The above-described features of the front end142are configured to support active-active access for reading from and writing to data objects by multiple SPs. For example, the front end142on each of the SPs communicates with one or more other front ends142(e.g., over the logical connection156) to maintain consistency across unified system caches234, storage pools232, and lower-deck file systems230(see alsoFIG. 2). In an example, the unified system cache234on each SP communicates with the unified system cache234on one or more other SPs to maintain cache coherency. Also, the storage pool232operates in a clustered manner with the storage pool232running on each of one or more other SPs to maintain a consistent view of slice allocation and metadata across all of such SPs, such that changes in a storage pool232on one SP are reflected in the storage pool232on each of the other such SPs. Further, the lower-deck file systems230operate in a clustered manner across multiple SPs to provide a consistent file system image having a single namespace for each lower-deck file system accessed in active-active mode.

In some examples, the object-volume mapping224also operates in a clustered arrangement. For example, if a data object being accessed in active-active mode is a host file system, then the object-volume mapping224provides not only mapping to an underlying volume (and file) but also the features needed by hosts to access and use the host file system. To support active-active access to the host file system from multiple SPs, the object-volume mapping224further provides file system clustering. Such file system clustering presents a consistent view of the host file system to hosts, regardless of which SP is used to access the host file system. It should be noted that clustering described above for lower-deck file systems is not enough to support active-active access to host file systems. Clustering lower-deck file system supporting host file systems promotes consistency among different SPs at the internal file system level but does not address the need for consistency at the upper deck. Rather, the upper-deck, host file system should itself also be clustered to provide hosts with a single image of the host file system having a single namespace that is consistent across all SPs. To effect clustering of upper-deck file systems, the object-volume mapping224on the front end142of each SP accessing the host file system in active-active mode communicates (e.g., over the logical connection156) with each of the other such SPs to provide coordinated mirroring, locking, serializing, and/or other access control features to ensure consistency across all such SPs.

As described hereinabove, two SPs120aand120bare configured to provide active-active access to data objects (e.g., LUN 1 and HFS 1) hosted from an IO stack140that realizes both block-based objects and file-based objects as underlying files (e.g.,336and346) in a set of internal (lower-deck) file systems230. However, the number of SPs that participate in an active-active arrangement need not be limited to two and can be extended with the addition of more storage processors to the data storage system116.

FIG. 4shows an example arrangement400for providing active-active access to a data object in storage180using six SPs. Here, four of the SPs (420athrough420d) run IO stack front ends142(with no back ends144) and two of the SPs (420eand420f) run IO stack back ends144(with no front ends142). The SPs420athrough420fmay otherwise be configured in a manner similar to the SPs120aand120bshown inFIG. 1. The SPs420aand420bform a functional pair connected via a high-speed interconnect150. Functional pairs of SPs are also formed between SPs420cand420d, and between SPs420eand420f, with an interconnect150provided between the SPs of each pair. A high speed network450, such as InifinBand, is used to interconnect front end SPs420athrough420dthat belong to different pairs. The SPs420athrough420drunning front ends142are also connected to the SPs420eand420fvia a switch fabric414, which allows any of the SPs420a,420b,420c, and420d(i.e., any of the “front-end SPs”) to be selectively connected to any of the SPs420eand420f(i.e., any of the “back-end SPs”).

In operation, the front-end SPs420a-420dreceive IO requests112specifying data to be written to and/or read from a particular data object. The front ends142running on the SPs420a-420dperform front-end processing in response to receiving the IO requests112. The front-end processing includes performing clustering activities, such as coordinating among the unified system caches234of the SPs420a-420dto maintain cache coherency, coordinating among the storage pools232to maintain a single, consistent view of slice allocation, coordinating among the lower-deck file systems230hosting the data object to provide a single file system image having a single namespace shared among the SPs120a-120d, and (when the object is a host file system) coordinating among the object-volume mapping224to provide a single host file system image (at the upper deck) having a single namespace shared among the SPs420a-420d. Such coordination among front-end SPs420a-420dtakes place over the logical connection156using physical interconnects150for SPs in the same pair and/or using the high-speed network450for SPs in different pairs. Once the front end SPs120a-120dhave processed the IO requests112, the front end SPs420a-420dtransmit modified versions of the IO requests to the back-end SPs420eand420fthrough the switch fabric414in a block-based protocol, such as Fibre Channel or iSCSI.

The back-end SPs420eand420freceive the block-based versions of the IO requests from the front-end SPs and further process the requests to effect read and/or write operations on the data object in the storage180. Such processing includes coordinating between the RAID manager252on SP420eand the RAID manager252on SP420fto ensure that both back-end SPs420eand420fmaintain the same view of RAID groups and FLUs. Such processing also includes coordinating between the back-end cache254on SP420eand the back-end cache254on SP420fto maintain cache coherency across both back-end SPs420eand420f.

With the arrangement ofFIG. 4, any of the front end SPs420a-420dcan process IO requests112directed to a data object, without some SPs needing to forward IO requests to other SPs, as is needed in active-passive arrangements. Rather, the SPs420a-420dcan process IO requests112in parallel. Once a front-end SP processes an IO request, the front-end SP can direct the switch fabric414to switch the resulting modified IO request to any of the back-end SPs, for further processing and writing to the storage180. As with the front-end SPs420a-420d, the back-end SPs420eand420fcan also process IO requests in parallel.

Although the arrangement ofFIG. 4is shown with four front-end SPs420a-420dand two back-end SPs420eand420f, it is understood that the number of SPs provided in the front end and in the back end can vary depending on expected load and other considerations. In an example, additional front-end SPs are added to the arrangement400. Such additional SPs connect to the currently-shown front-end SPs, e.g., over the high-speed network450, for maintaining consistency among front ends144. The additional SPs also connect to the switch fabric414for sending block-based versions of IO request to the back-end SPs. The number of back-end SPs can also be increased. For example, additional SP pairs running back ends144can be added, with added SP pairs connecting to the currently-shown back-end SPs over a high-speed network, e.g., similar to the network450.

In another arrangement (not shown), multiple front-end SPs can be connected to a back-end array, such as a VMAX array, in a gateway arrangement, where the back-end array includes one or more internal back ends like the back end144. In an example, the front-end SPs operate as described above in connection with the front-end SPs ofFIG. 4. If the back-end array operates a single back end, then no coordination is needed among different back-ends. Rather, the back-end running on the array may serialize and process arriving block-based versions of IO requests in the order received. If the back-end array operates multiple back ends, then coordination among such back ends144within the array may proceed as described above in connection with multiple back-end SPs.

It should be understood that the arrangement ofFIG. 4(as well as that described in connection withFIG. 1), can process IO requests112for different data objects, and that such IO requests can be processed at the same time. For example, the arrangements shown inFIGS. 1 and 4can each receive a first set of IO requests directed to a pooled LUN (e.g., LUN 1 ofFIG. 3) and a second set of IO requests directed to a host file system (e.g., HFS 1 ofFIG. 3). Further, other sets of IO requests can be directed to block-based vVOLs, file-based vVOLs, VMDKs, VHDs, and so forth. Different data objects are mapped to different lower-deck files (and usually to different lower-deck file systems230). The front ends142of all SPs that provide front-end active-active processing coordinate with one another to maintain consistency in front-end operations, and the back ends144of all SPs that provide back-end active-active processing coordinate with one another to maintain consistency in back-end operations. Thus, the SPs in any of the arrangements above can provide active-active access to multiple data objects at the same time.

FIG. 5shows an example process500for processing IO requests in a data storage system. In an example, the process500is performed by the SPs120aand120b, or by the SPs420a-420f, using the software constructs described in connection withFIGS. 1-3.

At step510, a clustered storage pool is operated on each of a first storage processor and a second storage processor of the data storage system. Each clustered storage pool provisions storage units to data objects and maintains consistency such that changes to a clustered storage pool on one of the storage processors are reflected in the clustered storage pool on the other of the storage processors. For example, each of the SPs120aand120bruns a storage pool232. The storage pool232provisions storage units (e.g., slices360) to data objects (e.g., pooled LUN310or HFS312) and operates in a clustered manner to maintain consistency across the SPs120aand120bsuch that changes to a storage pool232on one of the storage processors (e.g.,120a) are reflected in the storage pool232on the other of the storage processors (e.g.,120b).

At step512, a clustered file system is operated on each of the first storage processor and the second storage processor. The clustered file system presents a single namespace shared between the first storage processor and the second storage processor. The clustered file system is provisioned with storage units from the storage pool and stores a data object realized in a form of a file of the clustered file system. For example, a clustered lower-deck file system (e.g., one of the file systems230) is operated on both SP120aand SP120b. The lower-deck file system presents a single file system image having a single namespace to be SP120aand SP120b. The lower-deck file system is provisioned with storage units (e.g., slices360) from the storage pool232and stores a data object (e.g., a LUN310or an HFS312) realized in the form of a file (e.g., a file336or a file346) of the lower-deck file system.

At step514, in response to receiving IO requests, read and write access is provided to the data object by both the first storage processor and the second storage processor in an active-active arrangement. For example, in response to IO requests112, SP120aand SP120beach provide read and/or write access to the data object (e.g., LUN310or an HFS312) in an active-active arrangement, where both storage processors SP120aand SP120boperate to service IO requests112in parallel.

An improved technique has been described that provides active-active access to pooled data objects from multiple storage processors. Data objects, which may include both block-based objects (e.g., LUN310) and file-based objects (e.g., HFS312), are realized in the form of respective files (e.g.,336and346) stored in a set of clustered internal file systems (230) of the data storage system (116). For providing active-active access to a data object, each of multiple storage processors (e.g.,120a,120b) operates such a clustered internal file system (230), which coordinates with a clustered internal file system (230) on each of the other storage processors to present a consistent file system image having a single namespace across all such storage processors. On each storage processor, the clustered internal file system (230) is built upon a clustered storage pool (232), which maintains consistency with each of the clustered storage pools (232) running on each of the other storage processors, to present a consistent image of storage allocation across all storage processors. The resulting arrangement thus allows each storage processor to access both block-based data objects and file-based data objects in an active-active manner, while maintaining consistency across all storage processors and allowing customers to benefit from the advantages of pooled data objects.

As used throughout this document, the words “comprising,” “including,” and “having” are intended to set forth certain items, steps, elements, or aspects of something in an open-ended fashion. Although certain embodiments are disclosed herein, it is understood that these are provided by way of example only and the invention is not limited to these particular embodiments. In addition, the word “set” as used herein indicates one or more of something, unless a statement is made to the contrary.

Having described certain embodiments, numerous alternative embodiments or variations can be made. For example, the improvements or portions thereof may be embodied as a non-transient computer-readable storage medium, such as a magnetic disk, magnetic tape, compact disk, DVD, optical disk, flash memory, Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), and the like (shown by way of example as medium550inFIG. 5). Multiple computer-readable media may be used. The medium (or media) may be encoded with instructions which, when executed on one or more computers or other processors, perform methods that implement the various processes described herein. Such medium (or media) may be considered an article of manufacture or a machine, and may be transportable from one machine to another.

Further still, although features are shown and described with reference to particular embodiments hereof, such features may be included in any of the disclosed embodiments and their variants. Thus, it is understood that features disclosed in connection with any embodiment can be included as variants of any other embodiment, whether such inclusion is made explicit herein or not.