System and method for secure multi-tenancy in an operating system of a storage system

Exemplary methods for providing secure multi-tenancy in a Purpose Built Backup Appliance include creating a set of tenant-units (TUs), associating file system management objects (FSMOs) and users with the TUs. The methods further include maintaining a protocol config-metadata store based on the association of the FSMOs and users with the TUs. In one embodiment, in response to a first request from a first user to access a first FSMO of a first TU, the methods include determining whether the first user is authorized to access the first FSMO based on information of the protocol config-metadata store, and in response to the protocol config-metadata store indicating the first user is authorized to access the first FSMO, allowing the first user to access the first FSMO.

FIELD

Embodiments of the present invention relate generally to data storage systems. More particularly, embodiments of the invention relate to providing secure multi-tenancy at a Purpose Built Backup Appliance (PBBA).

BACKGROUND

Multi-tenancy refers to a technology wherein a single storage appliance (e.g., a Purpose Built Backup Appliance) is deployed to serve multiple customers, each customer using the same storage appliance for their protection storage requirements. A storage system which supports multi-tenancy must satisfy the security and isolation requirements. Here, the “security and isolation requirements” refer to the requirements that each customer's dataset must be secured and isolated from the other customers on the storage appliance. The security and isolation requirements apply to data access. For example, a customer must not be able to read or write to datasets that belong to another customer. The security and isolation requirements can also refer to control access. For example, an administrator of one customer must not be able to perform system configuration, monitoring, etc., of the datasets that belong to another customer. Thus, although the customers may share the same storage appliance for backup, restore, or replicating their datasets, none of the customers can be aware of the presence of other customers in the storage appliance.

Other than the security and isolation requirements, there were some other obvious problems in deploying multi-tenancy on a single storage appliance. For example, a conventional PBBA does not include a mechanism in its Operating System through which the system administrator could track the system resources allocation and usage for each customer. Deploying multi-tenancy on a PBBA, especially in a service provider (SP) environment also presents a problem of administrative scaling. For example, if tens or hundreds of customers are deployed in the same PBBA, and if none of these customers' own administrators could perform self-administration, then for each and every administrative requirement, the customers would be dependent on the system administrator. Thus, the system administrator would face a problem as the number of customers increase.

A conventional storage appliance does not natively support multi-tenancy in such a manner that satisfies the security and isolation requirements. As illustrated inFIG. 1, Purpose Built Backup Appliance (PBBA)101has been deployed with two customers, i.e., customer A and customer B. PBBA101includes file system management objects (FSMOs)110-113. FSMOs110-111are allocated to customer A, and FSMOs112-113are allocated to customer B. Conventional PBBA101, however, does not natively provide a mechanism in which FSMOs110-111are securely isolated from customer B, and FSMOs112-113securely isolated from customer A. Further, conventional PBBA101does not provide a mechanism for each customer to have its own administrator who can only administer objects belonging only to the customer. Thus, all administration must be performed by a single system administrator. In order for customer A and customer B to manage their respective allocated FSMOs, the credentials of system administrator102must be provided to both customer A and customer B. In such a scenario, each customer would be able to access and manage datasets that belong to the other customer. Alternatively, all system configuration and management can be performed by a third party, without providing the credentials of system administrator102to customer A and customer B. This approach, however, is not feasible in cases where the PBBA is deployed to many customers. Thus, there is a need for a storage system to natively support multi-tenancy by providing mechanisms within its operating system to secure and isolate the datasets of each customer.

DESCRIPTION OF EMBODIMENTS

Techniques for providing SMT with security and isolation to tenants are herein described.FIG. 2is a block diagram illustrating an example of a storage system (e.g., a PBBA) according to embodiment. In the illustrated example, storage system204has associated FSMOs210-211with tenant-unit (Tu) A, and associated FSMOs212-213with Tu B. As used herein, a Tu refers to the highest unit of abstraction for providing security and isolation in the operating system. A Tu also acts as the highest abstraction for allocating and tracking resource utilization by a tenant. Here, a FSMO refers to a unit of storage allocation that presents a unique and self-contained namespace for a tenant. Each tenant can be allocated one or more FSMOs. Tenant-unit A and tenant-unit B have been assigned the Tu names TuA and TuB, respectively. TuA is allocated to tenant A, and TuB is allocated to tenant B. As used herein, a tenant can be a business unit within a large enterprise (e.g., a finance department, marketing department, etc.). A tenant can also refer to an enterprise (e.g., when a storage appliance is deployed by a service provider). TuA and TuB have been assigned the Tu IDs of Tu-IDA and Tu-IDB, respectively. FSMOs210-213have been assigned the FSMO IDs of FSMO-ID10-FSMO-ID12, respectively. Further, FSMOs210-213have been assigned the FSMO paths “/mtree10”-“/mtree13”, respectively. These IDs and paths are shown for illustrative purposes, and not intended to be limitations of the present invention. The configuration shown inFIG. 2shall be referenced throughout the description. Throughout the description, references are made to IDs for users, Tus, and FSMOs. It shall be understood that these IDs are Universally Unique IDs (UUIDs).

Contrary to a conventional PBBA, storage system204of the present invention only allows tenant A to access FSMOs associated with its tenant-unit (e.g., FSMOs210-211), and only allows tenant B to access FSMOs associated with its tenant unit (e.g., FSMOs212-213). FSMOs210-213can be accessed by tenants A and B using various protocols. For example, tenants A and B can access FSMOs210-213using the 1) DDBoost protocol (available from EMC® Corporation of Hopkinton, Mass.), in which case FSMOs210-213are known as “storage units”, 2) Network File System (NFS) or Common Internet File System (CIFS) protocol, in which case FSMOs210-213are known as Mtrees, 3) Virtual Tape Library (VTL) protocol, in which case FSMOs210-213are known as VTL pools, or 4) Protection Point protocol, in which case FSMOs210-213are known as Vdisks. Various other protocols can be used without departing from the broader scope and spirit of the present invention.

Further, by using the mechanisms of the present invention, storage system204enables tenants A and B to have their own respective tenant admins, and thus, do not rely on system admin202. As used herein, a system admin is an administrator authorized to perform all operations at the storage system. A tenant admin, on the other hand, is only authorized to perform a subset of the operations that are available to the system admin. A tenant admin is also distinguished from a system admin in that a tenant admin can only access objects that are associated with the Tu that the tenant admin has been allocated. A tenant user can only perform a subset of the operations that are available to the tenant admin. Various mechanisms of the present invention shall become apparent through the description of other figures below.

FIG. 3is a block diagram illustrating a storage system according to one embodiment of the invention. For example, storage system304may be implemented as part of storage system204. Referring toFIG. 3, system300includes, but is not limited to, one or more client systems301-302communicatively coupled to storage system304over network303. Clients301-302may be any type of clients such as a server, a personal computer (e.g., desktops, laptops, and tablets), a “thin” client, a personal digital assistant (PDA), a Web enabled appliance, a gaming device, a media player, or a mobile phone (e.g., Smartphone), etc. Network303may be any type of networks such as a local area network (LAN), a wide area network (WAN) such as Internet, a corporate intranet, a metropolitan area network (MAN), a storage area network (SAN), a bus, or a combination thereof, wired and/or wireless. For example, client301may represent a first tenant (shown as tenant A), and client302may represent a second tenant (shown as tenant B). InFIG. 3, each tenant is represented by one client for the sake of simplicity. In shall be understood, however, that each tenant may access storage system304through multiple clients.

