Guy, I think the concern I have (I'll limit to one for this sentence) is that if you update the DNS, what does that do for the client? I.E. how does the client know to look at some other DNS? Or, more simply, how does the DNS get updated if that site the client was using for DNS goes to the dogs?  I'm wondering how that mechanism works in your scenario because the client has to be able to find the information and if the DNS went with the solution, then it's going to be difficult to make that work.  On the other hand, if DNS is hosted outside this solution, then you're only real hope is to use a load balancer IMHO.  Why? Because the people already have a signifcant investment in making this work and to do otherwise would be the equivalent of putting Huffy tires on a Mazerati; sure it might work and it'll drastically cheaper up front, but would you really want to do that and would you really be happy about it?  Would you want your friends to see you in that car?
 
Anyhow, the solution lies with Veritas and by taking a good hard look at all 8 layers of the stack and comparing/contrasting that with your deliverables. HA doesn't occur at the application layer alone; rather it's a system that comes together and takes into account all 8 layers of the computing stack.  To do otherwise is without question a waste of time and resources.   
 
Keep your head low, walk softly and carry a very large Windows appliance. ;)
 
Al

 
On 6/19/06, Guy Teverovsky <[EMAIL PROTECTED]> wrote:
I will try to address all the points raised.
 
Al:
You are right. The idea is to provide highly available service as transparently as possible. This is one of those times when Unix folks are leading the project and they are trying to find the solution in the DNS. I have already pointed out that even if DDNS is successful, the TTLs will have to be reduced drastically to very short values.
 
Mike:
I have already suggested simple WMI script somehow triggered by the cluster, but they are hesitant about any non-standard customization. The SimpleFailover however looks like something that I might be able to use. Will defenetly have a better look at it. Funny that I have not found it while exercising my google-fu.
 
Willem:
If you ask me, the solution should indeed be based on some sort of appliance based load balancer, but the folks are looking into software based solution - introducing network related changes could be quite tricky in this case (politics, another IT group, single point of failure...)
 
Disclaimer: have no idea about Veritas HA Unix cluster either ;)
 
Now if I could only smack the Unix folks, make them disable DDNS registration requirement on the cluster and look into hardware load balancer, the life would be much easier...
 
Bottom line: Unix people are evil ! do not let them near your AD ;)
(ducking and getting on a plane)
 
Thanks all for the input !
Guy 
 

From: Willem Kasdorp
Sent: Mon 6/19/2006 5:55 PM
Subject: RE: [ActiveDir] DDNS in Unix environment

 

Guy,

 

Those are good points by Al. Especially the DNS TTL will break you up if the customer expects a quick failover. I would expect that there is some mechanism in the cluster failover (a script hook or something) that will allow you to manually change DNS where needed. But is this really the way to go? I'd take a hard look at how the app is supposed to realize high availability. Additionally, I have seen a similar scenario where a redundant network loadbalancer would reroute traffic to the active node. That would take care of name resolution and similar issues, anyway.

 

--

    Cheers, Willem

 

(disclaimer: I know nothing about Veritas HA clusters)

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Al Mulnick
Sent: Monday, June 19, 2006 4:01 PM
To: [email protected]
Subject: Re: [ActiveDir] DDNS in Unix environment

 

Guy, can we assume that the requirement is to provide the high availability as transparently as possible then?

What is the expectation if the primary site goes away as far as client name res? What is their way of knowing that the server went away and to use a new name (keeping in mind that caching etc is going to take place)?

What does Veritas recommend? (it is there product after all).

 

Al

 

On 6/17/06, Guy Teverovsky < [EMAIL PROTECTED]> wrote:


Howdy all,

I am banging my head over this trying to come up with a solution for a client.

To make the long story short: financial organization which is very concerned about security. They are setting up a new network segment that will be serving some application to the internal network (there is a firewall in between). Because of the critical nature of the application, there is a DR site. AD is used for authentication and DNS.
There is a Veritas HA cluster serving the application that will fail over to DR site in case the primary site goes down.
Primary site: 2 DCs with SFU (R2) + Veritas cluster node
DR site: 2 DCs with SFU (R2) + Veritas cluster node.
Primary and DR site are at different physical locations and on different subnets.

The only problem with this setup is that the cluster needs to register it's DNS name when failing over to DR site and it does not support secure DDNS. The best thing it can do is T-SIG DDNS with pre-shared key.
Enabling non-secure DDNS is not an option.

I can disable the DNS registration requirement in the cluster resource group, but this has some issues, while one of them is the fact that accessing the application at the DR site (from internal LAN) will require using FQDN different from the FQDN of the primary site.

An alternative would be to somehow enable DDNS only from a predefined set of IP addresses, but from what I know the MS DNS is not capable of it (correct me if I'm wrong).

Switching to BIND presents the same issue: while it can solve the dynamic registration of the cluster service using T-SIG DDNS, yet non-secure registration of SRV records is not acceptable and I would like to avoid having statically registered SRV records for the DCs.

Not sure whether the solution is in the MS DNS, but there are some knowledgeable folks over here that might have stumbled upon something like this.

Any help is greatly appreciated.

Thanks,
Guy

 


Reply via email to