亚洲中文字幕av每日更新_亚洲av成人综合网伊人_国产精品综合久久_国产成人毛片精品

優(yōu)惠活動(dòng) - 12周年慶本月新客福利
優(yōu)惠活動(dòng) - 12周年慶本月新客福利
優(yōu)惠活動(dòng) - 12周年慶本月新客福利

網(wǎng)站什么地方適合云計(jì)算(以及為什么!)

存儲(chǔ)

開始時(shí),Picnik使用了一個(gè)開源項(xiàng)目,Mogilefs,用于文件存儲(chǔ)。我們的大部分服務(wù)器都有幾個(gè)空閑的驅(qū)動(dòng)器插槽,我們?cè)谶@些插槽上接入大容量的SATA驅(qū)動(dòng)器,用于 Mogilefs文件存儲(chǔ)。大部分后臺(tái)服務(wù)都是CPU密集型的,所以與這些I/O密集型的存儲(chǔ)配合得相當(dāng)好。這個(gè)策略工作得很好,但存儲(chǔ)需求超過CPU需求之后,就不行了,這時(shí)候,Amazon的S3服務(wù)看起來好像是我們擴(kuò)展存儲(chǔ)的最容易也最便宜的方法。

在測試S3之前,我們實(shí)際上并沒有對(duì)費(fèi)用用做多少評(píng)估,一方面是當(dāng)時(shí)并沒有太多的云計(jì)算可供選擇,另外就是一些令人尊敬的工程師也極力推薦S3,最后,我們從來就沒指望會(huì)大量使用。

因?yàn)殚_發(fā)者的機(jī)器沒有使用Mogile,所以已經(jīng)有一個(gè)框架用于接口不同的文件存儲(chǔ)系統(tǒng),這樣一來,增加S3的支持就相對(duì)容易些。事實(shí)上,僅用了大約一天就實(shí)現(xiàn)了S3支持,又測試了一兩天,然后就將其打包到我們的每周例行發(fā)布中了。這種實(shí)現(xiàn)的簡易性也是我們選擇S3的另一個(gè)關(guān)鍵因素。


 
最初,我們計(jì)劃只將最早的文件遷移到S3,這些文件是從2007年12月份開始的,因?yàn)檫@些文件訪問頻率比較低,不用怎么擔(dān)心性能和可用性方面的問題。這個(gè)模式非常棒,S3看起來性能也很好。

唯一的不足,我們從Mogilefs中遷移文件的速度不夠快,沒有跟上文件增長的速度。而且 Mogilefs也開始出現(xiàn)一些性能問題了。我們的解決方案跟其他幾家大型網(wǎng)站一樣:將文件直接存儲(chǔ)到S3。開始時(shí),只將一小部分新文件直接存儲(chǔ)到S3,然后逐漸增加,一直到絕大部分新文件都流向Amazon。這樣,事情又搞定了,我們就轉(zhuǎn)去解決其他問題了。 

雖然S3已經(jīng)相當(dāng)可靠了,仍然出現(xiàn)了一些值得注意的問題。我們遇到的第一個(gè)問題是最終一致性(eventual consistency)問題,基本上,這意味著不能保證立即讀取剛寫入的文件,在寫入到西雅圖的S3集群后,再試圖從EC2中讀,這個(gè)問問題會(huì)更嚴(yán)重。通過將所有的文件訪問都從我們?cè)谖餮艌D的數(shù)據(jù)中心代理而使這個(gè)問題有所緩和,但這樣一來,我們的帶寬就增加了。

我們遇到的第二個(gè)問題是Amazon?返回HTTP500錯(cuò)誤,我們的代碼能夠?qū)Σ怀晒Φ恼?qǐng)求進(jìn)行重試,這在大多數(shù)情況下工作良好。每一兩周,我們都會(huì)遇到錯(cuò)誤突然爆發(fā),以至于重試邏輯都不起作用了。這種爆發(fā)會(huì)持續(xù)一小時(shí)左右。一天,我正在查看發(fā)生錯(cuò)誤的關(guān)鍵字(keys),注意到這些關(guān)鍵字都有相同的前綴!結(jié)果證明,S3是基于關(guān)鍵字的范圍對(duì)數(shù)據(jù)進(jìn)行分區(qū)的,這意味著維護(hù)(如增減某個(gè)分區(qū)容量)會(huì)導(dǎo)致某個(gè)范圍內(nèi)的關(guān)鍵字大量出錯(cuò)。Amazon這樣做是為了保持S3的高性能。對(duì)我們而言,這種突發(fā)性錯(cuò)誤更大程度上是種煩惱,因?yàn)槲覀冞€有Mogilefs在起作用,如果寫到S3失敗,將其寫到Mogile:就是了。隨著增長率趨于穩(wěn)定,這個(gè)問題現(xiàn)在已經(jīng)很少出現(xiàn)了,但Mogile仍然在發(fā)揮作用。