Storage system304may include any type of server or cluster of servers. For example, storage system304may emulate a storage server used for any of various different purposes, such as to provide multiple users with access to shared data and/or to back up mission critical data. Storage system304may be, for example, a file server (e.g., an appliance used to provide network attached storage (NAS) capability), a block-based storage server (e.g., used to provide SAN capability), a unified storage device (e.g., one which combines NAS and SAN capabilities), a nearline (also known as an archive) storage device, a direct attached storage (DAS) device, a tape backup device, or essentially any other type of data storage device. Storage system304may have a distributed architecture, or all of its components may be integrated into a single unit. Storage system304may be implemented as part of an archive (e.g., Extended Retention Tier) and/or backup system such as a deduplicating storage system available from EMC® Corporation of Hopkinton, Mass.

In one embodiment, storage system304includes, but is not limited to, backup/restore engine306, deduplication storage engine307, and one or more storage devices308-309communicatively coupled to each other. Storage devices308-309may be implemented locally (e.g., single node operating environment) or remotely (e.g., multi-node operating environment) via interconnect320, which may be a bus and/or a network. In one embodiment, one of the storage devices308-309operates as an active storage to receive and store external or fresh user data, while the other storage devices operates as a target storage device to periodically archive data from the active storage device according to an archiving policy or scheme. Storage devices308-309may be, for example, conventional magnetic disks, optical disks such as CD-ROM or DVD based storage, magnetic tape storage, magneto-optical (MO) storage media, solid state disks, flash memory based devices, or any other type of non-volatile storage devices suitable for storing large volumes of data. Storage devices308-309may also be a combination of such devices. In the case of disk storage media, the storage devices308-309may be organized into one or more volumes of Redundant Array of Inexpensive Disks (RAID).

In response to a data file to be stored in storage devices308-309, deduplication storage engine307is configured to segment the data file into multiple chunks according to a variety of segmentation policies or rules. Deduplication storage engine307may choose not to store a chunk in a storage device if the chunk has been previously stored in the storage device. In the event that deduplication storage engine307chooses not to store the chunk in the storage device, it stores metadata enabling the reconstruction of the file using the previously stored chunk. As a result, chunks of data files are stored in a deduplicated manner, either within each of storage devices308-309or across at least some of storage devices308-309. Data stored in the storage devices may be stored in a compressed form (e.g., lossless compression: Huffman coding, Lempel-Ziv Welch coding; delta encoding: a reference to a chunk plus a difference; etc.). In one embodiment, different storage devices may use different compression methods (e.g., main or active storage device from other storage devices, one storage device from another storage device, etc.).

The metadata, such as metadata310-311, may be stored in at least some of storage devices308-309, such that files can be accessed independent of another storage device. Metadata of each storage device includes enough information to provide access to the files it contains. In one embodiment, metadata may include fingerprints contained within data objects312-313, where a data object may represent a data chunk, a compression region (CR) of data chunks, or a container of one or more CRs. Fingerprints are mapped to a particular data object via metadata310-311, enabling the system to identify the location of the data object containing a chunk represented by a particular fingerprint. When an active storage device fails, metadata contained in another storage device may be utilized to recover the active storage device. When one storage device is unavailable (e.g., the storage device has failed, or is being upgraded, etc.), the system remains up to provide access to any file not stored in the failed storage device. When a file is deleted, the metadata associated with the files in the system is updated to reflect that the file has been deleted.

In one embodiment, the metadata information includes a file name, a storage device where the chunks associated with the file name are stored, reconstruction information for the file using the chunks, and any other appropriate metadata information. In one embodiment, a copy of the metadata is stored on a storage device for files stored on a storage device so that files that are stored on the storage device can be accessed using only the information stored on the storage device. In one embodiment, a main set of metadata information can be reconstructed by using information of other storage devices associated with the storage system in the event that the main metadata is lost, corrupted, damaged, etc. Metadata for a storage device can be reconstructed using metadata information stored on a main storage device or other storage device (e.g., replica storage device). Metadata information further includes index information (e.g., location information for chunks in storage devices, identifying specific data objects).

In one embodiment, the storage system as shown inFIG. 3may be used as a tier of storage in a storage hierarchy that comprises other tiers of storage. One or more tiers of storage in this hierarchy may utilize different kinds of storage devices and/or may be optimized for different characteristics such as random update performance. Files are periodically moved among the tiers based on data management policies to achieve a cost-effective match to the current storage requirements of the files. For example, a file may initially be stored in a tier of storage that offers high performance for reads and writes. As the file ages, it may be moved into a tier of storage according to one embodiment of the invention. In various embodiments, tiers include different storage technologies (e.g., tape, hard drives, semiconductor-based memories, optical drives, etc.), different locations (e.g., local computer storage, local network storage, remote network storage, distributed storage, cloud storage, archive storage, vault storage, etc.), or any other appropriate storage for a tiered data storage system.

According to one embodiment, backup/restore engine306is responsible for backing up data from remote clients (e.g., clients301-302) to one or more local storage devices (e.g., storage devices308-309). Backup/restore engine306is also responsible for restoring and/or replicating data from one or more local storage devices to the remote clients.

In one embodiment, storage system includes SMT engine315configured to provide security and isolation to each tenant. For example, SMT engine315is configured to allocate Tus to tenants by managing various config-metadata. Protocol engine317is configured to use these config-metadata to determine whether tenants may perform data access of FSMOs at storage system304. Role based access control (RBAC)316is configured to use the config-metadata to determine whether tenants may perform control access of the FSMOs and various other resources at storage system304.

FIG. 4is a block diagram illustrating a data path of a storage system according to one embodiment. The storage system illustrated inFIG. 4is similar to the storage system illustrated inFIG. 3. Certain details, however, have been omitted inFIG. 4in order to avoid obscuring the invention. Further, certain details have been added inFIG. 4in order to better illustrate the present invention.FIG. 4shall be described with reference to the example illustrated inFIG. 2. That is, tenant-unit A and tenant-unit B are allocated to tenants A and B, respectively. Tenant-unit A and tenant-unit B are associated with the Tu names TuA and TuB, respectively. TuA represents FSMOs210-211, and TuB represents FSMO212-213. TuA and TuB are associated with Tu IDs Tu-IDA and Tu-IDB, respectively, and FSMOS210-213are associated with FSMO IDs FSMO-ID10-FSMO-ID14, respectively. Further, FSMOs210-213are associated with FSMO paths “mtree10”-“mtree13”, respectively.

