Re: [ActiveDir] DDNS in Unix environment
And cheap and easy. You forgot those two descriptors of using DNS vs intelligent load balancers. :) Conditional forwarding? Hmm So if I understand this correctly, the application has to have triggered a change and the DNS has to be notified of the change. If you're using conditional forwarding, do you not expect there to be a lag in replication in the case that the application is down in the pri site but DNS is still operational? Is that time lag acceptable? The one where the BC site realizes it's now the application owner node, updates DNS in it's own site (that's it's own view and the pri site application node is defunct at this point; can't count on it to do anything) and replication occurs and cache gets refreshed. That could be a while longer then currently expected, but you may have already thought of how the mousetrap will work so I may just be repeating your thoughts. Al On 6/21/06, Guy Teverovsky <[EMAIL PROTECTED]> wrote: All good and valid points, Al. The problem with DNS in this case is that DNS servers responsible for the AD zone must be located on the same segment as the application/DCs - this is client's requirement that I am totally agreeing with - we want to keep all the resources related to the application under strict control and behind the firewall. As for DNS redundancy - DRP site also has 2 DCs with DNS installed, so if the primary is down, the DCs in the DR site will be able to answer the queries. People accessing the application can resolve the DNS name of the service using their local DNS servers that can utilize conditional forwarding to both primary and DR site's DNS servers. The point with the whole setup is that each node at primary or DR site is already HA and the main purpose of the DR site is to come up when the primary site as a whole is down. Yet I do not like making assumptions and would like to be able to deal with all the edge cases. I'll ask ~Eric if I can borrow his huge DIT for a while, use it on the Unix guys and see how it goes ;). Relying on DNS in this case to me sounds too opportunistic... Guy From: Al MulnickSent: Tue 6/20/2006 3:53 PM To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] DDNS in Unix environment 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
RE: [ActiveDir] DDNS in Unix environment
All good and valid points, Al. The problem with DNS in this case is that DNS servers responsible for the AD zone must be located on the same segment as the application/DCs - this is client's requirement that I am totally agreeing with - we want to keep all the resources related to the application under strict control and behind the firewall. As for DNS redundancy - DRP site also has 2 DCs with DNS installed, so if the primary is down, the DCs in the DR site will be able to answer the queries. People accessing the application can resolve the DNS name of the service using their local DNS servers that can utilize conditional forwarding to both primary and DR site's DNS servers. The point with the whole setup is that each node at primary or DR site is already HA and the main purpose of the DR site is to come up when the primary site as a whole is down. Yet I do not like making assumptions and would like to be able to deal with all the edge cases. I'll ask ~Eric if I can borrow his huge DIT for a while, use it on the Unix guys and see how it goes ;). Relying on DNS in this case to me sounds too opportunistic... Guy From: Al MulnickSent: Tue 6/20/2006 3:53 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] DDNS in Unix environment 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 KasdorpSent: Mon 6/19/2006 5:55 PM To: ActiveDir@mail.activedir.org 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 no
Re: [ActiveDir] DDNS in Unix environment
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 KasdorpSent: Mon 6/19/2006 5:55 PM To: ActiveDir@mail.activedir.org 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 MulnickSent: Monday, June 19, 2006 4:01 PMTo: ActiveDir@mail.activedir.orgSubject: 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 (R
RE: [ActiveDir] DDNS in Unix environment
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 KasdorpSent: Mon 6/19/2006 5:55 PMTo: ActiveDir@mail.activedir.orgSubject: 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 MulnickSent: Monday, June 19, 2006 4:01 PMTo: ActiveDir@mail.activedir.orgSubject: 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 nodeDR 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
RE: [ActiveDir] DDNS in Unix environment
You could look at http://www.simplefailover.com/ (never used or tried this – just found it in a google search) Or you could look at writing a WMI script yourself to update DDNS as long as you can find some way to trigger it. In that case http://www.iisfaq.com/Default.aspx?tabid=2986 may be of some assistance. Hope this helps __ Mike Guest | Capgemini | Sale Server Support | Outsourcing UK Office: + 44 (0)870 366 1814 | 700 1814 | [EMAIL PROTECTED] 77-79 Cross Street, Sale, Cheshire. M33 7HG Join the Collaborative Business Experience __ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: 19 June 2006 15:01 To: ActiveDir@mail.activedir.org 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 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
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: ActiveDir@mail.activedir.org 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
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 nodeDR 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
[ActiveDir] DDNS in Unix environment
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
