Network Zones across 10g trunks

[Scot]

Hi, 

 I have a Celera and a 3 node Isilon. 

 

Trying to setup the Isilon to support the Celera as a migration target and support new corporate needs in a separate IP space and AD Domain. 

Q: How can I have the 10G-agg ports support both Groupnets or am I limited to one groupnet per interface ?   

Goal is to have the Isilon support all service through the same set of 10gige-agg interfaces. In a failover mode like a Celera mover so I can move over the share IP with the data. In the event a interface in the agg or node goes dark the ip fails over. 

I have two Groupnets defined but cannot use the same set of agg ports to support them. 

Corporate

HostingServices 

Am I missing something or Isilon designed for one distributed network service across all nodes?  A doable migration but more complicated. 

Thanks 

[Adam Fox]

First, let's make sure you need 2 groupnets.  The purpose of groupnets is to support multiple sets of DNS servers for multiple tenants.  This is critical if you have, for example, 2 AD domains that are know by 2 different set of DNS servers.  From what you describe below, that could necessitate two groupnets.  However, if one set of DNS servers can answer SRV calls for both domains, you can use a single groupnet.  

Next, each groupnet must have at least one subnet in it.  The assumption is that if you need groupnets, the tenants are on separate subsets.  Now, each node has 2 10Gb ports and it's reasonable to want to use both ports for both subsets.  This is supported through VLAN tagging.  To enable this on the cluster side, go into each subnet and assign it a vlan ID.  Then do whatever you need to do on the switch side as well.  Now you can set up your IP pools and, ultimately, your SmartConnect zones using the aggr interfaces and the system knows which VLAN ID to use as the tag by the subnet of the pool.

Make sense?

-- Adam Fox

adam...@yahoo.com

--
You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Scot]

Thanks Adam, I left some details out for easy reading.  I have 2 groupnets but sounds like I don't necessarily need them. On one groupnet I already have several subnets and pools. 

domin.hosting.com, Hosting Groupnet

We have a VLAN for every application sometimes more. From the Celerra we have one IP from that VLAN as a share. I moved the share IP over by creating a pool of one IP. That pool is supported by all 3 10gig-agg interfaces on each Isilon Node. The Aggregation mode for the pool is set to failover.  I would expect the IP's to failover to another node should the agg interface or node go offline. Tested this but just a little back story and feel free to poke holes. 

domain.corporate.com Coporate Groupnet  

Separate AD domain but DNS is recursive so forwards lookups work but reverse does not. I would like to use the same set of 10gig-agg interfaces as well as for the System or Management Groupnet as well so the default route to cloud providers is through 10gig-agg also. 

Hope that is a little clearer picture. SmartConnect is not licensed.

From what you just said this should be accomplished by moving everything to one single Groupnet and limiting access by directory and share permissions ?

Thanks again, 

Scot 

To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-group+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-group+unsubscribe@googlegroups.com.

[Adam Fox]

Sounds like you are on the right track.  Just keep in mind, while you may have had one address for your CIFS server on the Celerra, you will want a pool of addresses (at least one per node per subnet) on the Isilon with the name being an NS record pointing to the service IP rather than an A record that points to one node.  The idea behind SmartConnect (even basic without the license) is to try and balance the clients across all the nodes without the clients needing any special software or have any knowledge of the Isilon.  It's a pretty slick idea once you get it.

If your clients are SMB, there is no reason for addresses to move in the case of a failure and they won't in a static pool.  The reason is that SMB clients do not follow an IP address if it moves.  Even with SMB3 with CA, the client negotiates multiple addresses and moves to a new address upon failure. An SMB2 client will drop the connection and then next time a user tries to access the share, it will get a new address via SmartConnect (because we return a TTL of 0) and then it reconnects to a live node.  For addresses to move upon a node failure, which is used by NFS clients, you would have a dynamic pool for your SmartConnect zone.  But dynamic pools require the advanced license and if you don't have it, that option will be greyed out in the WebUI and not allowed on the CLI or with the API.  But if you do not have NFS clients, dynamic zones aren't necessary since SMB behaves differently anyway.

My thought would be to have an NS record for each CIFS server you had on your Celerras.  Each CIFS server name would be either the name of a SmartConnect zone or an alias to an SC zone if they are to share the same IP pool.  That way each of your old CIFS server will have access to all of your nodes.  This is good for redundancy as well as performance.  NIC failover with your two 10Gb ports is fine and with tagging the aggr interface can live on all of your subnets.

Understanding IP pools and SmartConnect is an important part of setting up an Isilon, IMHO.  If you need help with that, I'd start by reaching out to your Isilon SE.  Those folks should know this stuff cold.

-- Adam Fox

adam...@yahoo.com

To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.

[Scot]

Thanks again Adam, 

Looks like I have some re-work and research to do. We do have SMartConnectADV. For the celerra workloads I hadn't planned on using anything more than to replicate a failover IP some of these vlans are tight and I'd like to reserve 8 addresses if I go that route because that is max nodes in our frame. I do plan on doing this for a new service address like hdfs://storage.corporate.com, cifs://storage.gannett.com. 

For NFS is sounds like I can still have a single IP pool when needed but recommend the "Allocation Method" to be dynamic ? 

System/Management can exist on the same physical set of gig-agg interfaces. 

[Adam Fox]

Yes, there are no dedicated management ports today.  Any port with an IP in the system zone can be used for management.

NFS clients benefit from a dynamic zone as IPs in a dynamic zone can move as the number of available interfaces change for any reason.  NFS clients grab on to an IP and tend to not let go so this works for them.  Other protocols like SMB, for example, do not do this and either require the client to reconnect (SMB 1/2) or have a CA capability that moves the client connections to another IP (SMB3).  For these protocols, static zones make more sense.

-- Adam Fox

adam...@yahoo.com

To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

<Screen Shot 2017-02-15 at 8.00.53 PM.png>

[Dan Pritts]

For the record, when Adam says "NFS" he means NFSv3.  If you don't know what version you're running it's probably nfs3. 

NFSv4 is different - not sure if it fails over like SMB3 or  needs to reconnect like SMB1/2.  

'Adam Fox' via Isilon Technical User Group

February 16, 2017 at 2:03 PM

Yes, there are no dedicated management ports today.  Any port with an IP in the system zone can be used for management.

NFS clients benefit from a dynamic zone as IPs in a dynamic zone can move as the number of available interfaces change for any reason.  NFS clients grab on to an IP and tend to not let go so this works for them.  Other protocols like SMB, for example, do not do this and either require the client to reconnect (SMB 1/2) or have a CA capability that moves the client connections to another IP (SMB3).  For these protocols, static zones make more sense.

-- Adam Fox

adam...@yahoo.com

On Feb 15, 2017, at 8:09 PM, Scot <sco...@gmail.com> wrote:

--
Dan Pritts

ICPSR Computing & Network Services

University of Michigan 

[Adam Fox]

For NFSv4, you can use dynamic zones starting in 8.x.  Prior to that, it worked, but not consistently and wasn't officially supported.

-- Adam Fox

adam...@yahoo.com