Referring now toFIG. 4. In one embodiment, DM405is configured to manage DM config-metadata store425for associating/mapping FSMO IDs to FSMO paths. In one embodiment, DM config-metadata store425includes, but not limited to, one or more sets of elements. Each set includes, but not limited to, the elements of {FSMO ID, path}. InFIG. 4, one set of element is shown: {FSMO ID471, path472}. FSMO ID471contains the ID of a FSMO. Path472contains the path of a FSMO. In some embodiments, the FSMO name specified by the user (e.g., as part of the request to access a FSMO) is in the same format as the FSMO path required by DM405. In some alternative embodiments, the specified FSMO name may need to be converted to a FSMO path. As used herein, a “specified FSMO name” refers to the FSMO name specified by the user as part of a user request to access the FSMO. For example, in some of the protocols supported by protocol engine317(described further below), the specified FSMO name is the same as the FSMO path. In other protocols, the specified FSMO name must be converted to a FSMO path in order for DM405to understand it as a path. In one such example, the specified FSMO name must be prepended with a predetermined path (e.g., “/data/col1”) in order to be consistent with the path format understood by DM405. Each set of elements associates a FSMO ID with a FSMO path. Thus, in this example, DM405may configure FSMO ID471to include FSMO-ID10and path472to include the path “/mtree10” (or “/data/col1/mtree10”). It shall be understood that DM config-metadata store425includes at least one set of elements {FSMO ID, path} for each FSMO in the system. DM config-metadata store425may also be managed by a system admin via a system configuration interface (not shown).

According to one embodiment, a system admin associates the Tus to tenant users/admins by configuring SMT config-metadata store410via a system configuration interface. In one embodiment, SMT config-metadata store410includes, but not limited to, Tu config-metadata store422, security config-metadata store423, and name-service config-metadata store424.

In one embodiment, Tu config-metadata store422includes information for associating/mapping Tu names to Tu IDs. Tu config-metadata store422includes, but not limited to, one or more sets of elements. Each set includes, but not limited to, the elements of {Tu name, Tu ID}. InFIG. 4, one set of element is shown: {Tu name430, Tu ID431}. Tu name430contains the name of a Tu. Tu ID431contains the ID of a Tu. Each set of elements associates the named Tu with the identified Tu. Thus, in this example, a system admin may configure Tu name430to include the name “TuA” and Tu ID431to include the ID “Tu-IDA”. It shall be understood that Tu config-metadata store422includes at least one set of elements {Tu name, Tu ID} for each Tu in the system.

Although Tu config-metadata store422has been described as being configured by a system admin, it shall be understood that Tu config-metadata store422can be configured using other mechanisms. For example, Tu config-metadata store422may be configured by SMT engine315automatically when a new Tu is created (described in further details below).

In one embodiment, security config-metadata store423includes, but not limited to, one or more sets of elements. Each set includes, but not limited to, the elements of {user name, user ID, Tu ID, operation ID, user role}. InFIG. 4, one set of element is shown: {user name436, user ID437, Tu ID438, operation ID439, user role440}. User name436contains the name of a user. User ID437contains the ID of a user. Tu ID438contains the ID of a Tu. Operation ID439contains one or more IDs identifying one or more operations. User role440contains the role of a user (e.g., system admin, tenant admin, tenant user, etc.) Each set of elements associates the named/identified user with the identified Tu, user role, and identified set of operations. The operation ID element includes one or more IDs identifying one or more operations (e.g., a self-service operation) that the named/identified user can perform. The user role element allows storage system304to bypass certain checks during a control access request when the requesting user is a system admin (described in further details below). In this example, a system admin may configure user name436to include the name of TuA admin, user ID437to include the ID of TuA admin, Tu ID438to include “Tu-IDA”, and operation ID439to include the ID(s) of operation(s) that TuA admin may perform. It shall be understood that security config-metadata store423includes at least one set of elements {user name, user ID, Tu ID, operation ID} for each user in the system.

Although security config-metadata store423has been described as being configured by a system admin, it shall be understood that security config-metadata store423can be configured using other mechanisms. For example, config-metadata store423may be configured by SMT engine315automatically when a new user is created and associated with a Tu.

In one embodiment, SMT engine315associates FSMOs to Tus by configuring DM attribute store411. In one embodiment, DM attribute store411includes, but not limited to, one or more sets of elements. Each set includes, but not limited to, the elements of {FSMO ID, Tu ID}. InFIG. 4, one set of element is shown: {FSMO ID455, Tu ID456}. FSMO ID455contains one or more IDs of one or more FSMOs. Tu ID456contains the ID of a Tu. Each set of elements associates the identified FSMO(s) with the identified Tu. In one embodiment, in response to a request to associate a FSMO with a Tu, SMT engine315requests DM405to provide the FSMO ID of the specified FSMO name (which may need to be converted to a path as described above). As used herein, a “specified FSMO name” refers to the name provided by the user as part of the request to associate the FSMO with the Tu. In response to the request, DM405uses the specified FSMO name/path to lookup the associated FSMO ID in DM config-metadata store425. For example, DM405may determine that path472contains the specified FSMO name/path, and provides the ID contained in the associated FSMO ID element471to SMT engine315. In this example, path472may contain the path “/mtree10”, and FSMO ID471may contain “FSMO-ID10”.

Further, in response to a request to associate a FSMO to a Tu, SMT engine315uses the specified Tu name to lookup the Tu ID in Tu config-metadata store422. As used herein, the “specified Tu name” refers to the name provided by the user as part of the request to associate the FSMO to the Tu. For example, in response to determining Tu name430contains the specified Tu name, SMT engine315obtains the Tu ID contained in the associated Tu ID431. In this example, Tu name430may contain “TuA” and Tu ID431may contain “Tu-IDA”. In one embodiment, SMT engine315associates the specified FSMO to the specified Tu by atomically storing the obtained FSMO ID and the obtained Tu ID in DM attribute store411via a DM attribute interface (not shown). For example, SMT engine315atomically stores the ID obtained from FSMO ID471(e.g., FSMO-ID10) in FSMO ID455and the ID obtained from Tu ID431(e.g., Tu-IDA) in Tu ID456. In this example, the result is that FSMO210is associated with TuA. It shall be understood that DM attribute store411includes at least one set of elements {FSMO ID, Tu ID} for each FSMO in the system. Element Tu ID, however, does not contain a valid ID unless the FSMO has been allocated to (i.e., associated with) a Tu.

Although DM attribute store411has been described as being configured by SMT engine315, it shall be understood that DM attribute store411can be configured using various other mechanisms. For example, DM attribute store411can also be configured by a system admin via a system configuration interface (not shown).

According to one embodiment, SMT engine315updates protocol config-metadata store412based on metadata contained in security config-metadata store423and DM attribute store411. Alternatively, SMT engine315may update protocol config-metadata store412independently using the same mechanism for updating DM attribute store411and security config-metadata store423, without having to rely on DM attribute store411and security config-metadata store423. Further, protocol config-metadata store412can be configured by a system admin.

According to one embodiment, protocol config-metadata store412includes, but not limited to, one or more sets of elements. Each set includes, but not limited to, the elements of {user name, user ID, Tu ID, FSMO ID}. InFIG. 4, one set of element is shown: {user name466, user ID467, Tu ID468, FSMO ID469}. User name466contains the name of a user. User ID467contains the ID of a user. Tu ID contains the ID of a Tu. FSMO ID469contains one or more IDs of one or more FSMO. Each set of elements associates the named/identified user with the identified Tu, and associates the identified Tu with the identified FSMO(s).

