On Thu, 2006-06-15 at 08:51 -0700, Shidan wrote: > After reading up on new DNS features and some clarifications I've > asked people, I have to agree SRV records are something I definitely > have to implement, and John is totally right, but virtual ips are > still a more full proof solution, there are times that SRV records > won't work, using a cluster it will always work. I think that the very > best solution is to do both, and neither are complex to implement ;)
Definitely not trying to start an argument here; just curious; in what situation would an SRV record not work but a cluster would? On the contrary, I think there are several situations where SRV would work but a cluster would not. Clustering requires you to have the machines at the same physical location (since they are sharing an IP). If something happens at your location (fire, backhoe, internet provider routing issue etc.) both nodes of your cluster will be down. SRV lets you have your servers geographically dispersed which is much more reliable than a single location. And lets not forget that SRV also lets you do load balancing at the same time as redundancy. Therefore, unlike a fail-over cluster situation, many machines can be active and if one goes down SRV transparently handles it. Of course you need redundant PRIs to make this work but they are available. I more or less agree that a properly implement cluster would work just as well in most situations you are likely to encounter but I will respectfully disagree that clustering is as easy to setup and maintain as a SRV DNS record. Regards, John Lange > > Regards, > Shidan > > On 6/15/06, John Lange <[EMAIL PROTECTED]> wrote: > > At the risk of sounding redundant; you don't need any of this fancy > > clustering, virtual IPs etc. etc. > > > > All you need is to use SRV records in your DNS and tell your client > > hardware to use SRV lookups. > > > > John > > > > On Thu, 2006-06-15 at 10:34 -0300, [EMAIL PROTECTED] wrote: > > > Has anyone looked at using the CARP protocol to share virtual IPs between > > > two servers? This was developed on OpenBSD but looks like it has been > > > ported to Linux as Ucarp. I use it for our two OpenBSD firewalls and the > > > switchover to the secondary server is instantaneous. You would need a > > > second NIC in each server to run the pfsync protocol between them. This > > > is > > > great for maintenance too. You just down the server you want to work on. > > > Trickier if a T1 is attached of course. > > > > > > I don't know if Asterisk is working well on OpenBSD because of Zap driver > > > problems but I would like to give it a shot some time. I noticed that > > > Asterisk > > > is in the packages. > > > > > > Peter M. > > > > > > > The problem is those pesky TTLs. I believe the big resi providers (ie: > > > > Sympatico & Rogers) are > > > > manipulating them, so even though you have yours set to 1 hour or > > > > whatever, your customers > > > > who get their DNS via their providers will be given something that's > > > > almost a week old. I'm not > > > > sure if they've stopped this practice or not, but last time I checked, > > > > that's the way they operated. > > > > > > > > Of course to get around it, you could easily ship your devices with > > > > your DNS servers set, but most > > > > of that info is user configurable so they could bork it on you. > > > > > > > > - Ian > > > > > > > > On 6/14/06, Nabeel Jafferali <[EMAIL PROTECTED]> wrote: > > > > Simon: > > > > > > > > Although it is true that DNS is cached and round-robin DNS would > > > > cause a 50% > > > > failure of calls in case one of the servers failed, DNS SRV is a > > > > different > > > > animal. > > > > > > > > "Smart" SIP endpoints know to look at all SRV records and the RFC > > > > provides > > > > for priorities, so caching the DNS entry is not an issue. > > > > > > > > Nabeel > > > > > > > > > > ******************************************************** > > > Peter MacFarlane, ACP > > > Network Administration & Programming > > > Target Call Center/ Message Centre P.E.I. > > > ***************************************************************** > > > OpenBSD's PF Firewall: Now available with CARP Failover. > > > Nothing to do with fish, but everything to do with security! > > > ***************************************************************** > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
