• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 297,  comments - 15,  trackbacks - 0

            當前影響計算機運算速度的不是CPU,也不是內存而是硬盤。為了是硬盤能有更好的性能表現人們開使使用一種新的磁盤技術——磁盤陣列技術。下面為大家詳細介紹各種磁盤陣列技術的特點。

            當時,RAID是解決我們存儲問題的靈丹妙藥。通過RAID,我們可以將文件系統擴展得更大,獲得更高的吞吐率,甚至還可以增加冗余度以便讓我們可以承受磁盤損失的風險--這種風險在這段時間發生得尤其經常。

            隨著NAS(網絡附加存儲)和SAN(存儲局域網)設備的興起,我們已經不是很需要那種深入到物理存儲然后調整物理存儲以滿足系統需求的技能了。這不是一件好事。我們僅僅是將存儲卸載到外部設備,這并不能改變我們需要深入理解存儲的事實,我們還是需要在理解的基礎上調整存儲以滿足系統的特定需求。

            過去五到十年來,人們似乎誤以為RAID某種程度上相當于系統備份。其實它不是。RAID是一種容錯形式。

            備份和容錯是不同的概念。備份讓你可以在災難發生后恢復數據。容錯是減少災難發生的概率。你可以想象成容錯是在懸崖頂部立一條護欄,而備份是在懸崖底部設立一座醫院。護欄和醫院都是你想要的,但是它們是完全不同的事物。

            一旦我們開始在驅動器上實施RAID,無論是本地連接的還是存儲網絡上的遠程設備,如今的我們可以根據業務需要選擇四種主要的RAID解決方案:RAID 1(鏡像);RAID 5(帶校驗碼的條帶化);RAID 6(帶雙校驗碼的條帶化);RAID 10(帶條帶的鏡像)。

            市場上還有其他類型的RAID,比如RAID 0,不過如果你真正理解你的驅動器子系統需求的話,你就知道RAID 0只適用于很罕見的場合。RAID 50和51也被人們所使用,但是更加少見。十年前,RAID 1和RAID 5是很常見的,但是如今我們有更多的選擇。

            RAID類型

            現在我們一個一個來分析這些RAID,并討論基本的數據。在我們的例子中,我們使用"n"來表示陣列中驅動器的數量,用"s"來表示單個驅動器的大小。通過這些符號,我們可以描述任何陣列的可用存儲空間,讓存儲容量的比較更加方便。

            RAID 1

            在這種RAID類型中,驅動器被鏡像。如果你有兩個驅動器,那么它們同時一起做所有事情,也就是"鏡像"。鏡像可以非常穩定,因為它的流程非常簡單,但是和完全不使用RAID的情況比起來,它需要你購買雙倍的驅動器,因為你要將第二個驅動器指定為冗余驅動器。

            這種RAID的好處就是你可以確保你在磁盤上寫入的每個數據都被重復寫入,從而達到數據保護的目的。通過RAID 1,我們的可用容量計算是(n*s/2)。RAID 1所能提供的相對于非RAID驅動器的性能提升很小。RAID 1的寫入速度和非RAID系統相當,而讀取速度在大部分情況下差不多是非RAID系統的兩倍,因為在讀取操作過程中,驅動器可以并行地訪問,從而提高了吞吐率。RAID 1限定于雙驅動器設置。

            RAID 5

            帶校驗碼的條帶化。在這種類型的RAID中,數據通過復雜的條帶寫入到陣列中的所有驅動器,同時分布式校驗塊留在所有驅動器上。通過這么做,RAID 5可以使用指定大小的三塊以上磁盤的陣列,而且只犧牲與單個校驗磁盤相當的存儲容量。但是校驗碼是分布式的,它并不單獨存在于任何一塊物理磁盤。

            鑒于其成本經濟性,RAID 5經常被使用。在大型陣列中,RAID 5所帶來的容量損失是比較少的。和鏡像不同,帶校驗碼的條帶化需要計算每條寫入條帶,這帶來了一些系統開銷。因此,RAID 5的吞吐量并不是那么容易計算,很大程度上需要依賴于系統在進行校驗碼計算時候的計算能力。

            計算RAID 5的容量很容易:就是((n-1)*s)。一個RAID 5陣列可以承受陣列中任何單個磁盤的故障和損失。

            RAID 6

            帶雙校驗碼的冗余條帶化。RAID 6和RAID 5很像,不過使用的是兩個校驗塊而不是一個校驗塊,從而提高了對抗磁盤故障的保護能力。

            RAID 6是RAID家族的新成員。RAID 6是在幾年前在其他的RAID類型標準化后加入的。RAID 6比較特殊,因為它可以承受陣列中任意兩塊驅動器的故障,并同時防止數據丟失。但是為了提高冗余度,RAID 6陣列需要犧牲陣列中相當于兩塊驅動器的容量,并要求陣列擁有最少四塊驅動器。我們可以用((n-2)*s)來計算RAID 6的可用容量。

            RAID 10

            帶條帶化的鏡像。從技術上來說,RAID 10是復合RAID,結合了無校驗碼條帶(RAID 0)和RAID 1。

            在陣列中只有兩塊驅動器的情況下,許多廠商也使用RAID 10(或RAID 1+0)這個術語,不過實際上這種陣列只是RAID 1,因為只有陣列中擁有四塊以上驅動器條帶化才會開始運作。通過RAID 10,驅動器必須是一對一對地添加,因此陣列中驅動器的數量只可能是偶數。

            RAID 10可以承受占驅動器總數一半的驅動器故障和損失,同時最多只能承受每對驅動器中一個驅動器的故障和損失。RAID 10沒有校驗碼計算,這使得它相對于RAID 5或RAID 6有性能上的優勢,對陣列驅動器計算性能的要求也更低。在所有常見的RAID類型中,RAID 10提供了最高的讀取性能,因為在讀取操作中,陣列中的所有驅動器都可以同時使用。但是它的寫入性能要更低。RAID 10的容量計算和RAID 1相同,即(n*s/2)。

            在如今的企業中,無論RAID軟件或硬件是否已經實施,很少有IT部門需要考慮上述四種基本設置以外的驅動器設置。以前,RAID陣列決策中最主要的考量就是可用容量。這是因為當年驅動器比較貴而且容量比較小。

            如今,驅動器都很大,存儲容量基本上不是問題,至少不像幾年前那樣。驅動器的成本也下降了許多,因此購買更多的驅動器以實現更高的冗余度也基本上不成問題。當容量是主要顧慮的時候,RAID 5是比較受歡迎的選擇,因為和其他陣列類型相比,RAID 5損失的容量比例最小。

            如今,我們有其他方面的顧慮,主要是數據安全性和性能。花稍微更多一點錢來確保數據保護是比較明智的選擇。RAID 5只能承受一塊驅動器的故障和損失。對于擁有三塊驅動器的陣列,RAID 5的安全性只比RAID 1差一些。

            我們可能可以接受三塊驅動器中損失一塊。三塊驅動器損失一塊和兩塊驅動器損失一塊相比好像沒那么讓人害怕。但是如果是更大的陣列呢,比如說16塊驅動器?如果我們只能承受16塊驅動器中損失一塊,那我們有理由懷疑系統的可靠性。

            RAID 6可以填補這個安全性空白。RAID 6在用于大型陣列的時候,不會犧牲多少存儲容量和性能,同時還提供可以承受任意兩塊驅動器故障/損失的保護能力。帶校驗碼的條帶化RAID的支持者經常引用這些數字來安撫客戶的管理層,稱RAID 5/6可以提供足夠"物廉價美"的存儲子系統。但是用戶還有其他因素需要考慮。

            對RAID 10的分析

            在RAID的可靠性--這個也是很少被討論的話題--討論中,幾乎完全被忽視的一個問題就是校驗碼計算的可靠性。

            在RAID 1或RAID 10的情況下,系統不需要"計算"來創建帶校驗碼的條帶。系統以穩定的方式簡單地寫入數據。當一塊驅動器發生故障的時候,它的伙伴會接過工作負荷,在替換 驅動器之前,驅動器性能會有一些下滑。系統沒有會影響現有驅動器成員的重建流程,也沒有校驗條帶重建流程。

            帶校驗碼的RAID陣列需要有一定的計算操作來算出操作的數據是什么以及應該將哪些數據放到驅動器。雖然這種計算非常簡單,但是有出錯的可能性。

            如果RAID 1或RAID 10陣列控制發生故障,從理論上來說,系統有可能在驅動器的內容中寫入壞數據。但是由于控制器本身沒有進行驅動器變動的進程,因此這種情況發生的可能性非常小,因為除了創建鏡像外,系統沒有"重建"流程。

            當帶校驗碼的陣列執行重建操作時,它們會執行復雜的進程來逐步審視陣列的整個內容,然后將丟失的數據寫回到被替代的驅動器。就其本身來說是個簡單的步驟,應該不需要擔心。

            我和其他一些人首先注意到的是稍微不同的情境,即由于與陣列的連接器松動所導致的磁盤連接性的丟失。隨著時間的流逝,服務器中的驅動器有可能會松動,尤其是持續服務好幾年以后。

            在極端的情況下,如果陣列控制器認為一個或更多的驅動器相繼發生故障,驅動器中的好數據會被壞校驗數據所覆蓋,然后返回在線并進行重建。在這種情況下,驅動器本身其實沒有發生故障,也沒有數據丟失。理論上來說其實只要重新調整一下驅動器的位置就可以了。

            在 熱插拔系統中,在故障磁盤移除和替換的基礎上,驅動器重建的管理經常是自動的。因此,在沒有人工干預的情況下,這種丟失和替換驅動器的流程可能會發生-- 而重建流程會開始。在這種流程下,驅動器系統會蒙受風險,如果驅動器陣列再發生這種情況,根據驅動器的狀況,系統可能會開始條帶化壞數據,并覆蓋正常的文 件系統。

            對于服務器管理員來說,最痛苦的莫過于看到沒有驅動器故障的系統僅僅因為不必要的重建操作而丟失整個陣列。

            理論上來說,這種情況不應該發生,而管理員應采取措施來防止這類事件發生。但是判斷底層驅動器控制器的情況,判定驅動器當前和過去的情況,以及判斷驅動器所承載的數據的質量并不是那么容易,還是有可能發生錯誤。

            雖然這種事情發生的概率不高,但是它還是有發生的可能,并使得RAID 5和RAID 6系統的風險計算幾乎變得不可能。除了陣列可以容許的驅動器故障/損失數量外,我們必須考慮校驗碼錯誤的風險。隨著驅動器變得更加可靠,校驗碼錯誤風險顯得更加醒目。

            此外,RAID 5和RAID 6校驗碼需要計算,帶來了系統負擔。校驗碼的計算通常是由專門的RAID硬件來執行的。這種計算帶來了驅動器子系統的延遲性,不過延遲性的大小很大程度上 取決于硬件與軟件的設置。這使得我們幾乎無法比較RAID之間的性能水平,因為每種設置都是獨一無二的。

            如今,RAID決策中最大的問題就是我們可以方便地獲得有關存儲效率和驅動器容錯的指標,但是有關可靠性和性能的指標卻幾乎無法獲得。這里面隱藏的危險是人們經常關注那些可以方便衡量的因素而忽視那些無法方便衡量的因素,盡管這些無法方便衡量的因素有可能帶來重大影響。

            所有類型的RAID都有自己的立足之地,關鍵是考慮使用背景并對風險有完整的理解。我們應該爭取從現在行業中廣泛使用的RAID 5轉變到RAID 10。驅動器現在很便宜,而數據損失所帶來的成本很昂貴。

            from:

            http://tech.watchstor.com/storage-module-121402.htm

            posted on 2010-01-25 22:30 chatler 閱讀(485) 評論(0)  編輯 收藏 引用 所屬分類: storage
            <2010年9月>
            2930311234
            567891011
            12131415161718
            19202122232425
            262728293012
            3456789

            常用鏈接

            留言簿(10)

            隨筆分類(307)

            隨筆檔案(297)

            algorithm

            Books_Free_Online

            C++

            database

            Linux

            Linux shell

            linux socket

            misce

            • cloudward
            • 感覺這個博客還是不錯,雖然做的東西和我不大相關,覺得看看還是有好處的

            network

            OSS

            • Google Android
            • Android is a software stack for mobile devices that includes an operating system, middleware and key applications. This early look at the Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.
            • os161 file list

            overall

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            久久精品国产亚洲av麻豆蜜芽 | 无码八A片人妻少妇久久| 久久国产一片免费观看| 免费一级欧美大片久久网 | 丁香五月综合久久激情| 欧美激情精品久久久久久| 久久午夜福利无码1000合集| 中文国产成人精品久久不卡| 国产精品久久久久天天影视| 久久国产视频网| 久久国产色AV免费观看| 久久精品亚洲福利| 久久久亚洲欧洲日产国码aⅴ| 亚洲国产精品一区二区久久| 欧美一区二区久久精品| 久久久精品午夜免费不卡| 少妇人妻综合久久中文字幕| 99久久伊人精品综合观看| 无码日韩人妻精品久久蜜桃 | 久久久久久av无码免费看大片| 亚洲色欲久久久综合网东京热| 99久久精品免费观看国产| 中文字幕无码免费久久| 久久伊人影视| 久久精品一区二区影院 | 国产韩国精品一区二区三区久久| 日韩亚洲国产综合久久久| 亚洲综合精品香蕉久久网97| 久久99精品国产自在现线小黄鸭| 亚洲а∨天堂久久精品9966| 国产免费福利体检区久久 | 国产精品禁18久久久夂久| 日韩人妻无码一区二区三区久久99| 狠狠精品久久久无码中文字幕 | 久久精品9988| 久久免费精品一区二区| 狠狠色噜噜狠狠狠狠狠色综合久久| 日产精品久久久久久久| 久久99精品久久久久久久久久 | 99久久夜色精品国产网站| 狠狠久久综合伊人不卡|