According to one embodiment, SMT engine315updates protocol config-metadata store412by replicating information from DM attribute store411and security config-metadata store423. For example, elements436-438of security config-metadata store423may be replicated to elements466-468of protocol config-metadata store412. Further, SMT engine315may use either Tu ID438or replicated Tu ID468to lookup the associated FSMO ID(s) in DM attribute store411. In this example, Tu ID438or replicated Tu ID468matches Tu ID456of DM attribute store411, and thus, SMT engine315determines that FSMO ID455is associated with Tu ID438or replicated Tu ID468. In response to this determination, SMT engine315replicates FSMO ID455to FSMO ID469. Thus, continuing on with the above example, user name466now contains the name of TuA admin, user ID467contains the user ID of TuA admin, Tu ID468contains TuA, and FSMO ID469contains FSMO-ID10. The result is that TuA admin is associated with TuA, and can access FSMO210. It shall be understood that protocol config-metadata store412includes at least one set of elements {user name, user ID, Tu ID, FSMO ID} for each user in the system.

In one embodiment, storage system304includes protocol interface401configured to receive one or more data access requests from one or more tenants using the Remote Procedure Call (RPC) protocol. Here, a data access request can be a read, write, or replicate request. Protocol interface401processes the protocol-specific header of the request and forwards the request to protocol engine317after removing at least some of the networking stack related information from the request. Protocol engine317processes the request and forwards it to one of the protocol servers (not shown) implemented as part of protocol engine317. The protocol server can be, for example, a Network File System (NFS) server, Server Message Block (SMB) server, Likewise Common Internet File System (CIFS) server, virtual tape library interface (VTL) server, and Protection Point server, DDBoost, or any combination thereof. The protocol server of protocol engine317authenticates the data access request by validating the credentials of the user that initiated the request, for example, by looking up protocol config-metadata store412.

The protocol server of protocol engine317determines whether the user is authorized to access the data by looking up protocol config-metadata store412to determine which FSMO(s) the user is authorized to access. For example, the protocol server uses the specified user name to lookup the associated user ID in protocol config-metadata store412. As used herein, a “specified user name” refers to the name which is provided by the user (e.g., as part of a login process or as part of the request itself). The protocol server then uses the determined user ID to obtain an associated Tu ID from protocol config-metadata store412. The protocol server then uses the obtained Tu ID to determine one or more of the associated FSMO IDs. These associated IDs identify the FSMOs that the user is authorized to access.

By way of example, the protocol server may determine that the specified user name (e.g., TuA Data-Access user's user name) matches the user name contained in user name466, which is associated with the ID contained in user ID467. The protocol server uses the user ID contained in user ID467to obtain the Tu ID contained in the associated Tu ID468. The protocol server uses the Tu ID to determine that the user is authorized to access the FSMO(s) identified by the ID(s) contained in the associated FSMO ID469. In this example, FSMO ID469contains the FSMO-ID10. Thus, TuA Data-Access user is authorized to access FSMO210.

According to one embodiment, the protocol server then determines whether the FSMO for which the access is being requested is one of the authorized FSMOs. For example, the protocol server requests DM405to provide the FSMO ID associated with the specified FSMO name. For example, DM405may determine that path472contains the specified path, and provides the FSMO ID contained in FSMO ID471to the protocol server. This FSMO ID identifies the FSMO for which the request is being made.

In one embodiment, the protocol server determines that the user is authorized to access the requested object if the FSMO ID of the requested FSMO matches one of the FSMO IDs the user is authorized to access (e.g., the FSMO IDs contained in FSMO ID element469). In response to determining FSMO ID469contains the FSMO ID of the requested FSMO, the protocol server grants the access request. Otherwise, the protocol server denies the request. Note that in some embodiments, the protocol server may have to convert the specified FSMO name to a FSMO path, for example, by prepending the specified FSMO name with a predetermined path (e.g., “/data/col1”). In alternative embodiments, the specified FSMO name is the same as the FSMO path supported by DM405. As described above, FSMO ID elements (e.g., FSMO ID element469) contains one or more IDs identifying one or more FSMOs that the user is authorized to access. In cases where the user is associated with multiple FSMOs, the requested FSMO is compared against all the FSMOs associated with the requesting user, and if there is any match, the data access request is authorized.

In response to determining the user is authenticated and authorized to access the data, the protocol server forwards the request to file service interface403. File service interface403requests DM405to update (or fetch, depending on whether the access is a write or read) metadata concerning the file being accessed. DM405maintains file abstraction for the underlying deduplicated segments of the files stored at storage system304. DM405maintains all the metadata for the files including file names, file IDs, and various other file attributes.

File service interface403then requests content store404to perform the authorized request. Content store404provides a stream abstraction for the underlying deduplicated data segments. The stream abstraction provided by content store404ensures segment locality in order to provide better throughput for data access. In one embodiment, content store404is configured to segment the files (in the case of a write access) into variable-length segments based on a variety of rules or considerations. For example, the files may be broken into segments by identifying segment boundaries using a content-based technique (e.g., a function is calculated at various locations of a file, when the function is equal to a value or when the value is a minimum, a maximum, or other value relative to other function values calculated for the file), a non-content-based technique (e.g., based on size of the segment), or any other appropriate technique. A segment is restricted to a minimum and/or maximum length, to a minimum or maximum number of segments per file, or any other appropriate limitation.

Content store404requests deduplication storage engine307to perform the data access, for example, writing the deduplicated segments of the file to disk in the case of a write, or reading deduplicated segments from disk in the case of a read request. Note that by natively supporting multi-tenancy, the present invention enables data from multiple FSMOs belonging to the same or different tenants to be deduplicated, resulting in a much more efficient use of the physical storage device. For example, data from FSMO210(belonging to tenant A) may be deduplicated with data from FSMO212(belonging to tenant B). Thus, only one copy of a data segment that is common among FSMOs210and212are actually stored in the physical storage device. It shall be noted that this implies security and isolation are provided logically at the FSMO level, but not physically at the storage device level.

Note that some or all of the components shown as part of storage system304inFIG. 4may be implemented in software, hardware, or a combination thereof. For example, some or all of the shown components may be implemented in a form of executable instructions that can be stored in a machine-readable storage medium, which when executed, loads the components into an operating system of storage system304. Some or all of the components shown inFIG. 4may also be stored as part of a persistent storage device (e.g., storage devices308-309). For example, protocol config-metadata store412, DM attribute store411, and/or SMT config-metadata store410may be stored as part of a persistent storage device, and loaded into memory during operation.

FIG. 5is a block diagram illustrating a control path of a storage system according to one embodiment. The storage system illustrated inFIG. 5is similar to the storage system illustrated inFIG. 3. Certain details, however, have been omitted inFIG. 5in order to avoid obscuring the invention. Further, certain details have been added inFIG. 5in order to better illustrate the present invention.FIG. 5shall be described with reference to the example illustrated inFIG. 2. That is, tenant-unit A and tenant-unit B are allocated to tenants A and B, respectively. Tenant-unit A and tenant-unit B are associated with the Tu names TuA and TuB, respectively. TuA represents FSMOs210-211, and TuB represents FSMO212-213. TuA and TuB are associated with Tu IDs Tu-IDA and Tu-IDB, respectively, and FSMOS210-213are associated with FSMO IDs FSMO-ID10-FSMO-ID14, respectively. Further, FSMOs210-213are associated with FSMO paths “mtree10”-“mtree13”, respectively.

Referring now toFIG. 5. System control interface501receives one or more control access requests from one or more users using the Remote Procedure Call (RPC), Hypertext Transfer Protocol Secure (HTTPS), Representational State Transfer (REST) protocol, or any combination thereof. Here, a control access request refers to a request to perform an operation on an object. An operation includes, but not limited to: 1) listing the FSMOs associated with a tenant-unit, 2) listing deduplication statistics for the FSMOs associated with a tenant-unit, 3) listing the files/directories that are associated with the FSMOs that are associated with a tenant-unit, 4) associating/disassociating FSMOs with/from a tenant-unit, 5) listing the users/groups associated with a tenant-unit, 6) associating/disassociating users/groups associated with/from a tenant-unit, 7) listing the notification-groups associated with a tenant-unit, and 8) associating/disassociating notification groups with/from a tenant-unit.

