On Mon, 3 May 2010 22:34:02 -0400 Wes Rogers <skolpat...@gmail.com> wrote:
WR> 2010/5/3 Ted Zlatanov <t...@lifelogs.com>: >> On Mon, 3 May 2010 15:07:43 -0400 Wes Rogers <skolpat...@gmail.com> wrote: >> WR> Seems like too much effort to me, IMO when I can just add another WR> 'cfservd server' behind my LB VIP and call it a day. >> >> You still need a way to propagate policy between multiple cfservd >> servers. What happens when one of them is offline, misses a policy >> update, but comes back as far as the load balancer is concerned? You >> either need to bring the out-of-date cfservd up manually or set up a >> tightly coupled update process with the load balancer to tell it when >> the host is "ready." >> >> Resolving that inconsistency automatically at the cfservd storage >> backend is what I mean by a backend with "eventual consistency." WR> For us, our policy gets refreshed every hour from SVN on all "servers" WR> (or whenever manually). You could be distributing outdated policies to your clients for up to an hour if you miss a SVN update on a server. There are many situations (conflicts, for instance) where SVN will abort forever without manual intervention *and* give you an outdated or corrupted file. Finally, if a SVN commit happens between the pull instant for cfservd's A and B, you'll have cfservd A serving outdated policies whenever your load balancer points to it. All of this could be avoided if cfservd used a centralized ACID storage backend but then you have a single point of failure. So my original point was about doing it without ACID, in a distributed way, and with eventual consistency. Ted _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
