Johnston, Christopher (GAE) wrote: It depends on how you are provisioning the machines and where you're seeing load challenges, if any. I really haven't heard of any load concerns so far that are cobbler specific as we are essentially relying on Apache and TFTP server to do the file transfers -- cobblerd is there to generate kickstart files, do some logging, and execute triggers. I would be /very/ interested in load testing to see how to best configure things in environments that do multiple reinstalls at the same time if they are being stressed. Ultimately, most of that stress would go on Apache, and it's easy enough to teach the kickstart generators how to distribute load between different web servers (if needed) and to tell the TFTP config to pick different cobbler servers (if needed). I'll get to that in a bit... The closest example I have at present is a Cobbler powered cluster that was doing 300 machine reinstalls at once, and seemed to be doing ok. At the time (about a year ago), cobblerd was being a bit slow, but we've since replaced all of the CGI code with mod_python, and for large installs, we also have seralizer_catalog in 1.1 (a storage backend) that is much zippier than serializer_yaml (and it is backwards compatible) So, about how to distribute things between multiple cobbler servers if you want to do that ... For clean installs of bare metal, basically TFTP is going to serve up systems when they are requested. If optimizations are needed, we do have the "--server-override" flag which can point certain hardware at different cobbler servers, and "cobbler replicate" which can be used to construct a mirror of a cobbler server. Server-override could be used so that installs of the "webserver" profile hit "cobbler2.example.org" and another profile hits "cobbler.example.org", and "cobbler replicate" could be used to mirror the data between the two on a crontab. Another piece of advice might be to use "cobbler import" with "--available-as" as opposed to mirroring into /var, such that you can leave your data on a SAN/NFS share, to be shared by the multiple cobbler servers (or otherwise bind mount /var/www/cobbler on the same SAN/NFS share). This solves the need to replicate data between multiple cobbler servers -- you can just use replicate to replicate the metadata. Another thing you can do is if you are using something like koan, you could reinstall the machines in staggered batches. This really isn't possible with just PXE, though in a PXE setup, you could control it by making the profile/system assignments in cobbler and then cycling power on a staggered basis. I would love to collect user cases on the Wiki of ways people are building cobbler out for really aggressive reinstall type situations. That would be great to have. I'd love to hear more details as this is an interesting problem space. I think we've covered by any of the above, but if not, I'm sure we can work out something more specific to your environment. Let me know if that works! --Michael