The definition of an object depends on the operation that is being requested. For example, an object can be a: 1) FSMO, 2) user/group (where a user can be a local user (e.g., user definitions stored in the storage system operating system), or name-service user (e.g., Active Directory (AD), Network Information Service (NIS), etc.); users can be classified as either management-users (i.e., admins who perform control/management operations), or as data-access users (i.e., users who only access data); note that groups may be defined in some name service such as AD, NIS, wherein the same groups can be associated with a tenant-unit with the roles of tenant-admin/tenant-User; if any user logs in to the system which is part of such a group, that user will have the assigned tenant-admin/tenant-user role; 3) notification-group which includes, but not limited to, a list of alert classes and severities, and email-addresses; notification group information is looked up in order to determine where to send an alert notification when an alert is generated in the system.

In one embodiment, in order to provide security and isolation, the control operations which may be performed by the requesting user depends on his/her role. For example, while a system admin may perform all operations, a tenant admin may only be authorized to perform a subset of the operations on a subset of the objects. A tenant user may be allowed to perform only a subset of the operations and/or subset of the objects that are available to the tenant admin. The operations which are available to the roles are defined through the various config-metadata, described in further details below.

In response to a control access request, system control interface501requests pluggable authentication module (PAM)502to authenticate the control access request. PAM502processes the authentication request, and if successful, forwards the request to Role Based Access Control (RBAC)316. RBAC316determines whether the requesting user is authorized to perform the requested operation on the object based on the config-metadata stored at storage system304.

According to one embodiment, RBAC316determines the role of the requesting user by using the specified user name to lookup security config-metadata store423. For example, if user name element436contains the specified user name, RBAC316obtains the ID contained in the associated user ID element437. Using the obtained user ID, RBAC316determines the associated user role, which in this example, is contained in user role element440. If RBAC316determines that the requesting user is a system admin, RBAC316grants the request without further processing. Otherwise, RBAC316determines whether the requesting tenant admin/user is authorized to perform the self-service control operation. Here, a “self-service” control operation refers to an operation which is being requested by a tenant admin/user, as opposed to an operation being requested by a system admin.

In order to determine whether a self-service operation is authorized, RBAC316uses the user ID (associated with the specified user name) to lookup security config-metadata store423to obtain the operations that are associated with the user. Continuing on with the above example, RBAC316uses the obtained user ID to obtain the ID(s) contained the associated operation ID439. The operation ID(s) contained in operation ID439identify the operation(s) that the user is authorized to perform.

In order to determine whether a self-service operation is authorized, RBAC316compares the ID of the requested operation against all the operation ID(s) that the user is authorized to perform. The ID of the requested operation may be included as part of the control access request. If the ID of the requested operation matches at least one of the authorized operation ID(s), RBAC316determines that the user is authorized to perform the requested operation. After determining that the user is authorized to perform the requested operation, RBAC316determines whether the user is authorized to access the object on which the requested operation is to be performed.

In one embodiment, in order to determine whether the user is authorized to access the requested object, RBAC316uses the user ID (associated with the specified user name) to lookup security config-metadata store423to obtain the Tu ID that is associated with the user. The Tu ID obtained from security config-metadata store423identifies the Tu that can be accessed by the associated user. RBAC316uses this obtained Tu ID to access an object-to-Tu config-metadata store corresponding to the same object type as the object on which the operation is to be performed. Each object-to-Tu config-metadata store includes object IDs that identify the objects which can be accessed by a user who is authorized to access the associated Tu.

Storage system304stores the object-to-Tu association in a distributed manner. By way of example, if the object type is a FSMO, then the object-to-Tu association is contained in DM attribute store411. For other object types, such as notification groups, the object-to-Tu association is contained in their respective config-metadata (not shown inFIG. 5).

By way of example, assume that the object is a FSMO. In this case, RBAC316may determine that user ID437contains the ID of the requesting user, and obtains the Tu ID contained the associated Tu ID element438from security config-metadata store423. RBAC316then uses the obtained Tu ID to lookup the object-to-Tu association in DM attribute store411. RBAC316may determine that Tu ID element456contains the same Tu ID as the Tu ID obtained from security config-metadata store423. In that case, RBAC316obtains the FSMO IDs contained in the associated FSMO ID element455. In this example, FSMO ID element455contains the IDs that identify all the FSMOs (i.e., objects) that the user may access. RBAC316then compares the FSMO IDs obtained from DM attribute store411against the ID of the requested FSMO object. The ID of the requested FSMO may be provided by DM405as described above. Alternatively, the FSMO ID of the requested object may be included as part of the user request. If the FSMO ID of the requested object matches at least one of the FSMO IDs obtained from DM attribute store411, then the user is authorized to access the requested object. In response to determining the user is authorized to perform the requested operation, and authorized to access the object on which the requested operation is to be performed, RBAC316grants the control access request. Otherwise, the request is denied.

FIG. 5has been described with respect to a local user. In shall be appreciated that the same mechanisms apply equally to a name service group. For users belonging to Name Service Groups such as Active Directory (AD) groups or Name Information Service (NIS) groups, Authentication is handled by PAM502as is. PAM consults nsswitch.conf and redirects the authentication request to the appropriate Name-Server. Upon authentication, name-service config metadata store424is consulted to determine if the NameService ID associated with the User ID is associated with the tenant-unit. If so, PAM '502grants the request.

Note that some or all of the components shown as part of storage system304inFIG. 5may be implemented in software, hardware, or a combination thereof. For example, some or all of the shown components may be implemented in a form of executable instructions that can be stored in a machine-readable storage medium, which when executed, loads the components into an operating system of storage system304. Some or all of the components shown inFIG. 5may also be stored as part of a persistent storage device (e.g., storage devices308-309). For example, protocol config-metadata store512, DM attribute store511, and/or SMT config-metadata store510may be stored as part of a persistent storage device, and loaded into memory during operation.

FIG. 6is a flow diagram illustrating method600for creating a Tu according to one embodiment. For example, method600can be performed by storage system304. Method600can be implemented in software, firmware, hardware, or any combination thereof.

