Isilon SmartConnect without DNS Server

Hello Alex,

Yes for name resolution you need to setup FQDN entry in hosts file else you can try defining  smartconnect ip address to check if that works.

we can use the emc isilon cluster without dns in production environment , where we have 1000 users ?

Sandeep,

Was that a question or a statement?  If a question; Yes you can use Isilon without any DNS infrastructure at all with 1,000, or 30,000 clients. But I would advocate against it, strongly.  Do you actually have a network with 1,000 or more clients and no DNS infrastructure at all?  Or is it simply difficult to get DNS changes?  You can certainly as mentioned above make the SmartConnect Service IP be a DNS server in /etc/resolv.conf or similar, but it'll only answer for the names that you have configured as SmartConnect Zone Names, or SmartConnect Zone Aliases.  Using IP addresses it not advisable, because you take all intelligence away from the SmartConnect feature and it's abilities to load-balance the traffic, and avoid nodes where maintenance is being performed, etc.

~Chris

We have infra with 13 nodess cluster 1000 users and dns sever .isilon cluster is integrated with DNS server now. but we are plannig use access zone and DNS server per AZ. which is not supported now .

i got two suggetsion

1) DNS forwarder

2) Use Smartconnect as DNS (in this i need to make host entry in each client)

Understood, and are these totally separate tenants where DNS requests couldn't even flow through a firewall?  If not there is certainly still a workable solution, that i'll lay out as a sample:

clustername: isi01

global network config:

     subnet0: 10.123.1.0/24

          gateway: 10.123.1.1

          SSIP: 10.123.1.10  (DNS as isi01-ssip.domainA.com

     subnet1: 10.123.2.0/24

          gateway: 10.123.2.1

          SSIP: NONE

System Access Zone:

          subnet0:pool0: (static for SMB, NFSv4, FTP in domainA.com)

               SmartConnect Zone Name: isi01-s0.domainA.com (in NS to isi01-ssip.domainA.com)

               10.123.1.11-10.123.1.20

                Interfaces: Nodes 1-3 10gige-1, 1-3 10gige-2

                Smartconnect Service Subnet: subnet0 (This says what SSIP do I listen for this zone name on)

Access Zone 2:

          subnet1:pool1: (static for SMB, NFSv4, FTP in domainB.com)

               SmartConnect Zone Name: isi01-s1.domainB.com (in NS to isi01-ssip.domainA.com)

               10.123.2.11-10.123.2.20

               Interfaces: Nodes 4-6 10gige-1, 4-6 10-gige-2

               Smartconnect Service Subnet: subnet0

So this uses the DNS requests all sent to an SSIP in subnet0/domainA.com, but honestly that's OK as long as port 53 TCP and UDP can get through.  You could also create an identical A record for the SSIP in domainB, so isi01-ssip.domainB.com, and delegate to that A record in DomainB, and still you just need to open TCP/UDP 53 to that 1 IP address, and it should work without any fancy use a totally separate DNS Forwarder type of actions.

Make sense?  And even though the DNS request is going into an IP in subnet0, it'll respond with an IP based upon the zone name you're trying to connect to, so if you're trying to connect to isi01-s1.domainB.com, you will get an IP back from subnet1:pool1, even though the request doesn't even travel on that subnet.

~Chris

Right on the money, now as I understand it that this 2-way conversation actually occurs between the DNS servers on the 10.123.2.0 network and the SSIP on 10.123.1.10.  The DNS servers on 10.123.2.0 then would forward the responses received on to the clients themselves on that side of the firewall.  This is important to understand when designing ACLs for the firewall tables.  This is also a reason why if Microsoft DNS servers are in use (which have a DNS TTL value minimum of 1 second on NS Delegations), that 2 simultaneous requests (within 1 second) may get the same IP instead of being round-robined properly with smartconnect, because the DNS server doesn't bother to ask again.

~Chris

so you still have to poke holes in the firewall.  Replies from subnet0 and subnet1 back to DNS server will alway come back from 10.123.1.10 correct ?

We have used this setup for subnets that are used for VMware datastores. These subnets are not routable so the request comes from ESX server on subnet0 but replies back with an IP address from subnet1 (private network to ESX servers)

Chris Klosterman wrote: Right on the money, now as I understand it that this 2-way conversation actually occurs between the DNS servers on the 10.123.2.0 network and the SSIP on 10.123.1.10.  The DNS servers on 10.123.2.0 then would forward the responses received on to the clients themselves on that side of the firewall.

Chris,

are you sure about that, let's assume this configuration

ESX server:

public network - 10.123.1.0/24     - isi01-s1.domainA.com (SSIP 10.123.1.10)

private network - 10.123.2.0/24  (not routable).  - isi01-s1.domainB.com

My ESX servers use public network (as that is their default route) to ask DNS server how can i get to isi01-s1.domainB.com. DNS servers sees an NS record that points to 10.123.1.10 and sends the request there. That request arrives at Isilon and since subnet0 is responsible for subnet isi01-s1.domainB.com , it will reply with an IP address from 10.123.2.0/24 IP pool. That reply is coming back from 10.123.1.10.   Did i misunderstand your reply ?

Dynamox,

No, you didn't mis-understand my reply, it's just we're talking about apples and oranges here.  Your ESX hosts are all going to be multi-homed, so they are actually going to touch both networks.  This thread was started with a 2-access-zone configuration, meaning multiple tenants with different DNS infrastructures, different AD forests, and likely a firewall in the middle, and so the question was around how to configure the DNS records best in such an environment.   The answers usually end up for this as:

1. Create a separate DNS enviornment for the cluster that both domains can talk to

2. Do as I suggested and simply permit the DNS trafic through the firewall and just use 1 SSIP.

The cluster itself still cannot be configured to talk to multiple DNS server infrastructures, but that is really about it asking for things via DNS.  Perhaps this will or won't be an issue in this case.  Things like are you comfortable using just IPs in your NFS exports.  If you've configured the cluster's DNS servers to be the Servers in DomainA, do they have a forwarder in DomainA to be able to get records from DomainB.  If this is a single corporation with say an Engineering and a Finance department that are separated, this is a more mundane excercise because most likely these DNS pre-reqs are already in place.  If it's a hosting-provider with multiple tenants, it's a bigger challenge.

~Chris