跳到主要內容

AWS Autos Scaling Group termination policy

今天遇到了一個有趣的問題，是有個 build job 說他的 build node 會被隨機 terminate 掉。

大致去看了一下 Auto Scaling Group 的設定，當 idle node > 1 的時候， ASG 就會開始 scale in ，當有 build queue 不為空的時候，就 step scaling out
研究一下他的做法是在 jenkins cronjob 每分鐘去 query jenkins api 回報 build queue 和目前狀態是 idle or offline 的 build node number 去 CloudWatch metrics

然後 CloudWatch metrics 再去觸發 ASG 的 scale in or out

這時候我想到的問題是，那當 scale in 被觸發時，是哪台 instance 要被 terminate?
當初的設計很聰明，他利用了 lifecycle hook，用意是說當 build node 被選上要被 terminate 時，會進入 Terminate Wait 的狀態，直到 ASG 收到 complete-lifecycle-action 的指令時，才會真的 terminate 掉。

但這個 lifecycle hook 是有預設 timeout 時間 3600 sec !!  也就是說一但 instance 進入 Terminate Wait 即使你沒有用 cron job 去 complete-lifecycle-action 過了一小時 waiting 時間它還是會被關掉....

原本我以為 ASG 應該會挑 CPU 閒置的機器下手吧？後來再去翻一下文件發現， default termination policy 的策略依序是盡量讓機器分散在不同 AZ >  Allocation Policy > Oldest Launch Template or Config 最後是開機時間最接近整數小時的機器。

其他可以選的 termination policy 也都不是根據 instance usage 來判定。

原本因為不想花太多時間，只是暫時先把 timeout 時間設長，讓他有機會即使不幸被選上，還是可以把 build 跑完。

但再翻一下文件，或許可以把 busy build node 透過 cron job 送 record-lifecycle-action-heartbeat 或者是怕 timeout 太長，就等 build 跑完，再補送 complete-lifecycle-action 就好了...


Ref:

https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html

https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html

標籤：

留言

張貼留言

這個網誌中的熱門文章

3M UVA3000 更換濾芯紫外線燈匣

用了一年的3M濾水器提示說要換濾芯和燈匣 上 Youtube 想找教學的影片可是沒看到 UVA 3000 的 經過了一番奮戰後在這邊記錄一下 希望可以幫助後人，以免再重蹈覆轍。 Step 1. 拔掉插頭，把淨水器從牆上拿下來（基本上他是掛著而已），比較方便施工。 Step 2. 把前蓋往上拉，很容易就可以看到裡面的東西了。 Step 3. 打開後可以看到有兩個柱狀體，左邊的是燈匣，右邊的是濾芯。 Step 4. 這裡有個祕技是，這兩個柱狀體是可以往上 翻開30 度左右，這樣就可以有比較大的空間施工。 Step 4. 更換濾芯的話，柱狀體的瓶身上有箭頭，往左就是轉開，往右就是鎖緊。 Step 5. 更換燈匣的話比較麻煩一點，因為他底部是電源，頂部的右邊有個突出來的小方塊。對照淨水器上方連接處的話會有個弧形的凹槽，這是要 match 的．如果你只注意瓶身的箭頭往右鎖回去，就會造成漏水...Orz... Step 6. 把前蓋蓋回，機器掛回牆上，插插頭，開水，如果機器沒有告訴你有燈匣異常或漏水的話，就可以長按 C / UV  Reset 計數器了． 所以關鍵字就是，要往上翻 30 度，燈匣上面的小凸點要在右側，要看瓶身的 小箭頭． May it helps!
張貼留言
閱讀完整內容

AWS CloudWatch Synthetics

原本想用 DataDog 的 Sythetics API Test 做 e2e monitoring & alarm 但是遇到 multi-part form-data 沒辦法在 Request Body 使用 \r\n 的問題 curl -i -X  --trace-ascii - -F 'key=key1' -F 'key2=key2' https://whatever.totest.com/auth 你可以看到送出的 Content-Length 和 Request Body 是 Content-Length: YYY Content-Type: multipart/form-data; boundary=xxxx --xxxx Content-Disposition: form-data; name="key1" key1 --xxxx Content-Disposition: form-data; name="key2" key2 --xxxx-- 但是使用 DataDog 送出去的話只會用 \n 和 curl 送出的一比較，就發現 Content-Length 比較小，但是 DataDog 似乎沒辦法改.. 試了一下 AWS CloudWatch Synthetics Canary 發現他其實就是 deploy 一個 nodejs lambda layer 裡面執行 Puppeteer, Chromium 和 AWS SDK 但是又整合了 cloudwatch dashoboard, cloudwatch logs 和 cloudwatch alarm，所以不只可以跑 script 還可以透過 chromium 去抓網頁的 screenshot 彈性超大！ 另外一個好處是可以編輯要送出去的 postData，一開始我看他預設也是送 \n 會造成 invalid request 但是只要改成 \r\n 就好囉!
張貼留言
閱讀完整內容

/ect/crontab not running

如果把 cronjob  寫在 /etc/crontab 下，那要注意格式 # Example of job definition: # .---------------- minute (0 - 59) # |  .------------- hour (0 - 23) # |  |  .---------- day of month (1 - 31) # |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ... # |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat # |  |  |  |  | # *  *  *  *  * user-name command to be executed 在 "command to be executed" 前面, 要有 user-name... 如果用 crontab -e 的方式, 則不需要 user-name 那個欄位.... # *  *  *  *  *  command to be executed
張貼留言
閱讀完整內容