Referring now toFIG. 6. At block605, a storage system receives a request to create a tenant-unit. For example, storage system304receives a request from a system admin to create TuA for tenant A. At block607, the storage system determines the requesting user is a system admin and grants the request by proceeding to block610. For example, storage system304determines that the user role element (e.g., user role440) associated with the requesting user indicates the user is a system admin. In one embodiment, only the system admin is authorized to create Tus. Thus, if at block607the storage system determines that the user is not a system admin, the request is denied, and method600is completed.

At block610, the storage system determines that the specified Tu name complies with a predetermined Tu naming convention. For example, storage system304determines that the specified Tu name “TuA” complies with a Tu naming convention that had previously been configured as part of a naming policy stored at storage system304.

At block615, the storage system determines that a Tu with the same name does not already exist in the system. For example, storage system304iterates through Tu config-metadata store422to determine that none of the Tu name elements contain the name “TuA”. At block620, the storage system generates a Tu ID for the new Tu. For example, storage system304generates a UUID for the new Tu. At block625, the storage system atomically stores the generated Tu ID and the specified Tu name in the Tu config-metadata store. For example, storage system304atomically stores the name “TuA” in Tu name430and the generated UUID in Tu ID431of Tu config-metadata store422.

FIG. 7is a flow diagram illustrating method700for removing a Tu from a storage system according to one embodiment. For example, method700can be performed by storage system304. Method700can be implemented in software, firmware, hardware, or any combination thereof.

Referring now toFIG. 7. At block705, a storage system receives a request to remove a Tu from the storage system. For example, storage system304receives a request from a system admin to remove TuA from the system. At block707, the storage system determines the requesting user is a system admin and grants the request by proceeding to block710. For example, storage system304determines that the user role element (e.g., user role440) associated with the requesting user indicates the user is a system admin. In one embodiment, only the system admin is authorized to remove Tus. Thus, if at block707the storage system determines that the user is not a system admin, the request is denied, and method700is completed.

At block710, the storage system determines that the specified Tu name complies with a predetermined Tu naming convention. For example, storage system304determines that specified name “TuA” complies with a Tu naming convention that had previously been configured as part of a naming policy stored at storage system304.

At block715, the storage system determines that a Tu with the same name exists in the system. For example, storage system304iterates through Tu config-metadata store422to determine that at least one Tu name element contains the specified name “TuA”. As part of block715, the storage system obtains the Tu ID from the Tu ID element which is associated with the Tu name element that contains the specified Tu name. For example, in response to determining Tu name430contains the specified name “TuA”, storage system304obtains the ID from the associated Tu ID431.

At block720, the storage system determines whether the specified Tu is associated with any protection storage resource or attributes. For example, storage system304iterates through name-service config-metadata store424, security config-metadata store423, and DM attribute store411to determine whether the Tu ID obtained at block715exists in Tu ID elements447,438, and/or456. At block725, in response to determining the Tu ID obtained at block715is associated with a protection storage resource or attribute, the storage system denies the request to remove the Tu. For example, in response to determining the obtained Tu ID exists in Tu ID447,438, and/or456, storage system304denies the request to remove the Tu.

At block730, in response to determining the Tu ID obtained at block715is not associated with any protection storage resource or attribute, the storage system atomically removes the specified Tu name and associated Tu ID from the Tu config-metadata store. For example, in response to determining the obtained Tu ID does not exist in Tu ID447,438, or456, storage system304atomically removes “TuA” from Tu name430and the ID from Tu ID431.

FIG. 8is a flow diagram illustrating method800for renaming a Tu at a storage system according to one embodiment. For example, method800can be performed by storage system304. Method800can be implemented in software, firmware, hardware, or any combination thereof.

Referring now toFIG. 8. At block805, a storage system receives a request to rename a Tu at the storage system. For example, storage system304receives a request from a system admin to rename TuA to TuC. At block807, the storage system determines the requesting user is a system admin and grants the request by proceeding to block810. For example, storage system304determines that the user role element (e.g., user role440) associated with the requesting user indicates the user is a system admin. In one embodiment, only the system admin is authorized to rename Tus. Thus, if at block807the storage system determines that the user is not a system admin, the request is denied, and method800is completed.

At block810, the storage system determines that the specified new Tu name complies with a predetermined Tu naming convention. For example, storage system304determines that the new name “TuC” complies with a Tu naming convention that had previously been configured as part of a naming policy stored at storage system304.

At block815, the storage system determines that the specified current Tu name exists in the system. For example, storage system304iterates through Tu config-metadata store422to determine that at least one Tu name element contains the specified current name “TuA”. As part of block815, the storage system obtains the Tu ID from the Tu ID element which is associated with the Tu name element that contains the specified current Tu name. For example, in response to determining Tu name element430contains “TuA”, storage system304obtains the Tu ID contained in Tu ID element431.

At block820, the storage system determines that a Tu with the same new Tu name does not already exist in the system. For example, storage system304iterates through Tu config-metadata store422to determine that none of the Tu name elements contain the new name “TuC”. At block825, the storage system atomically updates the Tu config-metadata store with the new Tu name for the obtained Tu ID. For example, storage system304atomically updates Tu name430with the new name “TuC” and Tu ID431with its current ID value.

FIG. 9is a flow diagram illustrating method900for associating/disassociating a FSMO with/from a Tu at a storage system according to one embodiment. For example, method900can be performed by storage system304. Method900can be implemented in software, firmware, hardware, or any combination thereof.

Referring now toFIG. 9. At block905, a storage system receives a request to associate/disassociate a FSMO with/from a Tu. For example, storage system304receives a request from a system admin to associate/disassociate FSMO210from TuA. At block907, the storage system determines the requesting user is a system admin and grants the request by proceeding to block910. For example, storage system304determines that the user role element (e.g., user role440) associated with the requesting user indicates the user is a system admin. In one embodiment, only the system admin is authorized to associate/disassociate a FSMO with/from a Tu. Thus, if at block907the storage system determines that the user is not a system admin, the request is denied, and method900is completed.

At block910, the storage system determines that the specified FSMO name and the specified Tu name comply with a predetermined FSMO and Tu naming convention, respectively. For example, storage system304determines that the specified FSMO name “/mtree10” complies with a FSMO naming convention, and the specified Tu name “TuA” complies with a Tu naming convention that had previously been configured as part of a naming policy stored at storage system304.

In some embodiments, the FSMO name specified by the system admin as part of the request to associate/disassociate a FSMO is in the same format as the FSMO path required by the storage system. In other embodiments, the specified FSMO name may need to be converted to an FSMO path. For example, in some of the protocols supported by protocol engine317, the specified FSMO name is the same as the FSMO path. In other protocols, the specified FSMO name must be converted to a FSMO path in order for DM405to understand it as a path. In one such example, the specified FSMO name must be prepended with a predetermined path (e.g., “/data/col1”) in order to be consistent with the path format understood by DM405. Accordingly, at optional block915, the storage system converts the specified FSMO name to a FSMO path (e.g., by prepending “/data/col1”) to the specified FSMO name.

