AWS Auto Scaling組是一個優(yōu)秀的功能，該自動化系統(tǒng)負(fù)責(zé)管理服務(wù)器宕機(jī)并為用戶自動擴(kuò)展服務(wù)。一個Auto Scaling組連接到彈性負(fù)載均衡，則會讓確保應(yīng)用總是啟動并處于運(yùn)行中這件事變得容易。

管理員可以指定一個亞馬遜Web服務(wù)(AWS)Auto Scaling組使用彈性負(fù)載均衡(ELB)健康檢查，這將確保該服務(wù)在服務(wù)器上是運(yùn)行的–而不只是服務(wù)器本身是運(yùn)行的。這可以快速和自動更換任何行為不正常的服務(wù)器，殺掉那些壞的服務(wù)器并用好的干凈的服務(wù)器取代它們。

使用ELB健康檢查，而不僅僅是彈性計(jì)算云(EC2)健康檢查是很重要的。我碰到過這樣的問題，服務(wù)器仍在運(yùn)行，但服務(wù)器上的服務(wù)已經(jīng)死掉并且無法重新啟動。該ELB會從服務(wù)器斷開，因?yàn)樗巡辉俜?wù)請求，但AWS Auto Scaling組并沒有替換它，因?yàn)榉?wù)器仍在運(yùn)行。最終，所有服務(wù)器都有了同樣的問題，該服務(wù)停止工作。然后，我收到了一個來自Pingdom的警告，通知我說Web服務(wù)不工作。AWS Auto Scaling組一直認(rèn)為所有的服務(wù)器都正常，沒有檢測出實(shí)際的Web服務(wù)已經(jīng)死亡并且無法重啟。

***對每一個生產(chǎn)服務(wù)使用Scaling組，即使他們并不需要真正的自動擴(kuò)展。我的大部分AWS Auto Scaling組只是簡單的描述為，“保持X數(shù)量的服務(wù)器一直運(yùn)行。”這意味著，如果出現(xiàn)一個問題然后其中一臺服務(wù)器宕掉，該服務(wù)器會被殺掉并自動替換。這并不意味著我需要根據(jù)負(fù)載自動增加服務(wù)器的數(shù)量。但那使得自動化一些簡單的DevOps任務(wù)如重新啟動一臺服務(wù)器變得更容易。

什么地方出錯了?

關(guān)于AWS EC2定價的一個需要小小討論的事實(shí)是，用戶按照每臺服務(wù)器運(yùn)行任意部分小時來支付費(fèi)用。這意味著，如果一個用戶啟動服務(wù)器，然后在五分鐘內(nèi)殺死它，他仍然要為這完整的一小時買單。這似乎是可接受的，但是如果一個用戶殺掉一個服務(wù)器然后使用完全相同類型和位置的一個新的服務(wù)器來替換它，這個舉動會讓費(fèi)用翻倍。

起初，我啟動了一個服務(wù)器，被收取一臺服務(wù)器的費(fèi)用，五分鐘后殺掉該服務(wù)器，然后換成另一臺。但我被收取了2倍服務(wù)器運(yùn)行的費(fèi)用，直到***臺服務(wù)器被啟動(圖1)之后達(dá)到一小時。當(dāng)你將那種計(jì)費(fèi)模式和AWS Auto Scaling組不斷殺死和重新啟動服務(wù)器的錯誤結(jié)合起來，成本就會不斷上漲。

Auto Scaling在五分鐘后殺死一個實(shí)例并啟動另一個。

在我的這個案例中，Auto Scaling組的配置有一個問題，一個服務(wù)器連續(xù)被殺死并在有問題的同一區(qū)域內(nèi)被重新啟動。這意味著，每五分鐘，一個新的服務(wù)器啟動，舊的被取代，從而產(chǎn)生每小時12個實(shí)例小時的費(fèi)用 - 即便在任何時間永遠(yuǎn)都只有一個實(shí)例在運(yùn)行。并且該實(shí)例甚至都沒有正常工作。

我一開始沒有注意到，直到收到之后的帳單列表，因?yàn)檫@個原因出現(xiàn)了一筆額外的1200美金的支出。這時，我聯(lián)系了AWS的支持人員。當(dāng)我發(fā)現(xiàn)這個問題的時候我非常沮喪，但亞馬遜修復(fù)了它并給了我由于壞掉的Auto Scaling組導(dǎo)致的額外的信用度。 AWS還針對該問題進(jìn)行了檢測，并給了我Auto Scaling組失控的2個月的信用度。

現(xiàn)在回想起來，我本應(yīng)該設(shè)置Auto Scaling組的通知，我本應(yīng)該驗(yàn)證Auto Scaling的行為不可能每15分鐘超過一次。有了這些改變，最多只可能出現(xiàn)四倍的正常收費(fèi)。這仍然是糟糕的，但卻沒有12倍那么糟糕。我本應(yīng)該驗(yàn)證所有地區(qū)的服務(wù)器都正常啟動了。

如何防止Auto Scaling故障

首先，訂閱Auto Scaling組通知 - 即使它只是使用一個電子郵件地址，因?yàn)槭褂脤ず艨赡苡悬c(diǎn)極端。管理員還應(yīng)該小心該組突然“暴走”。如果確實(shí)發(fā)生了一些什么狀況并且AWS Auto Scaling組不停的啟動和替代服務(wù)器，管理員則可以禁用一個可用區(qū)域或阻止該組執(zhí)行任何操作。把“冷靜”時間增加到15分鐘也許是個不錯的主意，以防止類似的錯誤發(fā)生到完全失控。

***，確保ELB在服務(wù)器啟動之后給予了足夠?qū)捲５臅r間來決定是否最終會正常啟動。如果該服務(wù)通常需要5分鐘才能啟動成功，那么給它15分鐘。如果開發(fā)人員檢查到他至少有2臺服務(wù)器跑在ELB后面，在新的服務(wù)器正在啟動時，運(yùn)行的服務(wù)器必須能夠處理負(fù)載。

提供額外的能力總是一個不錯的主意，因?yàn)橛脩艨赡苄枰谛迯?fù)問題的時候停掉一些服務(wù)器。請記住，AWS Elastic Beanstalk內(nèi)部使用的是Auto Scaling組，因此也可以訂閱對他們的通知，如果他們被設(shè)置好的話。

原文鏈接：http://www.searchcloudcomputing.com.cn/showcontent_91495.htm