在原本 Puppet agent 上都是透過 runinterval 來決定多久去跟 Puppet Master 去要更新,但長久下來就會發現如果你所有的 Puppet agent 都設定相同的 runinterval,那你的 Master 就會在同一時間被所有的 node DDos …
之前同事有提到 Github 用密碼學的方式讓每台 node sleep 不同秒數來達到平均分散流量的方式,實際看完 Puppet 的文件後其實內建有 splay 和 splaylimit 這兩個參數可以搭配著用來達到相同的效果
如果 splay 設為 true,則在每次執行 catalog 的時候會隨機 sleep 一段時間再執行,而 splay 的最大秒數取決於 splaylimit 設定的值
舉例:
- splay = true
- splaylimit = 60s
這樣在執行 catalog 後會隨機 sleep 1 ~ 60 秒之間,如果沒有設定 splaylimit 的話則參考 runinterval 的值。
更好的辦法是使用 cron + fqdn_rand 來做:
$ramdom_time =fqdn_rand(60) cron { 'puppet-agent-reboot': ensure => 'present', command => '/opt/puppetlabs/bin/puppet agent -t -l /var/log/puppetlabs/puppet/puppet.log', special => 'reboot', target => 'root', user => 'root', } cron { 'puppet-agent': ensure => 'present', command => "sleep ${ramdom_time}; /opt/puppetlabs/bin/puppet agent -t -l /var/log/puppetlabs/puppet/puppet.log", minute => [fqdn_rand(10), fqdn_rand(10)+15, fqdn_rand(10)+30, fqdn_rand(10)+45], target => 'root', user => 'root', }
這樣會在 Node 上產生 cronjob,執行的時間(分) 會依照 fqdn 去 hash 後產生的值。
1,16,31,46 * * * * sleep 10; /opt/puppetlabs/bin/puppet agent -t -l /var/log/puppetlabs/puppet/puppet.log @reboot sleep 10; /opt/puppetlabs/bin/puppet agent -t -l /var/log/puppetlabs/puppet/puppet.log
Puppet master 就會平均分散的降低 Loading。
這個方法會有 random number 的問題,反而有可能在某一瞬間把 puppet 的 master server 打爆。
deployment sleep time 跑 random number 會有問題嗎 ?
目前是這樣跑的,從 Dashboard 看還蠻平均的,
上班來聊看看想法。
原本 */10 會有空窗期,導致所有 Loading 都聚集在那 300 sec,現在我加上 fqdn_rand 來讓執行的 min 也是隨機