跳到主要內容

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

標籤：

留言

張貼留言

這個網誌中的熱門文章

flash tomato firmware on ASUS RT-N12-C1

Tomato by Shibby For RT-N12-C1 we have to download from: K26RT-N – MIPSR2 – special builds for E4200, RT-N10U, RT-N12B1/C1, RT-N15U, RT-N53, RT-N66U, WNR3500Lv2 and newer Linksys E-series routers Step: 1. Reset AP to factory default 2. Setup staic IP for you desktop or laptop 3. Unplug power 4. Press the reset button in the back of AP the plug power 5. Wait until the pwoer led falsh slowly 6. Open browser and connect http://192.168.1.1 7. You should see a firmware upload page, select the tomato firmware and upload it 8. After upload success wait 5 minutes 9. Connect http://192.168.1.1, if you see the tomato webpage, you have done the job!
張貼留言
閱讀完整內容

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!
張貼留言
閱讀完整內容

Application Load Balancer lambda endpoint healthy check will be charged

AWS 還是有蠻多坑的... 如果 ALB 的 TargetGroup 使用 lambda endpoint 那麼為了避免 code start issue 可能會使用 provisioned concurrency 另外 lambda endpoint 在 update stack 的時候會出現 Load Balancer not able to stabilizied 的問題。AWS support 目前給的work around就是開啟 ALB healthy check 預設是每 35 秒會做一次 healthy check 然後如果 ALB 跨3個 AZ 的話，healthy check count 就 x3 .... 然後每次的 lambda execution 都是照 lambda function usage 來收費 另外ALB的 healthy check 不會有完整的 request header 如果你的 framework 不預期有這種不正常的 header 沒有去 handle 的話 可能會一直狂噴500... 如果你還沒有把預設的 lambda error retry 關掉的話...... 這樣子用 lambda endpoint 真的比較省嗎?....
張貼留言
閱讀完整內容