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