At block920, the storage system determines that the specified FSMO and Tu exist in the system. For example, DM405may use the specified FSMO path to lookup DM config-metadata store425to determine whether the specified FSMO exists in the system. By way of further example, SMT engine315may use the specified Tu name to lookup Tu config-metadata store422to determine whether the specified Tu exists in the system.

At block925, the storage system obtains the Tu ID for the specified Tu name from the Tu config-metadata store. For example, SMT engine315may determine that Tu name element430contains the specified Tu name, and obtains the Tu ID contained in the associated Tu ID element431.

At block930, the storage system obtains the FSMO ID from the DM using the specified FSMO path. For example, DM405may determine that path element472contains the specified path (i.e., the path specified as part of the request) and obtain the ID contained in the associated FSMO ID element471.

Note that block920is optional because the existence of the specified FSMO and Tu in the system is also verified by blocks925and930. In other words, the fact that the FSMO ID and Tu ID can be obtained confirms the existence of the FSMO and Tu in the system. The advantage of determining the existence at block920, however, is that it requires fewer resources. For example, to determine whether the FSMO exists, DM405can just lookup a hash table and determine if the FSMO exists. However, in order to retrieve the ID, DM405has to reach the leaf page of a B+ Tree and fetch the ID. Thus, in the case where the FSMO or Tu does not exist, resources can be saved by not attempting to obtain the respective IDs.

At block935, the storage system determines whether the request is to associate or disassociate the FSMO. At block940, in response to determining the request is to associate the FSMO with the Tu, the storage system atomically stores the obtained Tu ID as a DM attribute for the obtained FSMO ID through the DM attribute interface. For example, DM405stores the FSMO ID (obtained at block930) in FSMO ID455and the Tu ID (obtained at block925) in Tu ID456. At block945, the storage system atomically updates the protocol config-metadata store to include the FSMO ID for the TU ID. For example, DM405stores the FSMO ID (obtained at block930) in FSMO ID469and the Tu ID (obtained at block925) in Tu ID468. The result is that the specified FSMO is associated with the specified Tu.

At block950, in response to determining the request is to disassociate the FSMO with the Tu, the storage system atomically removes the obtained Tu ID as a DM attribute for the obtained FSMO ID through the DM attribute interface. For example, DM405removes the FSMO ID (obtained at block930) from FSMO ID455and the Tu ID (obtained at block925) from Tu ID456. At block955, the storage system atomically updates the protocol config-metadata store to remove the FSMO ID for the TU ID. For example, DM405removes the FSMO ID from FSMO ID469. The result is that the specified FSMO is no longer associated with the specified Tu.

FIG. 10is a flow diagram illustrating method1000for associating/disassociating a user with/from a Tu at a storage system according to one embodiment. For example, method1000can be performed by storage system304. Method1000can be implemented in software, firmware, hardware, or any combination thereof.

Referring now toFIG. 10. At block1005, a storage system receives a request to associate/disassociate a user with/from a Tu. For example, storage system304receives a request from a system admin to associate/disassociate a user from TuA. At block1007, the storage system determines the requesting user is a system admin and grants the request by proceeding to block1010. For example, storage system304determines that the user role element (e.g., user role440) associated with the requesting user indicates the user is a system admin. In one embodiment, only the system admin is authorized to associate/disassociate a user with/from a Tu. Thus, if at block1007the storage system determines that the user is not a system admin, the request is denied, and method1000is completed.

At block1010, the storage system determines that the specified user name and the specified Tu name comply with a predetermined user and Tu naming convention, respectively. For example, storage system304determines that the specified user name complies with a user naming convention, and the specified Tu name “TuA” complies with a Tu naming convention that had previously been configured as part of a naming policy stored at storage system304.

At block1020, the storage system determines that the specified user and Tu exist in the system. For example, storage system304may use the specified user name to lookup security config-metadata store423to determine whether the specified user exists in the system. By way of further example, storage system304may use the specified Tu name to lookup Tu config-metadata store422to determine whether the specified Tu exists in the system.

At block1025, the storage system obtains the Tu ID for the specified Tu name from the config-metadata store. For example, storage system304may determine that Tu name element430contains the Tu name specified as part of the request, and obtains the Tu ID contained in the associated Tu ID element431.

At block1030, the storage system obtains a user ID for the specified user name from the security config-metadata store. For example, storage system304may determine that user name436contains the user name specified as part of the request, and obtains the user ID contained in the associated user ID437.

Note that block1020is optional because the existence of the specified user and Tu in the system is also verified by blocks1025and1030. In other words, the fact that the user ID and Tu ID can be obtained confirms the existence of the user and Tu in the system. The advantage of determining the existence at block1020, however, is that it requires fewer resources. For example, to determine whether the user exists, storage system304can simply lookup a hash table and determine if the user exists. However, in order to retrieve the ID, storage system304has to reach the leaf page of a B+ Tree and fetch the ID. Thus, in the case where the user or Tu does not exist, resources can be saved by not attempting to obtain the respective IDs.

At block1035, the storage system determines whether the request is to associate or disassociate the user. At block1040, in response to determining the request is to associate the user with the Tu, the storage system atomically updates the security config-metadata store to include the Tu ID with the user ID. For example, storage system304updates security config-metadata store423to include the specified user name in user name436, the obtained user ID in user ID437, and the obtained Tu ID in Tu ID438.

At optional block1045, the storage system atomically updates the protocol config-metadata store to include the Tu ID with the user ID. For example, storage system304updates protocol config-metadata store412to include the specified user name in user name466, the obtained user ID in user ID467, and the obtained Tu ID in Tu ID468. Note here that the operations of block1045are performed if the user to be associated/disassociated is a data-access user.

At block1050, in response to determining the request is to disassociate the user from the Tu, the storage system atomically updates the security config-metadata store to remove the Tu ID from the user ID. For example, assuming user name436contains the specified user name, storage system304updates security config-metadata store423to remove the Tu ID from Tu ID438. Storage system304may also optionally remove the user name from user name436and user ID from user ID437.

At optional block1055, the storage system atomically updates the protocol config-metadata store to remove the Tu ID from the user ID. For example, assuming the user name466contains the specified user name, storage system304updates protocol config-metadata store412to remove the Tu ID from Tu ID468. Storage system304may also optionally remove the user name from user name466and the user ID from user ID467. Note here that the operations of block1045are performed if the user to be associated/disassociated is a data-access user.

FIG. 11is a flow diagram illustrating method1100for determining whether a tenant admin/user (herein referred to as user) is authorized to perform a self-service operation at a storage system according to one embodiment. For example, method1100can be performed by storage system304. Method1100can be implemented in software, firmware, hardware, or any combination thereof. A “self-service” operation refers to an operation that is being requested by a tenant admin/user, as opposed to an operation being requested by a system admin. Thus, in one embodiment, method1100assumes that the requesting user has already been determined to be a tenant admin/user.

Referring now toFIG. 11. At block1105, a storage system receives a request from a user to perform a self-service operation on a Tu. At block1110, the storage system obtains a user ID for the specified user name from the security config-metadata store. For example, storage system304may determine that user name436contains the specified user name, and obtains the user ID contained in the associated user ID437.

