turn A records into CNAME and point to one SmartConnect zone name ?  Maybe this is an opportunity to consolidate ?  Back in 2010 we migrated a lot of different schools with different VDM/CIFS servers from NS80  onto one isilon cluster. We did not have share name collisions so not too much drama. Each school gets one top level directory/share and then create subfolders for different departments and map users directly to subfolders.

>> I have been reading and setting up separate zones seem to be the way to go using separate IP's and mappings but they will point to the same AD for authentication

I understand "... but they will point to the same AD" as your finding for "zones" so far,

while your requirement is to have differents ADs for different "zones".

Maybe there is some confusion between OneFS SmartConnect Zones and OneFS Access Zones?

Set up one Access Zone per AD (and then at least one SmartConnect Zone for each Access Zone).

makes sense?

-- Peter

Consolidation is not possible unless we can map users to a specific set of shares with a c$ root designated for each campus and not to mention that it would be some 70+ TB's of consolidated data which would be to large of a volume. The main issue is users are able to map to the VG8 as \\my(campus)files\ with the my(campus)files being the CIFS server root c$ but on the Isilon users will have to map to \\isilon\my(campus)files\. We are trying to make as little impact on Staff and Faculty as possible and really need to keep the \\my(campus)files\ as the base directory for each campus. As for the AD and zones, yes, I understood it was frowned upon to have multiple Access Zones pointing to the same AD authentication source, if I'm wrong please let me know. As for SmartConnect Zones, this looks promising and I think doable but with 5 nodes we would need 11 IP's per site per SmartConnectZone in the same subnet. We have SmartConnect Advanced so if there is a better way, PLEASE, let me know. 

In the OneFS 8.0.0 Web Admin Guide I see the following...

• l Migrate multiple SMB servers, such as Windows file servers or NetApp filers, to a
• single Isilon cluster, and then configure a separate access zone for each SMB server.
• l Configure each access zone with a unique set of SMB share names that do not
• conflict with share names in other access zones, and then join each access zone to a
• different Active Directory domain.
• l Reduce the number of available and accessible shares to manage by associating an
• IP address pool with an access zone to restrict authentication to the zone.
• l Configure default SMB share settings that apply to all shares in an access zone.

The first bullet is what caught my eye but I am stuck with the 11 IP's per node (as I understand it) within the same subnet and it gets pretty messy (11X5=55 each x 9 SmartConnect zones = 495) and besides, 495 is a little larger than 252...

Any additional help is appreciated.

- Dave C.

you are used to having a dedicated volume on your Celerra gateway, no such thing on Isilon. You have one huge file system so i am not sure why you are so concerned about 70+ terabytes.

Not sure i understand your reference to c$, c$ on VG is the top level directory under which each VG file system was mounted.

If all your servers are on the same domain/domain with trust, i would create one groupnet, one access zone and use one SmartConnect pool (granted you don't have share name overlaps)

If you need to service different domains then you will get into different groupnets, access zones and SmartConnect pools

There is nothing wrong with multiple access zones using the same authentication provider. For example i have two access zones for CIFS clients, one access zone is used for "regular" office like shares, where another access zone is used for data that requires HIPAA compliance and needs to be audited (we use Varonis). Both access zones use the same authentication provider.

The number of IPs in one SmartConnect Zone should be divisible

by the number of nodes (N) to allow even balancing,

and by best practice also divisible by N-1 to allow balancing in case one node is down.

In you case that would be 5 * 4 = 20 for each zone,

but if you can live with a slight imbalance you can choose a lower number

like 10 = 2 + 2 + 2 + 2 + 2 (five nodes up) = 2 + 2 + 3 + 3 (four nodes up).

OneFS "groupnets" come into play when departments use also different DNS servers

in addition to different ADs.

As @dynamox pointed out, accessing a "default" share without a name like \\myserver\

cannot be done on Isilon -- at least not in an obvious way.

Cheers

-- Peter

If we chose to go with only single AD per access zone then wouldn't that be a single point of failure ? I prefer to have at least 2 per zone so HA and avoid SPOF. Comments ...

If you had a single AD *server* per domain, that would be a single point of failure, but the domain itself isn't a point of failure.  But AD domains can have multiple AD servers to protect against a failure of a server.

Do consider the syncIQ in which is the foundation for the DR ( real or test , in both cases). if you need 9 of your existing CIFS servers to be conducted in DR test separately then plan your sync IQ source folder structure accordingly.  It is single FS in ISILON , but if you need the flexibility of doing DR for each CIFS server separately then plan the policies not in the access zone level, rather go with the individual folders under the given access zone which would  represent the data of your nine respective CIFS servers.

Is there a known limitation of adding only one AD server per access zone ? We see that once we add the second from the GUI the firt AD disappear from the "Selected" list.

It's not really a limitation, it's really the purpose of having access zones, segregated data and segregated access for different tenants.  You couldn't join a CIFS server on VNX or a vfiler on NetApp to more than 1 AD domain at a time, this is the same.

But really try and keep these to a minimum.  You only need 1 join per trusted forest, not necessarily per domain.  And make sure you understand the limitations on the number of access zones permitted per cluster.  IIRC it used to be 5, but was later increased to 20 or something like that.  Look at the OneFS Limits and Boundaries guide for specifics.  (they may have renamed that document, but that's what it used to be called).

~Chris

isi auth ads trusts controllers list will clarify the number of AD servers behind the registered AD.

The soulution is to stand up a DFS Stanalone Consolidation Cluster. you can leverage setting up network name resources to emulate your namespace servers that you migrate to Isilon.

on migration/cutover day, you 1st need to rename your old servers, purge DNS and WINS entries for the old server, then create your new, join to AD. Then you can create the new instances for your DFS namespace and make sure to use a "#" for the name.  so your DFS root will be  \\previousservername\#previousservername. make sure to hang file system and shares on level down for your link target paths which would be \\isilonname\previousfileserver\flile-paths-here

make sure on your isilon that you add your sysadmins or sysadmingroups into the local Admins group of the Isilon. Will make your life easier.

two things two highlight from the recent ISILON implementation/migration efforts.

FTP is not supported to SMB CIFS servers if this resides outside the system zone. (it matters to us and we stopped migrating)

The share is global or unique in ISILON. But in VNX we can have very same share name under respective CIFS server. So if your  9 cifs servers has a common share name then one of them need to be renamed while migrating to Isilon