在云計算中，啟用新的實例只需要給提供者發(fā)一條簡單的API調(diào)用即可，但要想知道什么時候應(yīng)該啟動更多的實例或撤銷正在運行的實例，就會很麻煩。如果基于采集的資源使用情況來判斷啟用撤銷的話，就會容易得多，這是測量數(shù)據(jù)用做反饋機(jī)制的一種通例。
我在 Flickr，有一個大型項目，使用了這種反饋機(jī)制，事實證明，非常有用。
2007年，Yahoo!決定關(guān)掉 Yahoo!! Photos計劃很簡單:通知 Yahoo! Photos的用戶，這個服務(wù)將被關(guān)閉，用戶可以自己選擇，將自己的照片連同元數(shù)據(jù)一起轉(zhuǎn)移到其他的服務(wù)，包括非Yahoo!!的服務(wù)，像Shutterfly和 Kodak Gallery， Flickr也是選項之一。
為這個項目做出容量評估將是一件苦差事。盡管有一些測量數(shù)器據(jù)，用上載頻度、片大小及其他因素指述了Yahoo! Photos的典型用戶，但有多少用戶會選擇Flickr，即使選擇了Flickr，用戶的使用模式又會如何變化，我們心里仍然沒底。我們談?wù)摰氖且豁椧呀?jīng)超過10年的照片存儲服務(wù)，將會有巨量的數(shù)括，而且這么大的空同會在很短的時間內(nèi)消耗掉。不用講得太精確，我告訴你，2009年后期，F(xiàn)ick每天用掉大約12TB的存儲客量。從Yahoo! Photos到Flickr的遷移，在2007年持續(xù)了一段不長的時間，每天消耗的存空間是這個數(shù)的兩倍還多。
在在備遷移的過程中，基于對遷移的評估以及現(xiàn)有的 Yahoo! Photos數(shù)器，我們對存需求做了最好的估計，并給出了一個寬松的安全系統(tǒng)，確保遷移結(jié)束之前，不會出現(xiàn)存空間不夠的情況。我們能想到的每件事情，都有測量數(shù)據(jù):
● 遷移的賬戶
● 遷移的照片
● 處理的照片
● 遷移隊列大小
● 磁盤空間消耗量
對選擇遷移到Flickr的用戶，開始遷移過程，并進(jìn)行觀察
我直接聯(lián)到有意思的部分來說吧:即使微了如此謹(jǐn)慎的估計，我們還是錯了，錯大了。雖然做了研究，對存豬容量做了精心的評估，想遷近移到Fick來的人還是超出了我們的預(yù)期。要把想遷移到Flickr來的人的Yhoo! Photos數(shù)據(jù)都近移過來的話，我們部看的存豬空間都會用完。要么增加存豬，要么Flickr停止上載片。
調(diào)天地，由于測量數(shù)據(jù)能夠追蹤磁を請耗，我們很快意識到了這點，但卻受限于采購時間表。重要的是盡快購買、安裝、配置、部署更多存造，以免用完現(xiàn)有存。部著更多空間與遷移進(jìn)程之間展開了一場競賽，
為了解釋我們是如何通過測量數(shù)據(jù)反轉(zhuǎn)危為安的，要先介紹一下遷移過程是如何進(jìn)行的:
1.告知用戶，將關(guān)閉 Yahoo! Photos服務(wù)，用戶可以從列表中選擇遷移到哪里。假如選擇Flickr的話，該用戶賬號就進(jìn)人遷移隊列。
2.一旦用戶的遷移任務(wù)進(jìn)入隊列，則則鎖定該用戶的 Yahoo! Photos賬號，防止用戶進(jìn)行修改。現(xiàn)在 Yahoo! Photos和 Flickr之間進(jìn)行API對API的通信，以獲取要遷移的照片數(shù)據(jù)。
3.Flickr獲取并處理 Yahoo! Photos賬號的照片及其元數(shù)據(jù)。
4.將Yahoo!Photos賬號寫人 Flickr存儲和數(shù)據(jù)庫。
遷移完成后，開放 Flickr這邊的賬號，通知用戶可以使用遷移過來的 Flickr新賬號了。單個用戶的遷移并不需要很長時間，但用戶量很大，所以還是花了不少時間。遷移過程基本上就是一個大規(guī)模的異步過程，每個異步過程包括創(chuàng)建Flickr新賬號和批量上載照片。
由于知道遷移要消耗多少存儲、“有機(jī)”(非遷移)增長要消耗多少存儲，即使估計不足的話，也可以預(yù)測出還能夠支持的天數(shù)。我們下了一個龐大的訂單，來購買存儲，并開始計時。確認(rèn)了發(fā)貨和安裝日期，這樣我們就知道這些存儲什么時候能夠在數(shù)據(jù)中心上架以及需要多久才能投入使用。
因為使用 Ganglia采集數(shù)據(jù)，3行腳本代碼就可以計算出存儲的消耗率，然后將這個數(shù)字傳給負(fù)責(zé)遷移的API進(jìn)程。照片是存儲在分布于美國各地的若干個數(shù)據(jù)中心的，要確保API進(jìn)程能夠遠(yuǎn)程獲得這個值，并檢查正在遷移數(shù)據(jù)的所有數(shù)據(jù)中心。我們修改了API的處理過程，以便觀察存儲消耗的速率。如果在過去的一小時存儲的消耗率大于維持到新存儲上線那天的消耗率，則降低對排隊等待遷移的賬號的處理速度，反之，則加快處理速度。前面列出的步驟中，我們在步驟2和步驟3之間插入了一個檢查當(dāng)前存儲消耗率的步驟。
因為我們會根據(jù)存儲的消耗率調(diào)整遷移的速度，進(jìn)入隊列的賬號可能會等待更長的時間。減慢處理過程也是一個不得已的折中，既要保證遷移的順利進(jìn)行，又要不影響 Flickr的當(dāng)前業(yè)務(wù)。
最終，遷移順利完成，沒有發(fā)生存儲空間用光的情況。事后看來，我們的估計是有偏差的，但并沒有當(dāng)初想的那么大。遷移開始時的高峰使我們擔(dān)心存儲會用光，所以馬上部署了更多的存儲。但隨著漸漸接近原來的存儲極限，進(jìn)入遷移隊列的用戶也慢慢減少了
這個故事說明，將分布在全國多個地點的網(wǎng)站建設(shè)測量數(shù)據(jù)采集系統(tǒng)納入反饋循環(huán)，能夠?qū)B級照片數(shù)據(jù)從 Yahoo! Photos安全地遷移到 Flickr，同日時基本不影響兩者的正常使用。
本文地址：http://knowyourextract.com//article/3313.html