At block1115, the storage system obtains the Tu ID(s) associated with the obtained user ID from the security config-metadata store. For example, storage system304may determine that user ID437contains the obtained user ID, and obtains the Tu ID contained in the associated Tu ID438.

At block1120, the storage system obtains the operation ID(s) from the security config-metadata store using the obtained user ID, wherein the operation ID(s) obtained from the security config-metadata store identifies the operation(s) that the specified user is authorized to perform. For example, storage system304may determine that user ID437contains the obtained user ID, and obtains the operation ID(s) contained in the associated operation ID439. At block1123, the storage system obtains the object ID(s) from the object-to-Tu config-metadata store corresponding to the requested object type using the obtained Tu ID, wherein the object ID(s) obtained from the corresponding object-to-Tu config-metadata store identify the objects(s) that the specified user is authorized to access. For example, assuming the object type is FSMO, storage system304may determine that Tu ID456contains the Tu ID obtained at block1115, and obtains the FSMO ID(s) contained in the associated FSMO ID455. These FSMO ID(s) identify all the FSMOs (i.e., objects) that the user is authorized to access.

At block1125, the storage system determines whether the operation ID of the requested operation matches any of the obtained authorized operation ID(s). As part of block1125, the storage system also determines whether the object ID of the requested object matches any of the obtained authorized object ID(s).

For example, storage system304compares the operation ID of the requested operation against the operation ID(s) obtained at block1120. If there is at least one match, storage system304determines that the user is authorized to execute the requested operation. Otherwise, storage system304determines that the user is not authorized to execute the requested operation. By way of further example, storage system304also compares the ID of the requested object against the object ID(s) obtained at block1123. If there is at least one match, storage system304determines that the user is authorized to access the requested object. Otherwise, storage system304determines that the user is not authorized to access the requested object. In one embodiment, the ID of the requested operation is provided as part of the request. The ID of the requested operation, however, can be obtained using any mechanism. In one embodiment, the ID of the requested object is provided as part of the request. The ID of the requested object, however, can be obtained using any mechanism.

In response to determining the user is authorized to perform the requested operation, and also authorized to access the object on which the operation is to be performed, the storage system transitions to block1130and grants the request. Otherwise, the storage system transitions to block1135and denies the request.

FIG. 12is a flow diagram illustrating method1200for determining whether a tenant admin/user (herein referred to as user) is authorized to access statistics of a Tu at a storage system according to one embodiment. For example, method1200can be performed by storage system304. Method1200can be implemented in software, firmware, hardware, or any combination thereof.

Referring now toFIG. 12. At block1205, a storage system receives a request from a user to access statistics of a Tu. At block1207, the storage system determines whether the requesting user is a system admin. In response to determining the user is not a system admin, the storage system transitions to block1210. At block1210, the storage system determines whether the tenant admin/user is authorized to perform the requested operation and also authorized to access the object on which the operation is to be performed. For example, block1210may be implemented using operations similar to those described in method1100.

At block1210, in response to determining the tenant admin/user is not authorized to perform the operation or not authorized to access the object on which the operation is to be performed, the storage system transitions to block1215and denies the request. Alternatively, in response to determining the tenant admin/user is authorized to perform the operation and authorized to access the object on which the operation is to be performed, the storage system grants the request and transitions to block1220.

Referring now back to block1207. In response to determining the user is a system admin, the storage system grants the request and transitions to block1220. At block1220, the storage system determines that the specified Tu name complies with a predetermined Tu naming convention. At block1225, the storage system determines that the specified Tu exists in the system. At block1230, the storage system obtains the Tu ID for the specified Tu name from the config-metadata store. For example, SMT engine315may determine that Tu name element430contains the specified Tu name, and obtains the TU ID contained in the associated Tu ID element431.

At block1235, the storage system obtains the FSMOs that are associated with the Tu ID from the DM attribute store. For example, storage system304may determine that Tu ID456contains the Tu ID obtained at block1230, and obtains the FSMO ID(s) contained in FSMO ID455. At block1240, the storage system obtains the statistics (e.g., quotas, usage, performance, etc.) associated with the FSMOs identified by the FSMO IDs obtained at block1235. At block1245, the storage system provides the statistics to the requesting user, for example, via a graphical user interface (GUI).

FIG. 13is a flow diagram illustrating method1300for determining whether a user is authorized to access data of a Tu at a storage system according to one embodiment. For example, method1300can be performed by storage system304. Method1300can be implemented in software, firmware, hardware, or any combination thereof.

Referring now toFIG. 13. At block1305, a storage system receives a request from a user to access data of a Tu. Here, data access can be a read, write, or replicate operation. At block1310, the storage system obtains a user ID for the specified user name from the protocol config-metadata store. For example, storage system304may determine that user name466contains the specified user name, and obtains the user ID contained in the associated user ID467.

At block1315, the storage system obtains the Tu ID(s) associated with the obtained user ID from the protocol config-metadata store. For example, storage system304may determine that user ID467contains the obtained user ID, and obtains the Tu ID contained in the associated Tu ID468.

At block1320, the storage system obtains the FSMO ID from the DM using the specified FSMO path. For example, DM405may determine that path element472contains the specified path (i.e., the path specified as part of the request) and obtain the ID contained in the associated FSMO ID element471.

At block1325, the storage system determines whether the protocol config-metadata store indicate that the FSMO IDs associated with the Tu IDs that are associated with the user ID match the FSMO ID obtained from the DM. For example, DM405may determine that path472contains the specified FSMO path, and obtains the ID contained in the associated FSMO ID element471. Assume that user ID element467contains the user ID obtained at block1310. In such an example, storage system304compares the ID contained in FSMO ID471against all the ID contained in FSMO ID469. If there is at least one match, storage system304determines that protocol config-metadata store412indicates the user is authorized to access data from the specified FSMO, and transitions to block1330to allow the access. Otherwise, the storage system transitions to block1335and denies the request to access data from the specified FSMO.

FIG. 14is a block diagram illustrating a SMT ecosystem according to one embodiment. For example, storage system1401may be implemented as part of storage system304. In the illustrated example, storage system1401has allocated four Tus: TuA, TuB, TuC, and TuD. TuA includes FSMO A which can be accessed by NetBackup (NBU) system1410using a data-access protocol (e.g., the DDBoost protocol). TuB includes FSMO B-1which can be accessed by Networker system1411using a data-access protocol (e.g., the DDBoost protocol). TuB also includes FSMO B-2which can be accessed by Networker system1412using a data-access protocol (e.g., the CIFS protocol). TuC includes FSMO C which can be accessed by Avamar system1413using a data-access protocol (e.g., the DDBoost protocol). TuD includes FSMO D which can be accessed by App Direct system1413using a data-access protocol (e.g., the DDBoost protocol). Although client systems1410-1414are all accessing the same storage system1401, using the mechanism previously described, storage system1401prevents each client from accessing Tus that belong to others. Contrary to a conventional multi-tenancy storage system, storage system1401of the present invention allows an admin to be created for each Tu. As illustrated, TuA, TuB, TuC, and TuD are managed by TuA admin, TuB admin, TuC admin, and TuD admin, respectively.