其實(shí)我們遇到的這些問題是構(gòu)建大規(guī)模系統(tǒng)必然會(huì)發(fā)生的,所以 Amazon也用不著掩飾什么。人們很容易忘記,這其實(shí)是一個(gè)有著很多用戶的規(guī)模巨大的分布式系統(tǒng)。

隨著流量的增長,我們?cè)絹碓揭蕾囉赟3。要是S3宕掉了,一天的大部分時(shí)間里,我們的Mogl都無法處理龐大的請(qǐng)求。幸運(yùn)的是,S3大部分問題都不是發(fā)生在我我們網(wǎng)站的高峰時(shí)間,所以 Mogilev還能夠應(yīng)付。我也應(yīng)該提到的是,Mogile在兩種情況下會(huì)宕機(jī)幾個(gè)小時(shí),種情況是修改 MYSQL的表結(jié)構(gòu),還有就是調(diào)試Mogilev的Perl代碼。這種時(shí)候,1009%的流量都會(huì)壓到S3上,而我們的用戶則從來不知道發(fā)生了什么。

“無限”存儲(chǔ)的一個(gè)危險(xiǎn)是很容易造成浪費(fèi)。對(duì)我們來說,我并沒怎么注意刪除無用文件的后臺(tái)作業(yè)業(yè),對(duì)于創(chuàng)建的文件,最終會(huì)刪除掉近75%,而無用文件增長起來是很快的。

即使我們?cè)?jīng)注意到了這個(gè)問題,我們事實(shí)上還是決定忽略它。Picnik的每一個(gè)人都很忙,而且這看起來也不是什么大不了的問題,再說了,還有更棒的新功能或其他的伸縮性問題需要我們?nèi)リP(guān)注。有趣的是,S3讓我們選擇或者雇用和訓(xùn)練更多的人,或者更簡單,寫張支票就行了。在我們的信用卡月度額度快用光的時(shí)候,一切都變了。

經(jīng)過幾個(gè)月的調(diào)整、分析和重寫代碼,我們最后拿出了一份清理無用文件的可伸縮方案。首先是數(shù)據(jù)庫對(duì)無用文件記錄進(jìn)行清理,然后在數(shù)據(jù)庫的文件記錄和S3上的關(guān)鍵字列表之間做一個(gè)大型的連接操作(a large merge-join),以執(zhí)行實(shí)際的刪除。

在實(shí)現(xiàn)更好的清理系統(tǒng)的過程中間,我們開始意識(shí)到,S3對(duì)我們的工作負(fù)荷(workload)來說,實(shí)際上是非常昂貴的。先前的成本分析完全沒有考慮PUT操作的成本。很多S3的負(fù)荷中,存儲(chǔ)成本占了大頭,因?yàn)槲募陷d以后,在隨后的一個(gè)很長時(shí)段內(nèi),只是偶爾訪問下。正如前面所提到的,我們的負(fù)荷是創(chuàng)建大量文件,然后在隨后的幾天里就刪掉了這意味著PUT操作的成本上升了。

意識(shí)到這點(diǎn)以后,我們開始努力優(yōu)化Mogilefsl的性能,并且研究高性能的NAS產(chǎn)品。最后,我們實(shí)現(xiàn)了一個(gè)基于Linux的NFS概念系統(tǒng)作為前端存儲(chǔ),這意味著只需要在S3上存儲(chǔ)超過1周的大約25%的文件,這些留下來的文件也有了一個(gè)對(duì)S3來說更加友好的存取模式。

有很長一段時(shí)間,我們都不清楚S3是不是仍然合適。盡管更為傳統(tǒng)的NAS硬件看起來貴了點(diǎn),但如果你對(duì)長期存儲(chǔ)需求有信心的話,可以在一年或兩年內(nèi)分期付款。而另一方面,許多創(chuàng)業(yè)公司的CFO(包括我們自己的)都會(huì)告訴你,為了保持靈活性和一定程度的自由,多花點(diǎn)兒錢也值得一一這種靈活與自由就是S3提供的。當(dāng)然,這種靈活性比將此花費(fèi)算做運(yùn)維費(fèi)用還是資本費(fèi)用更為重要。至于我們所關(guān)心的,就只是運(yùn)維費(fèi)用了,因?yàn)檫@直接與流量和功能有關(guān)。 

