集群的最主要瓶頸是：磁盤。當我們面臨集群作戰(zhàn)的時候，我們所希望的是即讀即得。可是面對大數(shù)據(jù)，讀取數(shù)據(jù)需要經過磁盤io，這里可以把io理解為水的管道。管道越大越強，我們對于t級的數(shù)據(jù)讀取就越快。所以io的好壞，直接影響了集群對于數(shù)據(jù)的處理。
集群的瓶頸提出多種看法，其中網絡和磁盤io的爭議比較大。這里需要說明的是網絡是一種稀缺資源，而不是瓶頸。
對于磁盤io：（磁盤io：磁盤輸出輸出）
當我們面臨集群作戰(zhàn)的時候，我們所希望的是即讀即得。可是面對大數(shù)據(jù)，讀取數(shù)據(jù)需要經過io，這里可以把io理解為水的管道。管道越大越強，我們對于t級的數(shù)據(jù)讀取就越快。所以io的好壞，直接影響了集群對于數(shù)據(jù)的處理。
這里舉幾個例子，讓大家來參考一下。
案例一
自從使用阿里云以來，我們遇到了三次故障（一、二、三），這三次故障都與磁盤io高有關。
第一次故障發(fā)生在跑zzk.cnblogs.com索引服務的云
服務器上，當時的avg.disk read queue
length高達200多；
第二次故障發(fā)生在跑images.cnblogs.com靜態(tài)文件的云服務器上，當時的avg.disk read
queue length在2左右（后來分析，對于圖片站點這樣的直接讀文件進行響應的應用，disk read queue
length達到這個值會明顯影響響應速度）；
第三次故障發(fā)生在跑數(shù)據(jù)庫服務的云服務器上，當時的avg. disk write queue
length達到4~5，造成很多的數(shù)據(jù)庫寫入操作超時。
（這里既提到“硬盤”，又提到“磁盤”，我們這樣界定的：在云服務器中看到的硬盤叫磁盤[虛擬出來的硬盤]，在集群中的物理硬盤叫硬盤）
這三次的磁盤io高都不是我們云服務器內的應用引起的，最直接的證據(jù)就是將云服務遷移至另一個集群之后，問題立即解決。也就是說云服務器的磁盤io高是因
為它所在的集群的硬盤io高。
集群的硬盤io是集群內所有云服務器的磁盤io的累加，集群的硬盤io高是因為集群中某些云服務器的磁盤io過高。而我們自
己的云服務器內的應用產生的磁盤io在正常范圍，問題出在其他用戶的云服務器產生過多的磁盤io，造成整個集群硬盤io高，從而影響了我們。
為什么其他云服務器引起的硬盤io問題會影響到我們？問題的根源就在于集群的硬盤io被集群中的所有云服務器所共享，而且這種共享沒有被有效的限制、沒有
被有效的隔離，大家都在爭搶這個資源，同時爭搶的人太多，就會排長多。
而且對于每個云服務器來說，也不知道有多少臺云服務器在爭搶，從云服務器使用者的角
度根本無法躲開這個爭搶；就像在世博會期間，你起再早去排隊，也得排超長的隊。
如果每個云服務器使用的硬盤io資源是被限制或隔離的，其他云服務器產生再
多的磁盤io也不會影響到我們的云服務器；就像在一個小區(qū)，你一個人租了一套房子，其他的一套房子即使住了100人，也不會影響到你。
你可以買到cpu、內存、帶寬、硬盤空間，你卻買不到一心一意為你服務的硬盤io，這就是當前阿里云虛擬化平臺設計時未考慮到的一個重要問題。
經過與阿里云技術人員的溝通，得知他們已經意識到這個問題，希望這個問題能早日得到解決。
—————————————————————————————————————————————
案例2
云計算之路-遷入阿里云后：20130314云服務器故障經過
首先向大家致歉，這次云服務器故障發(fā)現(xiàn)于17:30左右，18:30左右恢復正常，給大家?guī)砹寺闊埓蠹艺徑猓?br>故障的原因是云服務器所在的集群負載過高，磁盤寫入性能急劇下降，造成很多數(shù)據(jù)庫寫入操作超時。后來恢復正常的解決方法是將云服務器遷移至另一個集群。
下面是故障發(fā)生的主要經過：
今天上午9:15左右一位園友通過郵件反饋在訪問園子時遇到502 bad gateway錯誤.
這是由阿里云負載均衡器返回的錯誤，tegine是由阿里巴巴開發(fā)的開源web服務器。我們猜測阿里云提供的負載均衡服務可能是通過tegine反向代理實現(xiàn)的。
這個錯誤頁面表示負載均衡器檢測到負載均衡中的云服務器返回了無效的響應，比如500系列錯誤。
我們將這個情況通過工單反饋給了阿里云，得到的處理反饋是繼續(xù)觀察，可能是這位用戶的網絡線路的臨時問題導致。
由于我們在這個時間段沒遇到這個問題，也沒有其他用戶反饋這個問題，我們也認可了繼續(xù)觀察的處理方式。
（根據(jù)我們后來的分析，出現(xiàn)502 bad gateway錯誤可能是集群出現(xiàn)了瞬時負載高的情況）
下午17:20左右，我們自己也遇到了502 bad gateway錯誤，持續(xù)了大約1-2分鐘。見下圖：
出問題期間，我們趕緊登錄到兩臺云服務器查看情況，發(fā)現(xiàn)iis并發(fā)連接數(shù)增長至原來的30多倍，而bytes
send/sec為0，而且兩臺云服務器都是同樣的情況。我們當時推斷，這兩臺云服務器本身應該沒有問題，問題可能出在它們與數(shù)據(jù)庫服務器之間的網絡通
信。我們繼續(xù)將這個情況通過工單反饋給阿里云。
剛把工單填好，我們就接到園友的電話反饋說博客后臺不能發(fā)布文章，我們一測試，果然不能發(fā)布，報數(shù)據(jù)庫超時錯誤，見下圖：
但打開現(xiàn)有的文章速度很快，也就是說讀正常，寫有問題。趕緊登錄數(shù)據(jù)庫服務器通過性能監(jiān)視器查看磁盤io情況，果然磁盤寫入性能有問題，見下圖：
avg. disk write queue length超過1就說明有問題了，現(xiàn)在平均已經到了4~5。進入阿里云網站上的管理控制臺一看，磁盤io問題就更明顯了，見下圖：
繼續(xù)向阿里云反饋情況，得到的反饋是這臺云服務器iops太高了，見下圖：
于是，阿里云工作人員將這臺云服務器遷移至另一個集群，問題立刻解決。
—————————————————————————————————————————————-
案例三
14:17左右，我們看到了這條閃存。立即進入博客后臺測試，發(fā)現(xiàn)提交時會出現(xiàn)如下的錯誤：
"timeout expired. the timeout period elapsed prior to completion of the operation or the server is not responding."
這是數(shù)據(jù)庫寫入超時的錯誤，對這個錯誤信息我們記憶猶新。之前遇到過兩次（3月14日、4月2日），都是數(shù)據(jù)庫服務器所在的云服務器磁盤io問題引起的。
登上云服務器，查看windows性能監(jiān)視器，發(fā)現(xiàn)日志文件所在的磁盤的io監(jiān)測數(shù)據(jù)avg.disk write queue
length平均值在5以上。性能監(jiān)視器中這個值的縱坐標最高值是1，可想而知5是多么高的一個值。性能監(jiān)視器中的走勢圖幾乎是一條直線。見下圖（最高值
竟然達到了20，真恐怖）：
（為什么數(shù)據(jù)庫寫入超時會表現(xiàn)于日志文件所在的磁盤io高？因為數(shù)據(jù)庫恢復模式用的是full，對數(shù)據(jù)庫的數(shù)據(jù)寫入，會先在日志中進行寫入操作。）
這次問題與3月14日磁盤io問題的表現(xiàn)是一樣的，所以我們斷定這次也是同樣的原因，是云服務器所在集群的磁盤io負載高引起的。
14:19，我們向阿里云提交了工單，特地在標題中加了“緊急”；
14:23，阿里云客服回復說正在核實我們提交的問題；
14:31，阿里云客服回復說已反饋給相關部門檢查；
14:42，沒有阿里云客服的進一步消息，我們就回復說“如果短時間內解決不了，希望盡快進行集群遷移”（3月14日就是通過集群遷移解決這個問題的，阿里云的技術人員也說過對于集群負載高引起的磁盤io問題，目前唯一的解決辦法就是集群遷移）；
14:47，阿里云客服只回復說正在處理；
14:59，還是沒消息，我們心急如焚（40分鐘過去了，連個說法都沒有），在工單中說：“能不能先做集群遷移？”；
然后，接到阿里云客服的電話，說集群中其他云服務器占用的磁盤io高影響了我們，他們正在處理。。。
過了會，阿里云客服又打電話

為什么說云原生是企業(yè)數(shù)字化轉型的通關密碼？
阿里云服務器硬盤容量多大
租賃云端服務器的價格組成
給初級seo的建議 如何端正自己對seo的態(tài)度
傳統(tǒng)服務器和云計算的區(qū)別
北京云服務器怎么購買虛擬主機
數(shù)據(jù)庫內容空白-虛擬主機/數(shù)據(jù)庫問題
阿里云服務器配置教程超級vps管理器