Re: Developing and maintaining a rapidly deployable image of an installed system
Warren Guy warren@calorieking.com wrote: Hi everyone, I'm just wondering if there is an established best practice for developing and maintaining a rapidly deployable image of an installed FreeBSD system? If anyone can point me towards documentation or any other resources that might be of use I would greatly appreciate it. One of the tools we've been using extensively is FreeBSD's jail system. Especially with the ezjail port, it's pretty easy to have a backup tarball of each system that can then be easily deployed to another server if needed. It also makes it easy to migrate servers to other hardware in order to do upgrades, or re-balance workload if one particular piece of hardware is getting over or under utilized. The host system is a very basic install -- mostly just give it an IP and add users for the administrators. All the ports and details of their configs are in the individual jails. It's much more efficient than using something like VMware, which has horrific performance penalties. -- Bill Moran http://www.potentialtech.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Developing and maintaining a rapidly deployable image of an installed system
Bill Moran wrote: [...] The host system is a very basic install -- mostly just give it an IP and add users for the administrators. All the ports and details of their configs are in the individual jails. It's much more efficient than using something like VMware, which has horrific performance penalties. Hi Bill, We've been using VMware with FreeBSD guests for a few years now without any performance problems. In fact, jails even work well within a FreeBSD VM. What kinds of problems have you run into? Responding to the original question, we solved it by creating a FreeBSD VM and storing it as a template in VMware VirtualCenter. Whenever a new VM is needed, the template is deployed and customized with memory, extra disk space, IP address, etc. You can take it further by implementing a tool like Puppet, cfengine or Chef to perform the post-deployment configuration and keep the various recipe files under source control: http://reductivelabs.com/products/puppet/ (in the ports tree) http://www.cfengine.org/ (in the ports tree) http://wiki.opscode.com/display/chef/Home (not in the ports tree) Cheers, Greg -- Greg Larkin http://www.FreeBSD.org/ http://twitter.com/sourcehosting ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Developing and maintaining a rapidly deployable image of an installed system
In response to Greg Larkin glar...@freebsd.org: Bill Moran wrote: [...] The host system is a very basic install -- mostly just give it an IP and add users for the administrators. All the ports and details of their configs are in the individual jails. It's much more efficient than using something like VMware, which has horrific performance penalties. Hi Bill, We've been using VMware with FreeBSD guests for a few years now without any performance problems. In fact, jails even work well within a FreeBSD VM. What kinds of problems have you run into? Really? Do you have any machines with more than 30 virtual systems on them? Even our beefiest hardware can't handle more than 10 VMWare machines. We use both jails and VMWare. Each has it's pros and cons. The big pro of VMWare is that you can simulate an entire piece of hardware, which is necessary for much of our lab and testing work. The big con of VMWare is performance and overhead. Another big pro of VMWare is that we can have FreeBSD, and Linux, and MS operating systems all running on the same hypervisor, which jails can't do. The big pro of jails is that we can put a crapload of jails on each physical server. Six or 8 is typical, but we have systems with more than 30 humming along happily. Each jail uses far less disk space than a virtual machine, and uses far less CPU. Also, the jail mechanism puts fewer layers between the OS and the hardware, which means things like network and disk performance suffer very little. Take two equivalent machines and put a FreeBSD jail on one and FreeBSD in a virtual machine on the other and benchmark the network and disk performance on each. You'll find that VMWare loses big time. If that's not enough to convince you, then increase the number of systems on each machine to about 10 and rerun the tests while the systems are under load -- VMWare doesn't scale up nearly as well as jails do. If you're doing purely CPU usage, then the two options appear to be roughly equivalent, although I've never done an actual test. Restarting a jail takes seconds, restarting a VM takes minutes. We've frequently had to go through our dev servers and shut down VMWare virtual machines to free up resources when a few of the VMs were seeing heavy usage. We've had the same problem with jails far less frequently. Like I said earlier, VMWare has its advantages, but performance is not one of them. And yes, we have VMWare VMs with FreeBSD jails inside them. It's a bizarre combination, but it works quite well ... right up until someone wants to load up one of the PostgreSQL servers and the disk issue brings the system to its knees ... that's actually a pretty good benchmark to illustrate the problem: pgbench will show how much VMWare hurts disk performance right out of the gate. I guess the overall issues are more with scalability than performance, but the two issues are linked in such a way that I frequently don't separate them. VMWare starts with a minor performance hit compared to jails, that performance hit increases significantly as you add VMs, whereas jails scale up very well. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Developing and maintaining a rapidly deployable image of an installed system
Hi everyone, I'm just wondering if there is an established best practice for developing and maintaining a rapidly deployable image of an installed FreeBSD system? If anyone can point me towards documentation or any other resources that might be of use I would greatly appreciate it. Thanks, Warren signature.asc Description: OpenPGP digital signature
Re: Developing and maintaining a rapidly deployable image of an installed system
On Thu, 07 May 2009 12:10:42 +0800, Warren Guy warren@calorieking.com wrote: I'm just wondering if there is an established best practice for developing and maintaining a rapidly deployable image of an installed FreeBSD system? One of the common (at least I think so) methods is using the system's standard tools dump and restore. You create the installation as you need it on a separate machine or in a jailed environment, and you end up with partitions as you want them to have on the machines for deployment. Then you dump these partitions into files. On the (fresh) machines, you boot into a minimal FreeBSD system that allows you to read the dump files, from optical media, tape, or across the network. First you slice, partition and newfs the partitions (can easily be scripted if you know what you want), then you restore the partitions (as on the machine used for preparing them) from the dump files. That's for deploying. For maintaining... it's possible to use a similar method where you only need to dump and restore partitions where you did major changes. For minor ones it should be sufficient to alter files the usual way (can be scripted, too). If anyone can point me towards documentation or any other resources that might be of use I would greatly appreciate it. There has been a discussion thread some days ago on this list which covers a bit of this topic (deploying). -- Polytropon From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
