On 04/25/2013 11:33 AM, Morgan Blackthorne wrote:
"Chef works atop ssh, which -- while the gold standard for
cryptographically secure systems management -- is computationally
expensive to the point where most master servers fall over under the
weight of 700-1500 clients."
This is factually incorrect on two counts. The crypto negotiation for
knife ssh is not done on the Chef server but instead on the knife
client. However, regular Chef client->server communication is done
over HTTP(S), depending on how you've configured your settings.
It's also completely incorrect about the cause of the speed problems,
which was mostly down to a combination of Ruby & CouchDB on the server
side, /not/ SSH. Opscode have been quite open about where the pain
points were.
With Chef 11 the whole server stack has been re-written in Erlang,
(whilst maintaining complete API compatibility), and it's utilising an
embedded postgres. Both those aspects mean a single chef server can
cope with literally tens of thousands of servers doing chef runs
simultaneously (Facebook have been demonstrating that).
There's a good blog post on the rebuild here:
http://www.opscode.com/blog/2013/02/15/the-making-of-erchef-the-chef-11-server/
and an example of Chef 11 in large scale use:
http://blog.cyclecomputing.com/2013/02/built-to-scale-10600-instance-cyclecloud-cluster-39-core-years-of-science-4362.html
Paul
_______________________________________________
Discuss mailing list
Discuss@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
