Puppet Master 用 Load-balabcing Scaling 達成 HA

2017-10-19 AWS, Puppet

隨著 Puppet Server 越來越龐大 Scaling 也是很重要的環節之一,在 Puppet 官方文件也有提到「Scaling Puppet Server with compile masters」的一些作法,還有在 Puppet Enterprise 文件中的「High availability overview

 

先談談官方 Puppet Enterprise 的 HA

  • Active / Standby 的架構,透過 Replica sync data。
    • 最少需 2 台 instances。

這種架構上你可以允許 1 台 Puppet Master 故障,但你可用的 Puppet cluster 並不會增加,你必須採用更高的規格才能支撐更大量的 Puppet Node。

 

  • 把 Compile Master 分離出來,讓 Puppet Agent 接的 Compile Master 可以 Scaling。
    • 最少需 4 台 instances。

Puppet Master 的角色還是維持 Active / Standby,讓 Compile Master 去搞定繁忙的工作。

 

在 Puppet Enterprise 的 HA 好處是可以 replica data 到另一台,你的 config 可以在 Manage console 上進行編輯,不用擔心容錯時遺失設定。

 

再來談談 Open Source Puppet 的作法:

  • Using round-robin DNS

# IP address of master 1:
puppet.example.com. IN A 192.0.2.50
# IP address of master 2:
puppet.example.com. IN A 198.51.100.215

這個方法其實很直接又簡單 … 直接替 Compile Master 加上多個 DNS A record,然後你就擁有自動負載均衡的架構,不過如果其中一台 Compile Master 掛了還是有機會跑到掛掉的那台,但 DNS 可以做 health check 這又是後話了 …

 

  • Using a hardware load balancer

更直覺的方式就是用可以 TCP 的 Load balancer 設備來做。

 

  • Using DNS SRV Records

# Site A has two masters – master-1 is beefier, give it 75% of the load:
_x-puppet._tcp.site-a.example.com. IN SRV 0 75 8140 master-1.site-a.example.com.
_x-puppet._tcp.site-a.example.com. IN SRV 0 25 8140 master-2.site-a.example.com.
_x-puppet._tcp.site-a.example.com. IN SRV 1 5 8140 master.site-b.example.com.

# For site B, prefer the local master unless it’s down, then fail back to site A
_x-puppet._tcp.site-b.example.com. IN SRV 0 5 8140 master.site-b.example.com.
_x-puppet._tcp.site-b.example.com. IN SRV 1 75 8140 master-1.site-a.example.com.
_x-puppet._tcp.site-b.example.com. IN SRV 1 25 8140 master-2.site-a.example.com.

還有 DNS SRV record 的方式來告訴 Agent 有哪些 endpoint,比 round-robin DNS 好的是可以做到 fail over,並且指定權重。

 

manifests 和 modules 的同步

但是上述方法都會用 manifests 和 modules 不同步的問題,所以 Puppet 官方建議用版控的工具或是 r10k 來同步所有 config,這就有關 CI / CD 了,把 CI / CD 做好環境 manifests and modules 一致性就沒問題。

 

除此之外,Puppet 最重要的就是 CA 憑證,如果你的 CA 憑證丟了,全部 Puppet agent 都要清掉 certificate 重來一次 …,所以上述的作法所有的 Puppet Master 都要存放相同的 ca 憑證,不然不會動 …,certufucate trust 的部份就用 auth sign policy 自動重新簽發就好了。

 

把 CA Server 拆出來做備援

另外也支援 ca_server 這個參數讓你指定 CA Server,所以在 CA 這塊你又可以另外拆出來做備援。Creating and configuring compile masters

 

上述講這麼多 Puppet 官方提供的 HA Solution 後,在下面會講我的 HA 實作案例。

 

AWS 上實作 Puppet Master 的 Auto Scaling

*** 以下實作必須具備 AWS 操作 EC2、AutoScaling、S3、IAM 的能力。

 

先說這個作法相同在 Docker、OpenStack 等平台其實也都能輕鬆達成,只是因為身在 AWS 環境,只要善用 Autoscaling 這個 API,就可以很簡單的做到 Puppet Master 的 Scaling。

 

Step 1. 先打好一個基本的 Puppet Master template AMI 這個 AMI 要做好幾件事情:

  • 安裝好 Puppet Master
  • puppet.conf 完成 certname、server 等 Domain 資訊
  • 針對效能調整的 JVM Heap size、max-active-instances 等

詳細可以參考 安裝初始化

 

Step 2. 處理最重要的 CA 憑證

把既有的 CA 憑證打包丟到 S3,這是最重要的動作,你也可以放在任何可以儲存的地方。

 

Step 3. 提供 S3 bucket 權限給要 Puppet Server instance 的 Role

因為準備在 Autoscaling launch instance 的時候從 S3 把 CA 取回來。

 

Step 4. manifests and modules 就透過 CI / CD 自動 deployment 到 instances

 

Step 5. 建立 Launch configuration,選擇已經建立好的 Puppet Server AMI,在這邊必須特別在 User-data 把 CA 憑證抓回來

 

Step 6. 建立 Autoscaling,記得 Join NLB or ELB。

 

Step 7. 測試

這時 Autoscaling 會自動 Launch instances,必須檢查以下項目:

  • Puppet Server 有自動 Join 到 NLB or ELB。
  • CI / CD 有將 manifests 和 modules deploy 到 instance
  • 寫在 user-data 的動作有把 CA 從 S3 抓到 /etc/puppetlabs/puppet/ssl
  • Puppet agent 重新和 Puppet Master 要 catalog 皆正常。

 

上面實作方式說明的有點籠統,但在 AWS 上就是點點點就好了,之後再補上完整的 Terraform config !

 

這種方式將 CA、compile、Master 都集成到 Puppet Server 上,就不用特別把某一部分拆開,用 Autoscaling 來達成萬台的架構。

 

 

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *

彙整

分類

open all | close all

License

訂閱 Mr. 沙先生 的文章

輸入你的 email 用於訂閱