Yes, there actually a few solutions which i'm employing. first, you
could use https with your chef server and expose the chef-server
cross-region with elastic ip or DNS endpoints. this solution is very
easy but can slow down chef-runs, especially the first where files
are not cached yet. This can be quite annoying if you are using
autoscaling. second, you can use two separate chef servers and manage them using different knife.rb instances. this add some overhead but can be beneficial if you want to separate your systems. lastly, chef servers can operate in a various cluster modes: master-master, master-slave and various mix n' match modes; e.g. you could have master/slave where the slave is read only (classic) or (my favorite for wan replication) master/master for couchdb, master/slave for solr, master slave for files (/var/lib/chef/cookbook_index) and federation/shovel for rabbitmq. there are other combination that will work well over wan, but i find this combo to be the easiest to setup and maintain. I'm currently using this setup with the master in eu-west-1 and a slave in us-east-1 and this chopped 3 minutes off the chef run. it also allows high availability if you combine this with some failover logic (global dns traffic manager or client side logic). Regards, Avishai On 08/08/12 10:18, Morgan Blackthorne
wrote:
" type="cite">Just wondering how others approach this situation. Elastic IPs aren't viable as we'll have nodes in autoscaling groups, etc. |
Archive powered by MHonArc 2.6.16.