Michael wrote: > Speaking to others here, I may be the old fuddy-duddy unix greybeard > (without the beard, but still...). > My love of text files is not universally shared it would seem.
Test files are nice, but... I think the biggest key to this is being able to change settings at runtime. Writing to a text file is nice because, generally speaking, it's difficult to corrupt a text file. Yes, I know it's possible, but you really have to work at it.. ;P Databases also have that interesting drawback of "where do I put the database?" ... If it's on the node that fails, then what? Sure you can replicate, but cross replication with writes to both nodes can be quite challenging.. > I wish other would speak up about this. I think it's worth discussing. > In any case, the support tools would have to be written and tested well > before we move everything to the database. > pfcmd is still a work in progress in that respect I believe. Properly written, it should be really simple to switch from reading/writing text files to reading/writing to a database. In either case, the admin shouldn't have to be worried about where the config is being stored. Things should work well enough that this is irrelevant. It's more advanced users that I think want the database functionality. And that's primarily so we can manipulate things in a programmatic fashion. Since there isn't a robust API at this point, directly manipulating configuration is the only way to do things. Perhaps it may be even better to work on an API? Given a robust API, I would likely never try to directly access the database or text files. > To be frank, I am not sure this is the most critical thing keeping > us from > having an active/active HA setup, which I think is the ultimate goal > here. > We already know how to have an active/passive setup even though > there may > be room for improvement there too. Why would this prevent active/active? It shouldn't be hard to trigger an rsync when needed to sync the text files. There are, of course, drawbacks to this, but it can be done. OR.. at least one product we currently use leverages a promise-theory engine (CFEngine, Puppet, Chef, etc) to accomplish configuration changes across multiple servers. That *might* be overkill for packetfence, but maybe not.. Worth thinking about at any rate. > What I see as things to fix first is the issue of services running > on every > node of the cluster when they might conflict: > active/active dhcp (with shared list of leases between nodes), > active/active dhcplistener (currently may cause database issues if > running > more than one simultaneously), SNMP traps, iptables and ipsets in > inline > mode etc. active/active dhcp using ISC DHCP is actually really easy. We run this already. The only real limitation here is that you can only have two nodes, but I don't see that as an issue for packetfence at this stage. > Some of them require rewriting a service (DHCP), while others > require that > we decide how to deal with devices that may only send packets to a > single > IP (SNMP in the case of some switches). > Do we use a virtual IP for the cluster? That's one more thing to > manage, > one more thing that can fail. This isn't strictly true. I can only speak for Cisco here, but I can configure the switches to SNMP traps to more than one IP pretty easily. In fact, we do this quite often. The harder part (though I'm not sure it's *THAT* hard) is to have only one of the servers process the request. Should that be done by assigning switches to server? Maybe it's done in a first-in basis? I think the answer may depend on what the admin is after. Maybe it's load balancing, maybe it's speed. Or, maybe it doesn't matter either way and the admin just wants an HA setup with zero downtime in the event of a failure. You'd still need a virtual IP, though, just for handling access to the admin interface. > Fixing some of these issues would at the same time make an > active/passive > setup easier, so the benefits may be compounded and a valid strategy > may be > to do this incrementally until full active/active HA is acheived. Not a bad strategy. > None of these issues are unsolvable. I am not trying to belittle the > idea, > in fact in think it's a worthwhile goal. > But we should not underestimate the tradeoffs and choices it will > entail, > and operability should remain a primary concern. Yes. No breaking my servers, please. Packetfence is a tad important. :P > Ok, rant off :-) > Please do chime in people... DING! > L. -- --------------------------- Jason 'XenoPhage' Frisvold xenoph...@godshell.com --------------------------- "Any sufficiently advanced magic is indistinguishable from technology.\" - Niven's Inverse of Clarke's Third Law ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ PacketFence-devel mailing list PacketFence-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-devel
