Isilon vs. SONAS Part 5: Multiple Authentication Sources for Multi Tenancy

Keywords: Multi tenancy, Isilon, SONAS, Authentication, Active Directory, LADAP

Article based on SONAS Version 1.3 and Isilon Version 7.0.1

For large scale NAS systems like SONAS and Isilon it would make sense for some customers, predominantly service providers, outsourcing companies and cloud providers to have a system that fully supports multi tenancy. Unfortunately the term multi tenancy is not standardizes so different people have different understanding of it. On the networking layer, we would think about separating network traffic through VLANs or encryption methods while on a server layer we think about different user roles and permissions etc. On the storage layer we care about data integrity, privacy, secure data access  and management privileges and others. And this is by far not complete but should give a little idea that multi tenancy spawns a wider area of the HW/SW stack.

In this article I will focus on some (current) capabilities of SONAS and Isilon with respect to multi tenancy. In general we have to admit that both products have limited capabilities in that regard and are far away from providing a complete multi tenant solution (as of today). However, both IBM and EMC are working on enhancements since these are essential for large companies, service and cloud providers.

In this article I will just compare the capabilities to use multiple authentication sources. It is a basic functionality that is not only required for a multi tenant environment but also for server consolidation.

The following table outlines the supported authentication providers by SONAS and Isilon:

SONAS 1.3  [1]	Isilon 7.0.1
· Active Directory (AD) incl. Microsoft SFU for UNIX · LDAP · Samba (PDC - NT4) · Network Information Service (NIS)	·   Active Directory (AD) incl. Microsoft SFU for UNIX ·   LDAP ·   Network Information Service (NIS) ·   Local Database ·   Local Files
Can use multiple sources at the same time: no	Can use multiple sources at the same time: yes

Beside the fact that Isilon also supports  local database and file providers (/etc/passwd like files, very useful if for example you want to migrate a NetApp filer with local authentication files, you can just copy them over to Isilon…), the biggest difference is that SONAS supports only one authentication source [2] while Isilon supports multiple sources independently and at the same time. There can even be multiple AD or LDAP instances that are supported.

This is a major shortcoming of SONAS which makes it impossible to authenticate users from different AD domains that do not trust each other.  Very often this is not wanted for example employees of different companies who need to access a common file space are rarely members of the same domain. In this case a complex meta-directory needs to be set up as a workaround.These kinds of projects are complex and costly and I have seen several of them failing due to various reasons.

So can SONAS support a multi protocol environment with only one authentication source? The answer is yes. Both solutions have mechanisms to map UNIX UID/GIDs for NFS to SID for Microsoft environments. Although both products support an automated internal mapping I would strongly recommend using Microsoft AD with Services for UNIX (SFU) (in both cases). I will use the term SFU here although the actual Microsoft term for this service is called Subsystem for UNIX-based Applications. However, most admins are familiar with the term SFU. Beside a number of UNIX subsystems that can run under Windows our interest for SFU in this context is the fact that SFU enhances the AD schema with attributes that allow AD to store also UID and GIDs. This approach has the advantage that the mapping does not need to be performed in SONAS or Isilon. Especially if you run multiple clusters you may otherwise not be able to manage the user and group mappings in a consistent way.

As said earlier, SONAS only supports one authentication source while Isilon supports multiple sources as outlined in the following figure.

Figure 1: Isilon can authenticate against different sources

OneFS Access Zones

If we come back to our initial thinking on multi tenancy we need even more options for example to have a number of authentication providers of different sources that authorize users from separate organizations as well as providing/denying access to appropriate shares. In Isilon this is provided by Access Zones. For example, when Access Zones are used multiple AD servers can be configured to provide authentication. Technically there is a separate SMB daemon for each Access Zone to segregate users from each other. However, all Access Zones can provide access to the same data if required. So administrators have a very granular control over authentication and access across multiple disparate systems.

In addition, file shares can be associated to an access zone to restrict the presentation of those shares through that entry point. When a client attempts to access a share through a given access zone the configured authentication providers will be used to determine identity. A System Zone is configured by default to include all shares and exports.  The same zone is used to access through SSH and the admin interface.

Each Access Zone must be associated with an IP Address Pool, so that users accessing the EMC Isilon Cluster through specific IP address pools (or SmartConnect Zones) are directed to the appropriate Access Zone for authentication and authorization. Each IP Address Pool can be associated with only one Access Zone, but multiple IP Address Pools can be associated with the same Access Zone. SmartConnect Zones and pools can be associated with only one Access Zone, and Access Zones can support one or more SmartConnect Zone or pool. The following picture outlines these dependencies.

Figure 2: End-users connect via IP address pools (SmartConnect Zones) to the Access Zones within OneFS. There is a n:1 relationship which means an IP-Adress-Pool can only be associated with one Access Zone but multiple IP-Address-Pools can connect to one Access Zone.

While this looks great already on the Isilon platform there is currently an important limitation: it only works for SMB/CIFS clients, not for NFS. It seems that the NFS implementation is more copmplex. Nevertheless it is a good starting point and I guess we'll see this for NFS and other access protocols later as well. The following example illustrates a common use case for these Access Zones.

Use Case 1: File Server Consolidation

Assume a company has three file servers to consolidate but only on AD for authentication. In this case each Access Zone is associated with a separate SmarConnect Zone but the same AD. In this way, the clients can even use the same DNS name to connect to the Isilon cluster. However, the shares are only exposed to the appropriate Access Zone so that users in other Access Zones cannot access or even see the shares of the others.

Figure 3: Use case example: File Server Consolidation with different shares associated to Access Zones

Use Case 2: Company merger
In the following scenario, a single Isilon is used to integrate data from a Corporation Merger. Here you have typically different AD-Servers and in contrast to the first scenario, here each Access Zones is  associated with different AD server.

Figure 4: Use case example 2: Corporation Merger with different AD Servers


Summary
The capability of authentication against various authentication sources is a base foundation for a multi tenant environment and thus for cloud computing environments that require massive scale out NAS solutions. SONAS does not provide these capabilities and Isilon has the described, currently limited to SMB/CIFS.
Due to the importance for large scale and cloud environments  I expect enhancements in this areas for both platforms in the future.

References:

[1] IBM SONAS Information Center, planning for user authentication

[2] IBM Redbook, SONAS Concepts and Architecture, Dec 2012, Chapter 6.1.9 page 208