ebs緩存
① openstack的問題。
OpenStack其實有三個與存儲相關的組件，這三個組件被人熟知的程度和組件本身出現時間的早晚是相符的，按熟悉程度排列如下：
Swift——提供對象存儲 （Object Storage），在概念上類似於Amazon S3服務，不過swift具有很強的擴展性、冗餘和持久性，也兼容S3 API
Glance——提供虛機鏡像（Image）存儲和管理，包括了很多與Amazon AMI catalog相似的功能。（Glance的後台數據從最初的實踐來看是存放在Swift的）。
Cinder——提供塊存儲（Block Storage），類似於Amazon的EBS塊存儲服務，目前僅給虛機掛載使用。
（Amazon一直是OpenStack設計之初的假象對手和挑戰對象，所以基本上關鍵的功能模塊都有對應項目。除了上面提到的三個組件，對於AWS中的重要的EC2服務，OpenStack中是Nova來對應，並且保持和EC2 API的兼容性，有不同的方法可以實現）
三個組件中，Glance主要是虛機鏡像的管理，所以相對簡單；Swift作為對象存儲已經很成熟，連CloudStack也支持它。Cinder是比較新出現的塊存儲，設計理念不錯，並且和商業存儲有結合的機會，所以廠商比較積極。
Swift
關於Swift的架構和部署討論，除了官方網站，網上也有很多文章，這里就不重復.(也可以參考我之前在OpenStack中國行活動中上海站演講的PPT)。從開發上看，最近也沒有太大的結構性調整，所以我想主要說說比較適用的應用領域好了。
從我所了解的實際案例來看，Swift出現的領域有4個，(應該還有更多，希望大家看到實際用例能夠指教)
1.網盤。
Swift的對稱分布式架構和多proxy多節點的設計導致它從基因里就適合於多用戶大並發的應用模式，最典型的應用莫過於類似Dropbox的網盤應用，Dropbox去年底已經突破一億用戶數，對於這種規模的訪問，良好的架構設計是能夠支撐的根本原因。
Swift的對稱架構使得數據節點從邏輯上看處於同級別，每台節點上同時都具有數據和相關的元數據。並且元數據的核心數據結構使用的是哈希環，一致性哈希演算法對於節點的增減都只需重定位環空間中的一小部分數據,具有較好的容錯性和可擴展性。另外數據是無狀態的，每個數據在磁碟上都是完整的存儲。這幾點綜合起來保證了存儲的本身的良好的擴展性。
另外和應用的結合上，Swift是說HTTP協議這種語言的，這使得應用和存儲的交互變得簡單，不需要考慮底層基礎構架的細節，應用軟體不需要進行任何的修改就可以讓系統整體擴展到非常大的程度。
2.IaaS公有雲
Swift在設計中的線性擴展，高並發和多租戶支持等特性，使得它也非常適合做為IaaS的選擇，公有雲規模較大，更多的遇到大量虛機並發啟動這種情況，所以對於虛機鏡像的後台存儲具體來說，實際上的挑戰在於大數據（超過G）的並發讀性能，Swift在OpenStack中一開始就是作為鏡像庫的後台存儲，經過RACKSpace上千台機器的部署規模下的數年實踐，Swift已經被證明是一個成熟的選擇。
另外如果基於IaaS要提供上層的SaaS 服務，多租戶是一個不可避免的問題，Swift的架構設計本身就是支持多租戶的，這樣對接起來更方便。
3.備份歸檔
RackSpace的主營業務就是數據的備份歸檔，所以Swift在這個領域也是久經考驗，同時他們還延展出一種新業務--「熱歸檔」。由於長尾效應，數據可能被調用的時間窗越來越長，熱歸檔能夠保證應用歸檔數據能夠在分鍾級別重新獲取，和傳統磁帶機歸檔方案中的數小時而言，是一個很大的進步。
4. 移動互聯網和CDN
移動互聯網和手機游戲等產生大量的用戶數據，數據量不是很大但是用戶數很多，這也是Swift能夠處理的領域。
至於加上CDN，如果使用Swift，雲存儲就可以直接響應移動設備，不需要專門的伺服器去響應這個HTTP的請求，也不需要在數據傳輸中再經過移動設備上的文件系統，直接是用HTTP 協議上傳雲端。如果把經常被平台訪問的數據緩存起來，利用一定的優化機制，數據可以從不同的地點分發到你的用戶那裡，這樣就能提高訪問的速度，我最近看到Swift的開發社區有人在討論視頻網站應用和Swift的結合，竊以為是值得關注的方向。
Glance
Glance比較簡單，是一個虛機鏡像的存儲。向前端nova（或者是安裝了Glance-client的其他虛擬管理平台）提供鏡像服務，包括存儲，查詢和檢索。這個模塊本身不存儲大量的數據，需要掛載後台存儲（Swift，S3。。。）來存放實際的鏡像數據。
Glance主要包括下面幾個部分：
l API service： glance-api 主要是用來接受Nova的各種api調用請求，將請求放入RBMQ交由後台處理，。
l Glacne-registry 用來和MySQL資料庫進行交互，存儲或者獲取鏡像的元數據，注意，剛才在Swift中提到，Swift在自己的Storage Server中是不保存元數據的，這兒的元數據是指保存在MySQL資料庫中的關於鏡像的一些信息，這個元數據是屬於Glance的。
l Image store： 後台存儲介面，通過它獲取鏡像，後台掛載的默認存儲是Swift，但同時也支持Amazon S3等其他的鏡像。
Glance從某種角度上看起來有點像虛擬存儲，也提供API，可以實現比較完整的鏡像管理功能。所以理論上其他雲平台也可以使用它。
Glance比較簡單，又限於雲內部，所以沒啥可以多展開討論的，不如看看新出來的塊存儲組件Cinder，目前我對Cinder基本的看法是總體的設計不錯，細節和功能還有很多需要完善的地方，離一個成熟的產品還有點距離。
Cinder
OpenStack到F版本有比較大的改變，其中之一就是將之前在Nova中的部分持久性塊存儲功能（Nova-Volume）分離了出來，獨立為新的組件Cinder。它通過整合後端多種存儲，用API介面為外界提供塊存儲服務，主要核心是對卷的管理，允許對卷，卷的類型，卷的快照進行處理。
Cinder包含以下三個主要組成部分
API service：Cinder-api 是主要服務介面, 負責接受和處理外界的API請求，並將請求放入RabbitMQ隊列，交由後端執行。 Cinder目前提供Volume API V2
Scheler service: 處理任務隊列的任務，並根據預定策略選擇合適的Volume Service節點來執行任務。目前版本的cinder僅僅提供了一個Simple Scheler, 該調度器選擇卷數量最少的一個活躍節點來創建卷。
Volume service: 該服務運行在存儲節點上，管理存儲空間，塔處理cinder資料庫的維護狀態的讀寫請求，通過消息隊列和直接在塊存儲設備或軟體上與其他進程交互。每個存儲節點都有一個Volume Service，若干個這樣的存儲節點聯合起來可以構成一個存儲資源池。
Cinder通過添加不同廠商的指定drivers來為了支持不同類型和型號的存儲。目前能支持的商業存儲設備有EMC 和IBM的幾款，也能通過LVM支持本地存儲和NFS協議支持NAS存儲，所以Netapp的NAS應該也沒問題，好像華為也在努力中。我前段時間還在Cinder的blueprints看到IBM的GPFS分布式文件系統，在以後的版本應該會添加進來
到目前為止，Cinder主要和Openstack的Nova內部交互，為之提供虛機實例所需要的卷Attach上去，但是理論上也可以單獨向外界提供塊存儲。
部署上，可以把三個服務部署在一台伺服器，也可以獨立部署到不同物理節點
現在Cinder還是不夠成熟，有幾個明顯的問題還沒很好解決，一是支持的商業存儲還不夠多，而且還不支持FC SAN，另外單點故障隱患沒解決，內部的schele調度演算法也太簡單。另外由於它把各種存儲整合進來又加了一層，管理倒是有辦法了，但是效率肯定是有影響，性能肯定有損耗，但這也是沒辦法的事了。
Openstack通過兩年多發展，變得越來越龐大。目前光存儲就出現了三種：對象存儲、鏡像存儲和塊存儲。這也是為了滿足更多不同的需求，體現出開源項目靈活快速的特性。總的說來，當選擇一套存儲系統的時候，如果考慮到將來會被多個應用所共同使用，應該視為長期的決策。Openstack作為一個開放的系統，最主要是解決軟硬體供應商鎖定的問題，可以隨時選擇新的硬體供應商，將新的硬體和已有的硬體組成混合的集群，統一管理，當然也可以替換軟體技術服務的提供商，不用動應用。這是開源本身的優勢！
② EBS系統菜單、職責的問題
1. 如果是對用戶的，用系統管理員職責，安全性->用戶 然後對要取消的職責設置失效日期 2. 要失效職責，同樣用系統管理員職責，安全性->職責 在職責的有效性上取消掉即可
③ 關於盜鏈下載的問題
[Reference]
Ref1=http://222.122.181.29/ebscul1/2006/CH01/0001182/VOD/300k/MSWMExt=.asf
Ref2=http://222.122.181.29:80/ebscul1/2006/CH01/0001182/VOD/300k/MSWMExt=.asf
流媒體做了隱藏，找方法下載。好像沒有好的辦法，只有看完一遍，在緩存裡面拷貝出來！
④ 大家常用的塊存儲工具有哪些
大家常用的塊存儲工具有哪些？
有獎勵寫回答共3個回答
jinnow1
2021-12-03
超過90用戶採納過TA的回答
儲存器具有記憶功能，用來保存信息，如數據，指令和運算結果等等。 它可以分為外儲存器和內儲存器兩種。下面進行詳細說明。 1） 內儲存器（內存） 內儲存器直接與CPU相連接，儲存容量較小，但速度快，用來存放當前運行程序的指令和數據，並直接與CPU交換信息。內儲存器由許多儲存單元組成，每個單元能存放一個二進制數或一條由二進制編碼表示的指令。 2） 外儲存器（外存） 外儲存器是內儲存器的擴充。它儲存容量大，價格低，但儲存速度慢，一般用來存放大量暫時不用的程序，數據和中間結果，需要時，可成批的與內存進行信息交換。外存只能與內存交換信息，不能被計算機系統的其他部件直接訪問。常用的外存有磁碟，磁帶，光碟等。 內存一般採用半導體存儲單元，包括隨機存儲器（RAM），只讀存儲器（ROM），以及高速緩存（CACHE）。只不過因為RAM是其中最重要的存儲器。S（synchronous）DRAM 同步動態隨機存取存儲器：SDRAM為168腳，這是目前PENTIUM及以上機型使用的內存。SDRAM將CPU與RAM通過一個相同的時鍾鎖在一起，使CPU和RAM能夠共享一個時鍾周期，以相同的速度同步工作，每一個時鍾脈沖的上升沿便開始傳遞數據，速度比EDO內存提高50%。DDR（DOUBLE DATA RAGE）RAM ：SDRAM的更新換代產品，他允許在時鍾脈沖的上升沿和下降沿傳輸數據，這樣不需要提高時鍾的頻率就能加倍提高SDRAM的速度。 ●只讀存儲器（ROM） ROM表示只讀存儲器（Read Only Memory），在製造ROM的時候，信息（數據或程序）就被存入並永久保存。這些信息只能讀出，一般不能寫入，即使機器掉電，這些數據也不會丟失。ROM一般用於存放計算機的基本程序和數據，如BIOS ROM。其物理外形一般是雙列直插式（DIP）的集成塊。 ●隨機存儲器（RAM） 隨機存儲器（Random Access Memory）表示既可以從中讀取數據，也可以寫入數據。當機器電源關閉時，存於其中的數據就會丟失。我們通常購買或升級的內存條就是用作電腦的內存，內存條（SIMM）就是將RAM集成塊集中在一起的一小塊電路板，它插在計算機中的內存插槽上，以減少RAM集成塊佔用的空間。目前市場上常見的內存條有1G／條,2G/條,4G/條等。 ●高速緩沖存儲器（Cache） Cache也是我們經常遇到的概念，它位於CPU與內存之間，是一個讀寫速度比內存更快的存儲器。當CPU向內存中寫入或讀出數據時，這個數據也被存儲進高速緩沖存儲器中。當CPU再次需要這些數據時，CPU就從高速緩沖存儲器讀取數據，而不是訪問較慢的內存，當然，如需要的數據在Cache中沒有，CPU會再去讀取內存中的數據。
⑤ 什麼是分布式存儲系統
分布式存儲系統
定義
分布式存儲系統是大量普通PC伺服器通過Internet互聯，對外作為一個整體提供存儲服務
特性
可擴展
低成本
高性能
易用
挑戰
分布式存儲系統的挑戰主要在於數據、狀態信息的持久化，要求在自動遷移、自動容錯、並發讀寫的過程中保證數據的一致性。分布式存儲涉及的技術主要來自兩個領域：分布式系統以及資料庫。
分類
非結構化數據，一般的文檔
結構化數據， 存儲在關系資料庫中
半結構化數據，HTML文檔
不同的分布式存儲系統適合處理不同類型的數據：
分布式文件系統
非結構化數據，這類數據以對象的形式組織，不同對象之間沒有關聯，這樣的數據一般稱為Blob（二進制大對象）數據
典型的有Facebook Haystack 以及 Taobao File System
另外，分布式文件系統也常作為分布式表格系統以及分布式資料庫的底層存儲，如谷歌的GFS可以作為分布式表格系統Google Bigtable 的底層存儲，Amazon的EBS（彈性存儲塊）系統可以作為分布式資料庫（Amazon RDS）的底層存儲
總體上看，分布式文件系統存儲三種類型的數據：Blob對象、定長塊以及大文件
分布式鍵值系統
較簡單的半結構化數據，只提供主鍵的CRUD（創建、讀取、更新、刪除）
典型的有Amazon Dynamo 以及 Taobao Tair
分布式表格系統
較復雜的半結構化數據，不僅支持CRUD，而且支持掃描某個主鍵范圍
以表格為單位組織數據，每個表格包括很多行，通過主鍵標識一行，支持根據主鍵的CRUD功能以及范圍查找功能
典型的有Google Bigtable 以及 Megastore，Microsoft Azure Table Storage，Amazon DynamoDB等
分布式資料庫
存儲結構化數據，一般是由單機關系資料庫擴展而來
典型的包括MySQL資料庫分片集群、Amazon RDS以及Microsoft SQL Azure
⑥ oracle FORM報錯 FRM-92101
安裝EBS12後，可以成功登錄EBS，但是卻不能打開FORM界面，打開FORM界面時報錯：FRM-92101：然後我去到$LOG_TOP/ora/10.1.3/j2ee/forms/forms_default_group_1（我的鏈接的完全路徑是：/d01/oracle/test/inst/apps/test_test/logs/ora/10.1.3/j2ee/forms/forms_default_group_1）的application.log日誌中查看，發現具體的原因如下：
Forms 會話 <1> 中止: 運行時進程在啟動過程中失敗, 並出現錯誤 /d01/oracle/test/apps/tech_st/10.1.2/bin/frmweb: error while loading shared libraries: libXm.so.2: cannot open shared object file: No such file or directory
在網路上查找，發現是我的：openmotif21-2.1.30-11.EL5.i386.rpm沒有安裝。但是在安裝之前，我是安裝了RehHat5光碟里的openmotif-2.3.0-0.3.el5和openmotif22-2.2.3-18了的。看來還是版本兼容的問題，所以我到https://oss.oracle.com/projects/compat-oracle/files/Enterprise_Linux/里直接去下載了openmotif21-2.1.30-11.EL5.i386.rpm來安上，然後重啟EBS應用後，就可以成功打開EBS FORM界面了。
⑦ 中國銀行 安全控制項問題
您好，遇到這種情況，請您首先，清空IE緩存~1.如您使用IE8，請你依次在瀏覽器上點擊「安全」——刪除瀏覽的歷史記錄。2.然後在使用「360安全衛士」等輔助軟體，掃描系統中的插件。看用沒有中國銀行的網銀控制項。3.如果有，請點擊「立即清除」，然後請您登錄「www.boc.cn「下載最新的登錄控制項。同時，在下載完成以後，請您關閉所有瀏覽器，重啟電腦後再重新打開中國銀行網站使用。4.如果您使用IE6或者IE7，請您直接使用輔助軟體清除IE緩存。然後重復2.3步驟即可。如您還有其他的任何問題，請補充。
⑧ 如何在資料庫應用中發揮SSD的優勢
利用固態硬碟(SSD)技術的優勢設計資料庫應用架構是非常有吸引力的一件事。特別值得注意的是，固態硬碟並行訪問數據的能力已經有了很大的提升。這些提升使得固態硬碟對於許多類型的資料庫應用幾乎能達到了隨機訪問內存存儲的性能，而成本只是其八分之一。
在過去的幾年裡，固態硬碟的性能得到了突飛猛進的增長，同時相比於傳統硬碟和RAM，其成本卻在持續降低。但是要利用好這些改進的優勢，需要掌握存儲特性選擇合適的AWS實例大小，理解應用特性並利用合適的編程語言。
掌握AWS選項
AWS IaaS EC2實例可以配置不同級別的存儲：
A)內存。對應於傳統物理計算機的RAM。
B)實例存儲。也稱為臨時存儲。它對應於傳統物理計算機的磁碟大小。
C)靈活的持久化補充存儲(比如EBS和S3)。基本上可以把它視為物理PC的網路存儲。
Amazon現在把SSD作為部署臨時存儲和通用存儲的默認配置，也是EBS的默認配置(早期的實例類型默認不是SSD)。EBS的其它好處是存儲系統可以在資料庫伺服器本身退役以後仍然繼續可用。
此外，AWS還提供SSD存儲作為Amazon DynamoDB的默認選項。SSD同時也是Amazon RDS和Amazon
Redshift的可選配置。這個配置非常好，它可以降低資料庫應用需要的開發代價。但是，如果企業需要部署其它資料庫，也有很多其它可配置項可以幫助他
們利用到SSD的並行特性。
並行存儲的物理原理
物理計算機通常設置有三種主要存儲類型。RAM安裝在主板上，緊挨著CPU，它提供最高的性能，成本代價也最高，計算機關閉以後內容不會保存。
SSD和傳統硬碟是連接到計算機上的補充存儲，通過PCI-e，SCSI和SATA線纜連接，或者在網路上通過eSATA或者光纖通道連接。
傳統硬碟包含有一個物理讀寫頭，一次可以跨多個物理碟片讀取數據流。如果數據可以順序讀取(比如讀取較大的多媒體視頻音頻文件)，或者對於一些
資料庫分析應用(比如Hadoop應用)，這種模式都非常合適。然而，如果讀取數據要搜索碟片的多個扇區，那麼傳統硬碟讀寫頭的性能會急劇下降。
與此相反，快閃記憶體驅動的物理構成就是成百上千個可以隨機訪問的塊，是由分散的許多晶元組成的，讀取哪一塊的數據不會影響訪問性能。快閃記憶體檔有兩個瓶頸：第一就是計算機處理器和個體晶元儲存區之間的存儲控制器;第二是不能從單個晶元上的不同塊區同時讀取隨機數據。
當今時代的大部分資料庫引擎都沒有利用快閃記憶體檔訪問數據隨機位的功能優勢。其結果是，資料庫都比較慢，或者雖然其訪問模式可以被緩存，但需要更多
RAM才能實現同樣的性能效果。而RAM存儲肯定比快閃記憶體檔速度快，不過對於相同數量的存儲空間，RAM的成本是快閃記憶體檔的十倍。在物理層面上，RAM比
SSD有更好的IO處理能力，但是成本也是其大約三到四倍。這些相對成本也被反映到了Amazon Web服務上可用的不同計算機實例相對成本上。
寫入隊列
利用跨多個晶元並行訪問數據能力優勢的關鍵在於編寫程序時要考慮到隊列深度這一特性。在資料庫應用中增加隊列深度可以使應用從SSD不同個體晶元中並行讀寫數據，這對提高資料庫性能有直接的效果。
如果隊列深度設置過大，訪問同一晶元中不同數據位的可能性就增大了，這也會破壞性能。因此，大部分應用的最佳隊列深度是每驅動器32到64個並
發請求，盡管驅動器本身支持更多並發請求。通過優化資料庫應用訪問SSD的隊列深度，應用程序可以花更少的代價就能達到用更昂貴RAM才能實現的更佳性能
狀態。
在應用層面，開發者需要考慮如何實現應用對存儲系統的請求隊列化，以實現並行處理。但是，軟體方面要獲得較好的並行有許多陷阱。要用像
JavaScript、Ruby和Python這樣的編程語言實現並行是很困難的，因為這些語言對實現多線程支持的不太好，Java和C#相對更容易一
些。
C和C++是實現高並發系統代碼最合適的編程語言，因為它們直接操作操作系統核心功能。例如，互斥擴展(也叫互斥量)就是簡化編程生成低級系統並行調用的語言特性。另一種選擇是使用自帶SSD存儲優化方案的商業資料庫，比如Aerospike。
為應用選擇合適的架構
不是所有的資料庫應用都需要快閃記憶體存儲功能來並行訪問隨機數據。處理大量並發用戶Web請求的資料庫很容易看到快閃記憶體存儲的最大優勢。
與此相反，像Hadoop這種分析應用在某種意義上是並行的，但是通常這些應用最後都需要訪問存儲驅動器上的大量數據流來完成數據訪問。例如，
處理一個月的用戶日誌來分析其行為或者分析用戶，本質上都要按順序提取數據，因此遷移到SSD並不能帶來太多益處。在這兩種極端場景之間，還有一些實時分
析類型的應用，它們既需要一定的隨機搜索和也需要數據流處理。
專家建議，充分利用各種層次成本差異的一種方式是，配置資料庫利用臨時存儲讀取數據以獲得最佳性能。這一點可以通過存儲在EBS持久化數據層的數據進行備份。這種方案提供了AWS上價格和性能的最佳平衡組合。
後台進程也需要考慮
資料庫應用架構師還應該考慮其它細微特徵。要理解資料庫軟體如何利用RAM，如何把數據刷到磁碟，這些對於優化SSD應用配置非常重要。這對於
評估資料庫與文件系統交互的各種方式也非常重要。最明顯的讀負載繁重會有大量後台IO競爭。而其他進程像報表系統、日誌文件生成是需要後台維護的。
要想找到合適的平衡點，專家建議以真實世界部署的強大指標為基準進行參考。這樣可以幫助企業判斷部署和優化SSD系統有多大益處。不過，在RAM和SSD之間選擇，最重要的考慮因素是深刻掌握要處理的數據集大小。
配置合適的SSD和RAM容量有許多種組合，會增加資料庫更高的復雜度。更多的是傳統資料庫系統，它們會部署一台主伺服器和許多備用伺服器用於
故障恢復，除了在磁碟級別的情況它們的配置都很簡單。另一方面，分布式資料庫系統根據節點數量不同，RAM數量和網路設置的不同會有更多的變化。
盡管在大多數情況下，如果你關注技術的力量和資料庫系統的可操作性作為選擇硬體驅動器的考慮因素，那麼你需要比較評估的系統應該相對不會很多。
⑨ Oracle EBS系統中報這個錯，ORA-00054:resource busy and acquire with NOWAIT specified。求答案。。。
設置一個大一點的緩存吧
⑩ 如何測試雲硬碟
問題
UOS公有雲開放以來，一些用戶反應用dd命令測試出來的1TB雲硬碟的吞吐率(MBPS)只有128MB/s，而不是我們SLA保證的170MB /s ，這是為什麼？下面我會簡單介紹如何測試硬碟，RAID，SAN，SSD，雲硬碟等，然後再來回答上面的問題。
測試前提
我們在進行測試時，都會分清楚:
測試對象：要區分硬碟、SSD、RAID、SAN、雲硬碟等，因為它們有不同的特點
測試指標：IOPS和MBPS(吞吐率)，下面會具體闡述
測試工具：Linux下常用Fio、dd工具, Windows下常用IOMeter,
測試參數: IO大小，定址空間，隊列深度，讀寫模式，隨機/順序模式
測試方法：也就是測試步驟。
測試是為了對比，所以需要定性和定量。在宣布自己的測試結果時，需要說明這次測試的工具、參數、方法，以便於比較。
存儲系統模型
為了更好的測試，我們需要先了解存儲系統，塊存儲系統本質是一個排隊模型，我們可以拿銀行作為比喻。還記得你去銀行辦事時的流程嗎？
去前台取單號
等待排在你之前的人辦完業務
輪到你去某個櫃台
櫃台職員幫你辦完手續1
櫃台職員幫你辦完手續2
櫃台職員幫你辦完手續3
辦完業務，從櫃台離開
如何評估銀行的效率呢：
服務時間 = 手續1 + 手續2 + 手續3
響應時間 = 服務時間 + 等待時間
性能 = 單位時間內處理業務數量
那銀行如何提高效率呢:
增加櫃台數
降低服務時間
因此，排隊系統或存儲系統的優化方法是
增加並行度
降低服務時間
硬碟測試
硬碟原理
我們應該如何測試SATA/SAS硬碟呢？首先需要了解磁碟的構造，並了解磁碟的工作方式：
每個硬碟都有一個磁頭(相當於銀行的櫃台)，硬碟的工作方式是：
收到IO請求，得到地址和數據大小
移動磁頭(定址)
找到相應的磁軌(定址)
讀取數據
傳輸數據
則磁碟的隨機IO服務時間:
服務時間 = 尋道時間 + 旋轉時間 + 傳輸時間
對於10000轉速的SATA硬碟來說，一般尋道時間是7 ms，旋轉時間是3 ms, 64KB的傳輸時間是 0.8 ms， 則SATA硬碟每秒可以進行隨機IO操作是 1000/(7 + 3 + 0.8) = 93，所以我們估算SATA硬碟64KB隨機寫的IOPS是93。一般的硬碟廠商都會標明順序讀寫的MBPS。
我們在列出IOPS時，需要說明IO大小，定址空間，讀寫模式，順序/隨機，隊列深度。我們一般常用的IO大小是4KB，這是因為文件系統常用的塊大小是4KB。
使用dd測試硬碟
雖然硬碟的性能是可以估算出來的，但是怎麼才能讓應用獲得這些性能呢？對於測試工具來說，就是如何得到IOPS和MBPS峰值。我們先用dd測試一下SATA硬碟的MBPS(吞吐量)。
#dd if=/dev/zero of=/dev/sdd bs=4k count=300000 oflag=direct
記錄了300000+0 的讀入 記錄了300000+0 的寫出 1228800000位元組(1.2 GB)已復制，17.958 秒，68.4 MB/秒
#iostat -x sdd 5 10
...
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sdd 0.00 0.00 0.00 16794.80 0.00 134358.40 8.00 0.79 0.05 0.05 78.82
...
為什麼這塊硬碟的MBPS只有68MB/s? 這是因為磁碟利用率是78%，沒有到達95%以上，還有部分時間是空閑的。當dd在前一個IO響應之後，在准備發起下一個IO時，SATA硬碟是空閑的。那麼如何才能提高利用率，讓磁碟不空閑呢？只有一個辦法，那就是增加硬碟的隊列深度。相對於CPU來說，硬碟屬於慢速設備，所有操作系統會有給每個硬碟分配一個專門的隊列用於緩沖IO請求。
隊列深度
什麼是磁碟的隊列深度？
在某個時刻,有N個inflight的IO請求,包括在隊列中的IO請求、磁碟正在處理的IO請求。N就是隊列深度。
加大硬碟隊列深度就是讓硬碟不斷工作，減少硬碟的空閑時間。
加大隊列深度 -> 提高利用率 -> 獲得IOPS和MBPS峰值 -> 注意響應時間在可接受的范圍內
增加隊列深度的辦法有很多
使用非同步IO，同時發起多個IO請求，相當於隊列中有多個IO請求
多線程發起同步IO請求，相當於隊列中有多個IO請求
增大應用IO大小，到達底層之後，會變成多個IO請求，相當於隊列中有多個IO請求 隊列深度增加了。
隊列深度增加了，IO在隊列的等待時間也會增加，導致IO響應時間變大，這需要權衡。讓我們通過增加IO大小來增加dd的隊列深度，看有沒有效果：
dd if=/dev/zero of=/dev/sdd bs=2M count=1000 oflag=direct
記錄了1000+0 的讀入 記錄了1000+0 的寫出 2097152000位元組(2.1 GB)已復制，10.6663 秒，197 MB/秒
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sdd 0.00 0.00 0.00 380.60 0.00 389734.40 1024.00 2.39 6.28 2.56 97.42
可以看到2MB的IO到達底層之後，會變成多個512KB的IO，平均隊列長度為2.39，這個硬碟的利用率是97%，MBPS達到了197MB/s。(為什麼會變成512KB的IO，你可以去使用Google去查一下內核參數 max_sectors_kb的意義和使用方法 )
也就是說增加隊列深度，是可以測試出硬碟的峰值的。
使用fio測試硬碟
現在，我們來測試下SATA硬碟的4KB隨機寫的IOPS。因為我的環境是Linux，所以我使用FIO來測試。
$fio -ioengine=lio -bs=4k -direct=1 -thread -rw=randwrite -size=1000G -filename=/dev/vdb \
-name="EBS 4K randwrite test" -iodepth=64 -runtime=60
簡單介紹fio的參數
ioengine: 負載引擎，我們一般使用lio，發起非同步IO請求。
bs: IO大小
direct: 直寫，繞過操作系統Cache。因為我們測試的是硬碟，而不是操作系統的Cache，所以設置為1。
rw: 讀寫模式，有順序寫write、順序讀read、隨機寫randwrite、隨機讀randread等。
size: 定址空間，IO會落在 [0, size)這個區間的硬碟空間上。這是一個可以影響IOPS的參數。一般設置為硬碟的大小。
filename: 測試對象
iodepth: 隊列深度，只有使用lio時才有意義。這是一個可以影響IOPS的參數。
runtime: 測試時長
下面我們做兩次測試，分別 iodepth = 1和iodepth = 4的情況。下面是iodepth = 1的測試結果。
上圖中藍色方框裡面的是測出的IOPS 230, 綠色方框裡面是每個IO請求的平均響應時間，大約是4.3ms。黃色方框表示95%的IO請求的響應時間是小於等於 9.920 ms。橙色方框表示該硬碟的利用率已經達到了98.58%。
下面是 iodepth = 4 的測試:
我們發現這次測試的IOPS沒有提高，反而IO平均響應時間變大了，是17ms。
為什麼這里提高隊列深度沒有作用呢，原因當隊列深度為1時，硬碟的利用率已經達到了98%，說明硬碟已經沒有多少空閑時間可以壓榨了。而且響應時間為 4ms。 對於SATA硬碟，當增加隊列深度時，並不會增加IOPS，只會增加響應時間。這是因為硬碟只有一個磁頭，並行度是1， 所以當IO請求隊列變長時，每個IO請求的等待時間都會變長，導致響應時間也變長。
這是以前用IOMeter測試一塊SATA硬碟的4K隨機寫性能，可以看到IOPS不會隨著隊列深度的增加而增加，反而是平均響應時間在倍增。
隊列深度 IOPS 平均響應時間
1 332.931525 3.002217
2 333.985074 5.986528
4 332.594653 12.025060
8 336.568012 23.766359
16 329.785606 48.513477
32 332.054590 96.353934
64 331.041063 193.200815
128 331.309109 385.163111
256 327.442963 774.401781
定址空間對IOPS的影響
我們繼續測試SATA硬碟，前面我們提到定址空間參數也會對IOPS產生影響，下面我們就測試當size=1GB時的情況。
我們發現，當設置size=1GB時，IOPS會顯著提高到568，IO平均響應時間會降到7ms(隊列深度為4)。這是因為當定址空間為1GB時，磁頭需要移動的距離變小了，每次IO請求的服務時間就降低了，這就是空間局部性原理。假如我們測試的RAID卡或者是磁碟陣列(SAN)，它們可能會用Cache把這1GB的數據全部緩存，極大降低了IO請求的服務時間(內存的寫操作比硬碟的寫操作快很1000倍)。所以設置定址空間為1GB的意義不大，因為我們是要測試硬碟的全盤性能，而不是Cache的性能。
硬碟優化
硬碟廠商提高硬碟性能的方法主要是降低服務時間(延遲)：
提高轉速(降低旋轉時間和傳輸時間)
增加Cache(降低寫延遲，但不會提高IOPS)
提高單磁軌密度(變相提高傳輸時間)
RAID測試
RAID0/RAID5/RAID6的多塊磁碟可以同時服務，其實就是提高並行度，這樣極大提高了性能(相當於銀行有多個櫃台)。
以前測試過12塊RAID0，100GB的定址空間，4KB隨機寫，逐步提高隊列深度，IOPS會提高，因為它有12塊磁碟(12個磁頭同時工作)，並行度是12。
隊列深度 IOPS 平均響應時間
1 1215.995842 0.820917
2 4657.061317 0.428420
4 5369.326970 0.744060
8 5377.387303 1.486629
16 5487.911660 2.914048
32 5470.972663 5.846616
64 5520.234015 11.585251
128 5542.739816 23.085843
256 5513.994611 46.401606
RAID卡廠商優化的方法也是降低服務時間：
使用大內存Cache
使用IO處理器，降低XOR操作的延遲。
使用更大帶寬的硬碟介面
SAN測試
對於低端磁碟陣列，使用單機IOmeter就可以測試出它的IOPS和MBPS的峰值，但是對於高端磁碟陣列，就需要多機並行測試才能得到IOPS和MBPS的峰值(IOmeter支持多機並行測試)。下圖是紀念照。
磁碟陣列廠商通過以下手段降低服務時間：
更快的存儲網路，比如FC和IB，延時更低。
讀寫Cache。寫數據到Cache之後就馬上返回，不需要落盤。 而且磁碟陣列有更多的控制器和硬碟，大大提高了並行度。
現在的存儲廠商會找SPC幫忙測試自己的磁碟陣列產品(或全快閃記憶體陣列)， 並給SPC支付費用，這就是赤裸裸的標准壟斷。國內也有做存儲系統測試的，假如你要測試磁碟陣列，可以找NSTC (廣告時間)。
SSD測試
SSD的延時很低，並行度很高(多個nand塊同時工作)，缺點是壽命和GC造成的響應時間不穩定。
推薦用IOMeter進行測試，使用大隊列深度，並進行長時間測試，這樣可以測試出SSD的真實性能。
下圖是storagereview對一些SSD硬碟做的4KB隨機寫的長時間測試，可以看出有些SSD硬碟的最大響應時間很不穩定，會飆高到幾百ms，這是不可接受的。
雲硬碟測試
我們通過兩方面來提高雲硬碟的性能的：
降低延遲(使用SSD，使用萬兆網路，優化代碼，減少瓶頸)
提高並行度(數據分片，同時使用整個集群的所有SSD)
在Linux下測試雲硬碟
在Linux下，你可以使用FIO來測試
操作系統：Ubuntu 14.04
CPU： 2
Memory: 2GB
雲硬碟大小： 1TB(SLA: 6000 IOPS, 170MB/s吞吐率 )
安裝fio：
#sudo apt-get install fio
再次介紹一下FIO的測試參數：
ioengine: 負載引擎，我們一般使用lio，發起非同步IO請求。
bs: IO大小
direct: 直寫，繞過操作系統Cache。因為我們測試的是硬碟，而不是操作系統的Cache，所以設置為1。
rw: 讀寫模式，有順序寫write、順序讀read、隨機寫randwrite、隨機讀randread等。
size: 定址空間，IO會落在 [0, size)這個區間的硬碟空間上。這是一個可以影響IOPS的參數。一般設置為硬碟的大小。
filename: 測試對象
iodepth: 隊列深度，只有使用lio時才有意義。這是一個可以影響IOPS的參數。
runtime: 測試時長
4K隨機寫測試
我們首先進行4K隨機寫測試，測試參數和測試結果如下所示：
#fio -ioengine=lio -bs=4k -direct=1 -thread -rw=randwrite -size=100G -filename=/dev/vdb \
-name="EBS 4KB randwrite test" -iodepth=32 -runtime=60
藍色方框表示IOPS是5900，在正常的誤差范圍內。綠色方框表示IO請求的平均響應時間為5.42ms， 黃色方框表示95%的IO請求的響應時間是小於等於 6.24 ms的。
4K隨機讀測試
我們再來進行4K隨機讀測試，測試參數和測試結果如下所示：
#fio -ioengine=lio -bs=4k -direct=1 -thread -rw=randread -size=100G -filename=/dev/vdb \
-name="EBS 4KB randread test" -iodepth=8 -runtime=60
512KB順序寫測試
最後我們來測試512KB順序寫，看看雲硬碟的最大MBPS(吞吐率)是多少，測試參數和測試結果如下所示：
#fio -ioengine=lio -bs=512k -direct=1 -thread -rw=write -size=100G -filename=/dev/vdb \
-name="EBS 512KB seqwrite test" -iodepth=64 -runtime=60
藍色方框表示MBPS為174226KB/s，約為170MB/s。
使用dd測試吞吐率
其實使用dd命令也可以測試出170MB/s的吞吐率，不過需要設置一下內核參數，詳細介紹在 128MB/s VS 170MB/s 章節中。
在Windows下測試雲硬碟
在Windows下，我們一般使用IOMeter測試磁碟的性能，IOMeter不僅功能強大，而且很專業，是測試磁碟性能的首選工具。
IOMeter是圖形化界面(濃濃的MFC框架的味道)，非常方便操作，下面我將使用IOMeter測試我們UOS上1TB的雲硬碟。
操作系統：Window Server 2012 R2 64
CPU： 4
Memory: 8GB
雲硬碟大小： 1TB
當你把雲硬碟掛載到Windows主機之後，你還需要在windows操作系統裡面設置硬碟為聯機狀態。
4K隨機寫測試
打開IOMeter(你需要先下載)，你會看到IOMeter的主界面。在右邊，你回發現4個worker(數量和CPU個數相同)，因為我們現在只需要1個worker，所以你需要把其他3個worker移除掉。現在讓我們來測試硬碟的4K隨機寫，我們選擇好硬碟(Red Hat VirtIO 0001)，設置定址空間(Maximum Disk Size)為50GB(每個硬碟扇區大小是512B，所以一共是 50*1024*1024*1024/512 = 104857600)，設置隊列深度(Outstanding I/Os)為64。
然後在測試集中選擇」4KiB ALIGNED; 0% Read; 100% random(4KB對齊，100%隨機寫操作)」 測試
然後設置測試時間，我們設置測試時長為60秒，測試之前的預熱時間為10秒(IOMeter會發起負載，但是不統計這段時間的結果)。
在最後測試之前，你可以設置查看實時結果，設置實時結果的更新頻率是5秒鍾。最後點擊綠色旗子開始測試。
在測試過程中，我們可以看到實時的測試結果，當前的IOPS是6042，平均IO請求響應時間是10.56ms，這個測試還需要跑38秒，這個測試輪回只有這個測試。
我們可以看到IOMeter自動化程度很高，極大解放測試人員的勞動力，而且可以導出CSV格式的測試結果。
順序讀寫測試
我們再按照上面的步驟，進行了順序讀/寫測試。下面是測試結果：
IO大小 讀寫模式 隊列深度 MBPS
順序寫吞吐測試 512KB 順序寫 64 164.07 MB/s
順序讀吞吐測試 256KB 順序讀 64 179.32 MB/s
雲硬碟的響應時間
當前雲硬碟寫操作的主要延遲是
網路傳輸
多副本，寫三份(數據強一致性)
三份數據都落盤(數據持久化)之後，才返回
IO處理邏輯
我們當前主要是優化IO處理邏輯，並沒有去優化2和3，這是因為我們是把用戶數據的安全性放在第一位。
128MB/s VS 170MB/s
回到最開始的問題 「為什麼使用dd命令測試雲硬碟只有128MB/s」， 這是因為目前雲硬碟在處理超大IO請求時的延遲比SSD高(我們會不斷進行優化)，現在我們有兩種方法來獲得更高的MBPS：
設置max_sectors_kb為256 (系統默認為512)，降低延遲
使用fio來測試，加大隊列深度
通過設置max_sectors_kb這個參數，使用dd也可以測出170MB/s的吞吐量
root@ustack:~# cat /sys/block/vdb/queue/max_sectors_kb
512
root@ustack:~# echo "256" > /sys/block/vdb/queue/max_sectors_kb
root@ustack:~#
root@ustack:~# dd if=/dev/zero of=/dev/vdb bs=32M count=40 oflag=direct
40+0 records in
40+0 records out
1342177280 bytes (1.3 GB) copied, 7.51685 s, 179 MB/s
root@ustack:~#
同時查看IO請求的延遲：
root@ustack:~# iostat -x vdb 5 100
...
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vdb 0.00 0.00 0.00 688.00 0.00 176128.00 512.00 54.59 93.47 0.00 93.47 1.40 96.56
下面是使用fio工具的測試結果，也可以得到170MB/s的吞吐率。
不可測試的指標
IOPS和MBPS是用戶可以使用工具測試的指標，雲硬碟還有一些用戶不可測量的指標
數據一致性
數據持久性
數據可用性
這些指標我們只能通過根據系統架構和約束條件計算得到，然後轉告給用戶。這些指標衡量著公有雲廠商的良心，有機會會專門進行介紹。
總結
上面介紹了一下測試工具和一些觀點，希望對你有所幫助。
測試需要定性和定量
了解存儲模型可以幫助你更好的進行測試
增加隊列深度可以有效測試出IOPS和MBPS的峰值