دسته‌بندی نشده

پیکربندی شبکه ای EMC Isilon SmartConnect

آوریل 12, 2016
admin

پیکربندی شبکه ای EMC Isilon SmartConnect

Looking back that the SmartConnect Part I post, remember that SmartConnect is handling DNS delegation of the SmartConnect Zone name (FQDN)… So… What happens if the SmartConnect Zone for an NFS data network is on an isolated network? Keep in mind, that DNS needs to contact the SmartConnect Service IP to request an IP resolution for the FQDN.  How can this happen if the SmartConnect Service IP for that zone is on an isolated network?

The first network defined for the “front-end” is typically configured as subnet0.  It is a common practice to leverage subnet0 for the management of an Isilon cluster.  When using IP based storage in vSphere environments, it is a best practice to have the storage traffic isolated from the regular network.  In my previous posts (SmartConnect Part I & SmartConnect Part II) the SmartConnect Zone was on the same subnet/pool.  When this is the case, and isolated networks are being used, it is impossible to leverage SmartConnect on the isolated network, unless there is a DNS, and subsequent delegation, in that isolated network.

In my demo environment, I have the following configuration:

  • 8 Isilon nodes
  • subnet0 configured with
    • subnet 192.168.1.0
    • netmask 255.255.255.0
    • gateway 192.168.1.1
    • SmartConnect service IP: 192.168.1.80
    • SSIP DNS Name: ssip.domain.local
  • pool0 configured with
    • IP range; 192.168.1.81-192.168.1.88
    • Zone name: isilon.domain.local
    • SmartConnect service subnet: subnet0
  • subnet1configured with
    • subnet 172.16.1.0
    • netmask 255.255.255.0
    • gateway 172.16.1.1
    • SmartConnect service IP: 172.16.1.80
    • SSIP DNS Name: ssip.nfs.domain.local
  • pool1configured with
    • IP range: 172.16.1.81-172.16.1.88
    • Zone name: isilon.nfs.domain.local
    • SmartConnect service subnet: subnet1

     

The following graphic details the typical look-up process for the isilon.domain.local SmartConnect Zone.

The process is as follows:

  1. Query the Isilon Fully Qualified Domain Name (isilon.domain.local)
  2. DNS delegates the query to the SmartConnect Service IP (ssip.domain.local DNS record)
  3. SmartConnect gives out the SmartConnect Zone Name
  4. The FQDN is accessed by the Management Network

Because the IP returned is on the 192.168.1.x range, the data flow is between the vSphereManagement Network and subnet0/pool0 of the Isilon Cluster.

As previously stated, this isn’t the preferred method.  Subnet0/pool0 aren’t isolated.

We really want our NFS datastores to be accessed on our NFS Storage Network (172.16.1.x) which is serviced by subnet1/pool1 on our Isilon Cluster, with the SmartConnect Zone name ofisilon.nfs.domain.local.

Following the same process, it would be:

  1. Query the Isilon Fully Qualified Domain Name (isilon.nfs.domain.local)
  2. DNS delegates the query to the SmartConnect Service IP (ssip.nfs.domain.local DNS record)
  3. SmartConnect gives out the SmartConnect Zone Name
  4. The FQDN is accessed by the NFS Data Network

But this doesn’t work… Because there is no connectivity from our DNS server to our SmartConnect Service IP for our second Zone (isilon.nfs.domain.local).

Examining at the SmartConnect settings for each pool will show why this does not work.

Pool0

Pool1

Notice how each pool is leveraging the SmartConnect service subnet that it resides in?

Pool0, which is part of subnet0, is using the SmartConnect service subnet of subnet0.

The DNS server has access to subnet0, and can properly return a value for isilon.domain.local.

Pool1 on the other hand, is configured for a SmartConnect service subnet of subnet1.

Because the DNS server does not have access to subnet1, it cannot delegate to the SmartConnect service IP (172.16.1.80) for resolution of isilon.nfs.domain.local.

Making a couple changes will correct the issue.

  • Update the DNS Delegation to point to ssip.domain.local
    (which is on subnet0, and accessible by the DNS server)
  • Update the SmartConnect service subnet for subnet1/pool1 to use subnet0 to answer SmartConnect queries on behalf of subnet1.

Now the process is:

  1. Query the Isilon Fully Qualified Domain Name (isilon.nfs.domain.local)
  2. DNS delegates the query to the SmartConnect Service IP (ssip.domain.local DNS record)
  3. SmartConnect gives out the SmartConnect Zone Name
  4. The FQDN is accessed by the NFS Data Network

Attempting this again, shows the proper results.

This graphic demonstrates the process:

In my previous SmartConnect posts (SmartConnect Part I & SmartConnect Part II), I did not really cover the process of assigning a different SmartConnect service subnet to accommodate for subnets/pools that were isolated.  I hope that this clears things up.

And just for refreshers, the Best Practice Guide can be found here: EMC Isilon Scale-out Storage and VMware vSphere 5 Best Practice Guide.

Thanks go to James Walkenhorst for his input.

Update: Something I forgot to add. in the past, I have always setup a gateway address and SmartConnect service IP on each subnet I had created.  Upon standing up a new cluster tonight, I realized that the above method also works for subnets/zones that do not have a SSIP associated with it.  In standing up a new cluster, I left the SmartConnect service IP blank (not really using it on the isolated network), and it still works.  Again, this is because the SSIP for subnet0 is answering for the SmartConnect Zone on subnet1.  (I used different addresses, as my primary cluster is still running)

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *