Responses inline > -----Original Message----- > From: Michael Weinbergs [mailto:michael.weinbe...@wridgways.com.au] > Sent: Wednesday, June 16, 2010 7:23 PM > To: pound@apsis.ch > Subject: RE: [Pound Mailing List] RE: Ported to Windows? > > I should have been a little clearer in my post :) > > 1) Distribute ?d choice of words... pound will be behind three remote > links as "backups". Their configs will be identical. Distribution is > the > word I chose for getting replicative setups (pound.cfg) on each remote > link. I didn't mean "distributed-as-in-clustering". Sorry.
I didn't think you did... I meant if you try to zip up your c:\pound directory and put it on another server, one you might not fully control that might have different cygwin dll versions, without doing a full cygwin install/compile, you might run into issues. Seems like you have some type of control over the OS so you're probably ok :) > 2) I run vSphere in production and DR now - and there is a separate > project to P2V the remote sites to vSphere... but unfortunately this > pound-project has been bumped up the list - chicken-or-egg scenario. > The > Windows-based solution I seek is only temporary, until I get those > sites > virtualised. (BTW: I did consider VMware server/workstation at the > sites > - but they are just too underpowered - the virtualises project is part > of a hardware refresh). Good to hear! > 3) after I sent the post I started to think about CYGWIN. That's my > project for today. > I eventually noticed (once I discredited all of spurious google > results) > that this is well-trodden ground (eventually found someone posted a > W32-Pound-2.3-no-ssl on the 'net).. I'll see how I go with this today > and it might be the perfect temporary solution (yes, I do understand it > will be slow and sluggish... but better than what I have now!) It was ok... performance was "ok"... But the thing that got me was Windows' memory management, and some issues where it would lock for no reason... Maybe something in cygwin pthreads causes a deadlock; I never really figured it out. > Just so you understand where I come from here: we had a 6 hour outage > recently that even a BGP re-route could fix (the outage was in the > ISP's > core and took out all the BGP routes - as you can imagine - a big > problem affecting a LOT of companies and a 1 in a million...). it was > an > outage that was "never suppose to ever happen" - but it did. > Of course, this all came about whilst I was concurrently doing an > ISO270002 audit... so is now in the register and thus - "urgent" ;) > That's where I came across pound. With it I can keep provision of > webservices via a few other (different ISP) links.. and mitigate the > risks. > > Thanks to you all for your comments.. my apologies for not being > clearer > in my post. > > While I'm here: > Does anyone know a trick to get DNS "IN A" records to have a preference > (like "IN MX Preference")? > My next hurdle is - now I have pound at each of the sites - I only want > the remote sites involved during an outage. > If I put the IP's in to the A record (or CNAME them) - I will > essentially be doing round-robin or "first reply".. > The only way I can think to do this is to manually manipulate the NS > records, wait for DNS cache to refresh to pick up the new sites. > I'm concerned that the backup links will be slow so I don't want any > client to use them unless the core link is down. > If anyone has an idea to that I would appreciate feedback! I think the best thing you can do is set the TTL of the A record low... like 300 seconds. (You don't have to adjust the SOA) Cons: Every nameserver will re-ask for your A record every 5 minutes. Pros: Every nameserver will re-ask for your A record every 5 minutes. Then, at least, you can change the record and it'll take at most 5min to failover. Or you could get tricky, if your name server lets you do it, and give different responses based on source ips... I used the TTL method above to deal with our multi-ISP non-portable IPs situation. It was manual failover (I had to change the A) but it was better than nothing. Joe -- To unsubscribe send an email with subject unsubscribe to po...@apsis.ch. Please contact ro...@apsis.ch for questions.