混合計(jì)算

Picnik主要的服務(wù)端組件之一是我們的渲染場(render farm)。用戶在Picnik上保存圖片時(shí),經(jīng)常需要在服務(wù)端重建這個(gè)圖片。這時(shí),客戶端會(huì)向服務(wù)器發(fā)送一大段XML文本描述用戶的編輯操作。Web服務(wù)器收到后,會(huì)將所需要的圖片連同XML文本一起打包,并將其加入到渲染作業(yè)隊(duì)列中。渲染服務(wù)器獲取該作業(yè),重建圖片,然后將結(jié)果圖片返回給Web服務(wù)器。此時(shí),客戶端處于阻塞狀態(tài),等待服務(wù)器的響應(yīng)。大多數(shù)時(shí)間,客戶只需要等待幾秒鐘。

雖然這是可伸縮系統(tǒng)的典型架構(gòu),我們?cè)谠O(shè)計(jì)時(shí)仍然考慮到了未來對(duì)云計(jì)算的需求。這時(shí)的渲染服務(wù)器不需要訪問任何內(nèi)部服務(wù),如數(shù)據(jù)庫或存儲(chǔ)服務(wù)器。簡言之,它們非常適合于運(yùn)行在EC2上,另外,我們已有了一個(gè)自己開發(fā)的配置管理和代碼部署系統(tǒng),稱為Server manager。

像S3一樣,實(shí)際實(shí)現(xiàn)起來既簡單又快速。內(nèi)部的渲染場已經(jīng)考慮到了運(yùn)行在Xen之上的WM了,所以我需要做的就是一些簡單修改,使渲染服務(wù)器的VM映像適合于EC2的Xen找,然后將其打包為AMI。在映像啟啟動(dòng)時(shí),首先連接Server manager?獲取需要安裝和運(yùn)行的組件列表,其中之一是Renderserver,Renderserver用于連接渲染隊(duì)列以獲取渲染作業(yè)。我要做的第一件事就是激活兩個(gè)實(shí)例運(yùn)行一下看看怎么樣一一棒極了!

第二階段就是去實(shí)現(xiàn)云操作的終極目標(biāo)(loly Grail)了:自動(dòng)伸縮(auto-scaling)。我們的自動(dòng)伸縮實(shí)現(xiàn)起來還是很容易的,因?yàn)樗刑幚矶际峭ㄟ^隊(duì)列實(shí)現(xiàn)的。由于用戶在等待渲染結(jié)果,所以自動(dòng)伸縮代碼的目標(biāo)是維護(hù)一個(gè)空隊(duì)列5。每分鐘都會(huì)喚醒Server manager的一個(gè)線程,輪詢隊(duì)列的統(tǒng)計(jì)信息(上一分鐘已做過平衡),然后進(jìn)行計(jì)算,看為了維持閑者和忙者的比例需要做些什么。當(dāng)然,由于流量和網(wǎng)絡(luò)延遲會(huì)有小幅波動(dòng),為避免不必要的振蕩而對(duì)閑忙比例的修正會(huì)出現(xiàn)遲滯現(xiàn)象,如EC2實(shí)例有的時(shí)候需要幾分鐘才能啟動(dòng),我們的代碼也考慮到了這些問題。所有這些經(jīng)驗(yàn)性的調(diào)整經(jīng)歷了一兩周的時(shí)間,系統(tǒng)運(yùn)行起來以后,就非常簡單啦。

自動(dòng)伸縮并不僅僅是典型的容量需求問題,我們也遇到了諸如到EC2的網(wǎng)絡(luò)延遲加大了,或發(fā)布了一個(gè)代碼修正而使得渲染速度變慢了。遇到這些情況時(shí),我們先停止自動(dòng)伸縮,直到找出背后真正的原因并加以改正為止。我們還修正了一個(gè)錯(cuò)誤,這個(gè)錯(cuò)誤使一小部分用戶的保存操作失敗,這一修正使渲染負(fù)載増加了20%正好在圣誕節(jié)之前。
 
這種設(shè)置也很適合批處理作業(yè)。一段時(shí)間以前,我們要重建一批縮略圖,我就寫了一些代碼,將作業(yè)提交給渲染隊(duì)列,然后用新的縮略圖文件更新數(shù)據(jù)庫記錄。我不需要做任何特別的事情來分配空間或?qū)⒆鳂I(yè)設(shè)置在晚上負(fù)載較輕的時(shí)候處理,Server manager只是增加新的實(shí)例以適應(yīng)新的負(fù)載需求。

