存儲是系統的最底層，非常重要，如何選擇最合適自己存儲呢? 梳理下知識點，以備後用
1. 存儲應用的場景，瞭解自己的應用需求、預算及數據使用特點
2. 瞭解存儲的相關知識
3. 選擇存儲應注意的要素
4. 存儲的使用和維護
1. 存儲應用的場景，瞭解自己的應用需求、預算及數據使用特點
要清楚存儲是應用在OLAP還是OLTP？對存儲的性能，安全性要求如何？預算是多少？預計未來2-5年的業務增長趨勢？
中端存儲可以提供高響應速度，在磁盤數量相同的條件下，不會比高端存儲差多遠（但高端存儲的擴展能力，可靠性非常強）
2. 瞭解存儲的相關知識
磁盤：
一個IO的訪問，大致分爲三個步驟，第一是磁頭到指定的磁道（尋道），第二是等待需要讀取的數據隨盤片旋轉到磁頭（延遲），第三是讀取數據。相比較前兩個時間，讀取數據的時間可以忽略不計，所以一個IO的響應時間等於尋道時間+延遲時間決定（ssd固態硬盤除外，它的存儲方式不一樣），尋道時間由於是機械的動作，所以很難得到大幅度提高，但是可以通過提高磁盤轉速來提高延遲時間。所以轉速越高的盤，可以承載更多的IOPS。磁盤的IOPS由磁盤的轉速決定，比如15000RPM的磁盤，一般可以承受150個IOPS。
和存儲相關的三個性能參數：IOPS，吞吐量，響應時間
吞吐量：
吞吐量，則由磁盤的轉速和接口決定，轉速決定了內部傳輸率，接口則決定了外部傳輸率，很明顯前者肯定低於後者。常見的接口有ATA，SCCI，SATA，SAS，FC等等。FC接口一般在高端存儲中比較常見，而SAS和SATA多在服務器或者中低端存儲中常見。
影響吞吐量的因素稍微複雜些，由磁盤的數量和存儲的架構決定，當磁盤到達一定的數量後，吞吐量主要受限於存儲的架構。比如某高端存儲，吞吐量最大就是 1.4GB，這是由它內部的架構所決定的。另外還要注意存儲與主機的接口，比如HBA卡，有4Gb和2Gb（這裏是bit，而不是Byte），一般主機和存儲都配有多塊HBA卡
IOPS：
對於一個存儲系統來說，IOPS主要決定於cache的算法，以及磁盤的數量。有時候我們往往會被廠商的數據給忽悠了，第一是cache命中率，廠商利用了某種手段，讓cache命中率非常高，IOPS幾乎可以隨心所欲。另外一個因素就是磁盤的數量，廠家的數據是同型號1000塊磁盤的測試結果，而實際的系統只有幾十或者幾百塊磁盤。
購買存儲時，應該避免買高端的存儲，而只配數量很少的磁盤，廠商非常喜歡你買一個高端的BOX，告訴你擴展性好，現在用不着可以少買點盤，以後可以擴容等等，這完全是忽悠。建議不要超前消費，如果確實對性能追求很高，可以選用容量小一些的磁盤，而磁盤的數量多一些。磁盤的數量可以計算得出，我們的經驗，一般OLTP應用的cache命中率在20%左右，剩下的IO還是要到磁盤上的，根據磁盤的轉速和類型，就可以知道一塊盤能夠承載的IOPS，磁盤數量就可以估算出來了，爲了得到比較好的響應時間，建議每塊磁盤的IOPS不要超過100。
響應時間：
除了IOPS與吞吐量，存儲的另外一個重要性能指標就是單io的響應時間，單io的響應時間與IOPS的當前值，吞吐量大小及cache命中率都有密切的關係，經驗值表示，一個io的響應時間在20ms以後，應用基本可以正常工作，但對於高可用的核心OLTP系統，最佳的IO時間是小10ms。
Stripe：
Stripe的作用就是儘可能的分散IO，它在有些存儲上是可以調節的，但是很多存儲是不可以調節的，一般在128K-512K之間。有一個錯誤的說法是，我在存儲上做了stripe，數據庫的一個IO，所有的磁盤都會響應這個IO。這個說法是錯誤的，對於Oracle來說，一個隨機IO的大小是8K，一般條帶的大小要比8K大得多，所以Oracle一個隨機IO永遠只會落在一塊磁盤上。一塊磁盤在同一個時刻只能響應一個IO，也就是說磁盤沒有併發IO的概念，但是從整個系統來看，不同的磁盤響應不同的IO，宏觀上IO還是分散的，所以我們看到一個數據庫在運行時，所有的磁盤都在忙，實際上每塊磁盤是爲不同的 IO服務。對於順序IO，Oracle的默認設置是128K，最大值由OS決定，一般是1M，如果順序IO的大小大於stripe，那麼一個IO可能會有幾塊盤同時響應，但是很多存儲的stripe都大於128K，這時一個IO還是隻有一塊磁盤響應，由於讀是一個順序的過程（在不同的multiblock read之間，存在一定程度的並行。Oracle每次同時向OS發送若干個multiblock read IO請求，然後把返回的結果合併排序。整個scattered read應該是局部並行，宏觀串行的過程），所以要在數據庫這個級別加上併發，纔可以真正達到提高吞吐量的目的。
有人要問，stripe到底多大合適？假設把stripe做得很小，這樣不是很好嗎？一個IO同時可以讀很多塊盤，大大提高了吞吐量。我們假設stripe爲1K，Oracle一個IO要分佈在8塊不同的磁盤上，但是這時新的問題就出現了，因爲一塊磁盤是不具備併發IO能力的，如果每個IO都佔用很多塊盤，這樣整個系統的併發IO能力就下降了，而且一個8K的IO如果在一塊盤上讀，和從8塊盤上並行讀，不會有很大的差別（也許在一塊盤上讀還要更快），所以stripe不能做的很小。stripe到底設多大，我的觀點是大比小好，不要小於256K，數據倉庫應用可以設置的更大一些。ASM對於數據文件的stripe默認是1M，不要設置太小，經驗表明，1M的性能更好，Oracle也推薦用1M。這說明對於數據庫應用來說，stripe size要稍微大一點，而不是我們想的越細或者越分散越好。
Raid：
RAID一般比較常見的就是RAID10和RAID5，對性能要求比較高的數據庫應用一般都採用RAID10，RAID5也可以用，但是別把redo放在 RAID5上，因爲RAID5的對於redo這種小IO，性能非常差，很容易造成log file sync的等待。一個RAID group中的磁盤數量不宜過多，不要超過10塊，原因是RAID group中磁盤數量越多，壞盤的概率就越大（概率問題）。一些高端存儲對於RAID group中的磁盤數量都是固定的，這主要和存儲的架構有關。使用存儲的過程中，你會發現，越是高端的東西，就越是死板，而中低端存儲則非常靈活，並不是說高端存儲不好，而是說架構決定一切。
存儲劃分
劃分好的LUN輸出到主機後，我們怎麼用？這個就比較靈活多變，首先要看我們的用途，我們是追求IOPS還是吞吐量？我們用file system，raw devices，ASM？存儲輸出的LUN跨在多少塊盤上？一般的存儲沒有虛擬化功能，則輸出的LUN只跨在一個RAID group上，這時往往需要利用OS上的LVM來再次劃分一次，比如有兩個raid group，每個RAID goup有四塊磁盤，建立兩個LUN，輸出到主機後，然後分別創建兩個VG，再創建LV（stripe），這下每個LV就完全跨在了所有的磁盤上。實際中考慮的問題要更多，有時候不僅僅要考慮磁盤，還要考慮將負載分配在不同的控制器，前端卡後端卡和多路徑的問題，相當複雜。有些存儲本身有虛擬化的功能，甚至可以輸出一個LUN，比如3PAR就可以輸出一個虛擬卷，這個卷已經跨在所有的磁盤上，我們直接使用就可以了（但實際工作中這麼使用的比較少見）。
Oracle 有了ASM，問題就更加複雜了，我的建議是如果可以的話，存儲只做RAID1，stripe交給ASM去做。如果有些存儲必須要做stripe，也沒問題。存儲劃分是一個很有技術含量的工作，必須建立在對存儲，主機和數據庫深入瞭解的基礎上，纔有可能做出一個好的規劃。
3. 選擇存儲應注意的要素
1．選擇32位或64位的RISC CPU還是普通的Intel 586 CPU?
服務器的結構已由傳統的I/O結構改爲I2O結構，其目的就是爲了減少服務器中CPU的負擔，將系統的I/O與服務器CPU負載分開。 I2O是由一 顆RISC CPU來負責I/O的工作。服務器上都已用RISC CPU，磁盤陣列上當然也必須用RISC CPU纔不會形成瓶頸。另外，我們現在常用的網絡操作系統大都是32位或64位的，當操作 系統已由32位轉到64位時，磁盤陣列上的CPU必須是RISC CPU才能滿足要求。
2．磁盤陣列內的硬盤是否有順序要求？
也就是說，硬盤是否可以不按原先的次序插回陣列中， 而數據仍能正常存取？很多人都想當然地認爲根本不應該有順序要求，其實不然。我們曾用過一個陣列，其必須按照原來的次序才能正常存取數據。現在假設這樣一種情況，我們準備 清理一下硬盤陣列，把所有硬盤都放在一起，結果記不住順序了，爲了正常存取數據，我們 只有一個個地試，而對於有8塊硬盤的陣列來說，最壞的情況要試88次才行。現在已出現 了磁盤陣列產品具有不要求硬盤順序的功能，爲了防止上述事件發生，應選擇對順序沒有要 求的陣列。
3．是硬件磁盤陣列還是軟件磁盤陣列？
軟件磁盤陣列指的是用一塊SCSI卡與磁盤連接，硬件磁盤陣列指的是陣列櫃中具有背板的陣列，它與軟件磁盤陣列的區別很大。硬件磁盤陣列是一個完整的磁盤陣列系統與系統相接，內置CPU，與主機並行動作，所有的I/O都在磁盤陣列中完成，減輕主機的負擔，增加系統整體性能，有SCSI總線主控與DMA通道，以加速數據的存取與傳輸。而軟件磁盤陣列是一個程序，在主機上執行，通過一塊SCSI卡與磁盤相接形成陣列，其最大的缺點是大大增加了主機的負擔，對於大量輸入輸出的系統，很容易使系統癱瘓。顯然，應儘量選擇硬件磁盤陣列。
4．是IDE磁盤陣列還是SCSI磁盤陣列？
最近市場上出現了IDE磁盤陣列，它們的速度挺快，如增強型IDE在PCI總線下的傳輸速率可達66MB/s，價格與SCSI磁盤陣列相比要便宜得多； 而SCSI Ultra3速率接近160MB/s。但從實際應用情況來看，在單任務時，IDE磁盤陣列比 SCSI磁盤陣列快；在多任務時，SCSI磁盤陣列比IDE磁盤陣列要快得多。但IDE磁盤陣列 有一個致命的缺點：不能帶電熱插拔。這個缺點使IDE磁盤陣列命中註定只能使用於非重要 場合。如果您的應用不能停機，則一定要選擇SCSI磁盤陣列。
5．是單控制器還是冗餘控制器？
磁盤陣列一般都是以一個控制器連接主機及磁盤，在磁盤陣列的容錯功能下達到數據的 完整性。但磁盤陣列控制器同樣會發生故障，在此情況之下，數據就有可能丟失。爲了解決 此問題，可以把兩個控制器用纜線連接起來，相互備份。但兩個獨立控制器在機箱內的連接 意味着一旦出現故障必須打開機箱換控制器，即必須停機，這在很多應用中根本就不可能， 所以，我們應該選擇熱插拔雙控制冗餘的架構。現在有些磁盤陣列新產品上利用快取內存和 內存鏡像的方式，以保證在出現故障時不丟失數據，且在控制器更換後，自動恢復故障前的 工作設置，把工作負荷分散給相互備份的控制器，以達到負載均衡，這種架構能提供單控制 器所達不到的高性能及高安全性。當然如果你對安全要求更高，可以選擇多控制器的高端存儲
6．SCSI接口還是光纖通道接口？
SCSI的完善規格、成熟技術及高性能一直吸引着小型系統，但從目前的情況來看，光纖通道已形成市場，雙環可達200MB/s，且傳輸距離達10km， 可接126個設備。光纖通道把總線與網絡合二爲一，是存儲網絡的根本，其取代SCSI已是大勢所趨。因此，爲了保證系統的生命力，應該選擇光纖通道接口。但光纖通道網絡造價特別高，大約是SCSI接口網絡的4～5倍，且從實際情況來看，光纖通道在管理上仍是一個薄弱之處，對客戶端的軟件要求比校高，所以在選擇時，應根據實際情況來選擇。
4. 存儲的使用和維護
存儲的主要作用是提供大容量，高性能，高安全功能。
存儲的容量：存儲的容量大小決定你選擇存儲的類型（高端存儲大都支持大容量）及raid級別
存儲的高性能：存儲的高性能除了和存儲本身的架構，還和應用方式有關，比如磁盤的速度，raid級別，stripe（條帶）的大小，磁盤
的數量，存儲的相關參數等因素。
存儲的高安全性：存儲的高安全性和存儲架構有關，例如，中低端存儲採用以控制器爲中心的雙控結構，而高端存儲採用以cache爲中心
的多控制器結構；一般要配置適合數量的hotspare盤
cache參數對磁盤陣列性能和可靠性的影響
1. 調整全局cache
在介紹全局cache之前，先來明確兩個概念:cache和buffer，簡單的說，Cache是加速“讀”，而buffer是緩衝 “寫”，前者解決讀的問題，保存從磁盤上讀出的數據，後者是解決寫的問題，保存即將要寫入到磁盤上的數據。在很多情況下，這兩個名詞並沒有嚴格區分，常常把讀寫混合類型稱爲buffer cache
1.1 start and stop cache flush：
這兩個參數影響控制器處理cache區域的操作，在這中情況下是按照先進先出的原則往磁盤上寫數據。這隻對打開了寫cache的情況下適用。
在一般的情況下，在決大多數時候start的值大於stop的值。但是也有少量的情況下start等於stop的值。如start＝stop＝80%意味着，控制器的cache將不允許超過80%的部分用於寫cache操作，在這種情況下，控制會儘可能的將80%的cache做爲寫cache使用，這對應用而言，寫的性能可能是比較，但是在數據的可靠性保護方面可能不是很好。如果從數據保護的角度來看，使用比較小的start和stop值可能是比較好的。（針對cache掉電等意外情況下，cache中丟失數據的多少來考慮）
1.2 cache block size參數
如果IO操作均小於cache block size的大小，那麼每一次IO寫到cache中，都會浪費cache的使用情況（對於一個cache block中沒有使用的部分，不能用做其他的IO）。如果IO操作均大於cache block size，那麼完成一次操作會使用更多的cache block。
2. 指定捲上面的cache參數
2.1 read cache：
允許服務器的讀操作從控制器的cache中讀取所需要的數據，如果數據不在cache，控制器從磁盤中讀取數據並存放在cache中，直到cache flush。
2.2 read－ahead（prefetch）：
允許控制器從磁盤上讀取數據到cache中的時候，讀取附加的一些數據到cache中。在下一次IO可能會使用到這些數據，這樣在性能上可能會有所提高。
2.3 write cache：
數據不直接寫到磁盤，先寫到cache中。不一定write cache能夠提高性能。如在持續的大數據量的時候write cache可能會比關掉cache慢，因爲會頻繁的出現cache flush。
2.4 write cache
是否使用電池保護：如果不用電池保護寫cache，可能會出現數據丟失。
2.5 write cache mirror：
可靠性提高，但是性能會降低。
由於讀、寫均共享cache，因此需要整體考慮用於讀、寫cache的大小，以及對整體性能的影響。
轉載自：文章地址：http://www.aixchina.net/?action-viewnews-itemid-24295