從財(cái)務(wù)方面來說,使用EC2比使用S3更清楚。我們?cè)噲D擴(kuò)建內(nèi)部渲染以滿足平均的容量需求,同時(shí),將做渲染的CPU轉(zhuǎn)換到做Web服務(wù)的CPU也容易。這意味著將云作為渲染服務(wù)器給Web服務(wù)器帶來了一些動(dòng)態(tài)特性,這讓我們易于適應(yīng)負(fù)載模式的變化,而且,通過逐漸購買硬件的方式,這也讓我們更有效地使用現(xiàn)有的硬件。例如,可以在數(shù)據(jù)中心訂購個(gè)新的機(jī)柜,然后把服務(wù)器上架,而不用擔(dān)心浪費(fèi)大部分的機(jī)柜電力。

一般與EC2有關(guān)的問題主要集中在連接性上。雖然互聯(lián)網(wǎng)作為一個(gè)整體是可靠的,但任何兩點(diǎn)之間的連接卻并非如此。通常,如果問題出現(xiàn)在網(wǎng)絡(luò)和數(shù)據(jù)中心之間,只有一小部分用戶受影響,但是,假如網(wǎng)絡(luò)恰好是云計(jì)算提供者,則所有用戶都會(huì)受影響。這種類型的宕機(jī)可能非常嚴(yán)重,因?yàn)閱栴}可能出在這樣的區(qū)域,就是不論是你還是云計(jì)算提供者都沒有為之付費(fèi),即雙不管的區(qū)域。

在發(fā)生嚴(yán)重問題時(shí)(而且是在繁忙時(shí)段),唯一的選擇就是甩掉負(fù)載。過去,我們只有種辦法控制讓多少用戶進(jìn)來,現(xiàn)在我們按優(yōu)先級(jí)將用戶分類(游客、免費(fèi)用戶、合作伙伴、金牌用戶)??汕榈氖?,大多數(shù)情況下,你不得不等待宕機(jī)恢復(fù)。不論哪種情況,我們做的第一件事情就是更新 Twitter信息(fecd),這些消息也顯示在我們的It's raining onour Picnik”頁面上。我們并不指責(zé)任何人一個(gè)用戶才不關(guān)心這些呢。

我們并不像對(duì)內(nèi)部服務(wù)器那樣監(jiān)控EC2實(shí)例。Nagiosi通過 Servermanager自動(dòng)獲取EC2實(shí)例的信息,Nagiost也監(jiān)控隊(duì)列深度,因?yàn)檫@是很多問題的預(yù)警器(early indicator)。

Caci以圖示方式顯示運(yùn)行實(shí)例數(shù)(通過EC2API)及集群層層面上的性能數(shù)據(jù)。我們不需要在 Cacti上增加單個(gè)實(shí)例的信息,因?yàn)樗⒉粚?shí)際處理集群,何況實(shí)例還是動(dòng)態(tài)變化的。

事實(shí)上,我們并不關(guān)心單個(gè)實(shí)例的性能,已經(jīng)知道這些實(shí)例比本地機(jī)器上的要慢一點(diǎn)。沒關(guān)系的,因?yàn)樽詣?dòng)伸縮系統(tǒng)總能在現(xiàn)有資源的條件下找到平衡。

由于實(shí)例是從隊(duì)列中獲取作業(yè)的,EC2實(shí)例稍微慢一點(diǎn),只是少干點(diǎn)活兒而已,不會(huì)躺倒不干。這使我能夠集中精力關(guān)注高層的性能數(shù)據(jù),如一天中使用EC2實(shí)例的比例是多少。在一天結(jié)束時(shí),只需要針對(duì)web服務(wù)器做容量規(guī)劃,從而決定硬件購買決策,而渲染服務(wù)器只是從未使用的容量中獲益。 

要想有效使用網(wǎng)站建設(shè)云計(jì)算資源,需要對(duì)應(yīng)用架構(gòu)和配置管理/自動(dòng)化有一個(gè)合理的“增長”態(tài)度。我們將渲染服務(wù)器設(shè)計(jì)為可分解的,以及我們手邊已經(jīng)具備配置管理系統(tǒng)等,這些事實(shí)使得自動(dòng)伸縮實(shí)現(xiàn)起來既容易又可靠。

本文地址:http://www.islandpacificappraisals.com//article/3306.html
相關(guān)文章:
最新文章: