BestPracticeFromDOITWIKIJumpto:navigation,search版權聲明：《EM濟儲最佳實踐〉〉R22的版權歸美國EM四司所有,［感謝DOSTOR網友/Arthas的全力翻譯］。EM濟儲最佳實踐R22中文譯稿可以轉載，轉載時請務必以超鏈接形式標明文章原始出處DOSTOR儲在線和作者與譯者信息及本聲明。目錄［隱藏］1一.關丁性能的探討o1.性能的定義o2.應用的設計為順序或者隨機I/O的優化I/O的大小暫時的模式和峰值的表現(temporalpatternsandpeakactivities)o3.主機文件系統影口向文件系統的緩沖和組合(coalesce)最刀、化I/O的大刀、：文件系統的requestsize最大化的I/O大小文件系統的fragmentation校正對齊問題的I/Ofragementingo4.卷管理器VolumeManagersPlaid應該做的Plaid不應該做的Plaid為高帶寬的設置PlaidsandOLTPo5.主機HBA勺影響HBA卡的限制Powerpatho6.MetaLUNs對比metaLUNffi卷管理器MetaLUN的使用說明和推薦MetaLUN的擴充戰略o7.存儲控制器的影響A.CLARiiON的存儲控制器磁盤的級別和性能o引擎的緩存緩存的大小和速度緩存的設定o9.后端設備(磁盤的子系統)LUN的分布系統和啟動硬盤的影響使用LUN和RAID組的編號方式E.最小化硬盤的競爭F.Stripe和Stripeelement的大小CLARiiONRAID5的stripe優化每一個RAID組的硬盤的個數I.在一個存儲系統里應該使用多少個硬盤J.硬盤的類型和大小2二.為可用性和冗余做考慮o1.高可用性的配屆o2.RAID-level的考慮RAID5RAID1/0RAID3熱備份(Hotspares)o3.把RAID組通過總線和DAEW定跨DA耿綁定硬盤跨后端總線綁定硬盤通過DPEg盤綁定熱備份的策略o4.數據復制的持續性\關于性能的探討性能調優有多重要呢在一個Raid5的陣列組中使用5-9塊硬盤和使用默認的設置，CLARiiON光纖儲系統能發揮極好的性能這是EMCfc性能測試實驗室里測試自己的CLARiiON系統得出來的。CLARiiON存儲系統默認的設置是為實際環境中遇到的大部分工作情形所設計的。但是，有一些工作情景還是需要調優來實現存儲系統的最佳配置。為什么在陣列組里用5到9塊硬盤這個設置并沒有任何神奇的地方，也不是因為這個配置有什么特殊的優化。然而，Raid5使用這個數量的硬盤確實是最有效的利用了校驗，同時也能在合理的時間能重建數據。更小的陣列組會有更高的校驗開銷，而大的陣列組則會花更長的時間來重建數據。這份白皮書探討了在設計優化系統方面的時設計到的許多要素。請注意這里提供的信息是非常有幫助的，尤其當你充分理解了你的陣列的工作情形。因此，EMC推薦你使用NavisphereAnalyzer來分析你的陣歹0的工作情形，并且要定期的復習和回顧相關文檔的基礎知識。同時，請記住在配置一個陣列的時候很少有顯而易見的選擇，所以在有疑問的時候最好是按照默認的配置和保守的評估。［辿］性能的定義以下的名詞在整個白皮書當中都會用到。如果你對他們不熟悉，請回顧一下EMCCLARiiONFibreChannelStorageFundamentals帶寬校驗讀取隨機響應時間要求數據大小Requestsize順序條帶條帶元素Stripeelement吞吐量Write-aside應用的設計應用的設計對系統的表現影響很大。提升性能的最佳方法的第一步就是應用的優化。任何存儲系統的調優都不可能建立一個非常差的應用設計上面。［也］為順序或者隨機I/O的優化非常典型的一個例子是，提升帶寬在順序訪問的調優方面會起顯著作用，因為存儲系統在順序I/O方面會更加有效率--尤其是在RAID5的時候。而為隨機訪問的調優則要改善吞吐量和更快的響應時間，因為這樣會改善處理顧客響應所花的時問。讀和寫的對比寫比讀更加耗費存儲系統的資源，這是基丁CLARiiON對數據保護的機制的應用。寫到writecache是鏡像到兩個存儲控制器的（SR。寫到帶校驗的RaidGroup會碰到校驗運算的要求，而這也要求把冗余的信息寫到磁盤里面。寫到鏡像的RaidGroup會需要兩份數據的拷貝的寫入。讀的開銷相對會小一些，這是因為，從CLARiiON系統的讀的吞吐量會比寫的吞吐量要大一些。但是，對大部分工作情形來看，數據往往是寫入writecache,這樣會有更短的響應時間。讀，在另一方面來說，可能命中cache,也可能不命中cache；而對大部分隨機的工作情形來說，讀比寫會有更高的相應時間，因為數據還是需要從磁盤里面抓取。如果要達到高的隨機讀取吞吐量，需要更好的協作（concurrency）。［外］I/O的大小每一個的I/O都有一個固定的開銷和一個變量的開銷，后者決定丁其他的一些事情，例如I/O的大小。大的I/O能提供更少的固定開銷因為有著更大的數據。因而，對CLARiiON而言大的I/O比小塊的I/O能提供更大的帶寬。如果有足夠的硬盤，在執行大的I/O的時候后段總線的速度將會成為系統的性能瓶頸。小塊的隨機訪問應用（例如OLTP的瓶頸在丁磁盤（的個數），而且很少達到后端總線速率。當設計OLTP的時候，必須要使用基丁磁盤（的個數）的IOP來衡量，而不是使用基丁總線的帶寬來衡量。然而，在一個CLARiiON存儲系統里面，當I/O到了某一個特定的大小的時候，包括writecaching和prfetching都會被bypass掉。是決定用一個大的I/O請求還是把他分成幾個順序的請求，取決丁應用程序和它跟cache之間的相互作用。這些相互作用在“TheRaidengineCache”里會探討到。文件系統也可以影響到I/O的大小，這也在稍后的“Hostfile-systemimpact”中描述到。［也］暫時的模式和峰值的表現(temporalpatternsandpeakactivities)應用的操作設計--如何去使用，什么時候去使用，什么時候需要去備份--都會影響到存儲系統的負載。例如，用作隨機訪問的應用的存儲系統，在備份和批量處理的時候，需要好的順序性能。一般來說，對OLTPW消息應用(任何跟大量隨機訪問I/O有關的),更高的并發處理能力(concurrency)會更好。當有更高的并發處理能力的時候，存儲系統將會獲得更高的吞吐量。使用異步I/O是一種獲得更高的并發處理能力的通常的手法。對帶寬而言，單線程的應用幾乎不能有效地利用四塊硬盤以上帶來的好處，除非requestsize是非常大的(比2MM)或者使用到volumemanager.當最佳的順序性能達到的時候，而此時如果順序處理到磁盤的路徑是唯一的時候，用戶還是可以從有適度并發隨機訪問的光纖硬盤(每個硬盤的I/O在100以下)的設置中獲得一個可接受順序性能。［外］主機文件系統影響在主機層次，通過指定最小最大的I/Orequestsize,文件系統也影響了應用I/O的特性。［外］文件系統的緩沖和組合(coalesce)跟在存儲系統上的cache相似的是，緩沖是文件系統提高性能的一種主要方式。緩沖在大部分的情況下，文件系統的緩沖應該最大化，因為這能減少存儲系統的負載。然而，還是會有一些意外。一般來說，應用自己來調配緩沖，能避免文件系統的緩沖或者在文件系統的緩沖之外工作。這是基丁應用能更加有效的分配緩沖的假設之上。而且，通過避免文件系統的coalesce，應用更能控制I/O的響應時間。但是，正如在64位的服務器里RAM勺容量將會提升到32GB或者更多，這也就有可能把這個文件系統都放在緩沖里面。這就能使讀操作在緩沖下，性能會有非常顯著的提升。(寫操作應該使用寫透(write-through)的方式來達到數據的持續性。)結合Coalescing文件系統的coalesce能幫助我們從存儲系統里獲得更高的帶寬。在大部分順序訪問的操作里面，用最大鄰近和最大物理的文件系統設置來最大化文件系統的結合Coalescing.例如，這種處理方式可以和備份程序一起把64KB的寫操作結合(coalesce)成一個完全stripe的寫操作，這樣在writecache被bypass的情況下，對丁帶校驗的Raid會更加有效果。［外］最小化I/O的大小：文件系統的requestsize文件系統通常都被配置成一個最小的范圍大小，例如4K己8KB或者64KB,這是提供給陣列的最小的不可分割的請求。應用使用的I/O在比這個范圍大小要小的時候，會導致很多不必要的數據遷移和/或read-modify-write的情形出現。這也是考慮應用和文件系統文件的最佳設置的最好辦法。(itisbesttoconsultapplicationandfilesystemdocumentationfortheoptimalsettings)而requestsize沒有被文件系統限制的Rawpartitions,則沒有受到這個約束。［外］最大化的I/O大小如果想要快速的移動大量的數據，那么一個大的I/O(64KB或更大)會更加有幫助。在整合(coalescing)順序的寫操作成RaidGroup整個的stripe的時候，陣列將會更加有效率，正如預讀取大的順序讀操作一樣。大的I/O對從基丁主機的stipe獲得更好的帶寬而言也是很重要的，因為他們將會被基丁srtipe的toplogy打散成更小的大小。［辿］文件系統的fragmentation避免fragmentation和defragementation在一起，這是一個基礎的原貝M注意NTFSt件系統可能被分區成任何形式除了默認的范圍大小，他們不能被大部分的工具所defragement:這個API(程序的接口)并不能允許這樣做。執行一個文件級別的拷貝(到另一個LUN或者執行一個文件系統的備份和恢復)是defragement的一個有效的實現。跨越磁盤的小I/O在一些主機的類型里顯得更加重要，而我們接下來將會探討為什么會導致這種狀況。當以下情況發生的時候，跨越磁盤將會對響應時間有一個顯而易見的影響：a）有大比例的blocksize大丁16KB的隨機I/Ob）NavisphereAnalyzer報告的硬盤的平均等候隊歹U長度比4大的時候對齊4KB或者8KB邊界的時候（例如Exchange和Oracle）,工作負載將會從對齊中獲得一些優勢。但因為I/O當中，小丁6%（對丁4KB或者12%（對丁8KB的I/O都會造成跨盤操作（碰巧的是他們可能會以并行的方式來完成）。這種額外的收益可能很難在實踐中注意到。但如果當一個特定的文件系統和/或應用鼓勵使用對齊的地址空間并且位移（offset）被注明，EMC隹薦使用操作系統的磁盤管理來調整分區。NavisphereLUN的綁定位移（offset）工具應該要小心的使用，因為它可能反而會影響分層的應用同步速度。在Intel架構系統中的文件對齊Intel架構的系統，包括windows2000/windows2003,都會受到在LUN上元數據的位置的影響，這也會導致磁盤分區的不對齊。這是因為遺留的BIOS的代碼問題，BIOS里面用的是磁柱，磁頭和扇區地址來取代LBA地址。（這個問題一樣影響了使用intel架構的linux操作系統，正如WindowsNT2000,和2003。這個問題也一樣影響了運行在intel硬件上的VMWareS統）fdisk命令，正如windows的DiskManager,把MBR（MasterBootRecord）放在每一個SCDI設備上。MBA務會占用設備上的63個扇區。其余可訪問的地址是緊接著這63個隱藏分區。這將會后續的數據結構跟CLARiiONRAID勺stripe變得不對齊。在linux系統上，這個隱藏扇區的多少取決丁bootloader和/或磁盤管理軟件，但63個扇區是一個最常遇到的情況。對丁VMware位移（offset）是63。在任何情況下，這個結果都為確定的比例的I/O而導致不對齊。大的I/O是最受影響的。例如，假設使用CLARiiON默認的stripeelement64KB，所有的64KB的I/O都會導致跨盤操作。對丁那些比這個stripeelement的小的I/O,會導致跨盤操作的I/O的比例，我們可以通過以下公式來計算：Percentageofdatacrossing=（I/Osize）/（stripeelementsize）這個結果會給你一個大致的概念，在不對齊的時候的開銷狀況。當cache慢慢被填充的時候，這種開銷會變得更大。aa[]F.校正對齊問題你可以選擇以下的方法之一來修正對齊的問題。記住，必須只是兩種方法之一：LUN的對齊位移（offset）b.使用分區工具對任何特定的LUN只要使用其中一種，不是兩個。這個是我們經常要強調的。同時，當設定一個metaLUN只有那個basecomponent需要分條的對齊（就是那個被其他LUN掛靠上去的LUN。如果使用LUN的對齊位移，當metaLUN?立的時候，metaLUN勺對齊位移也被設置了。當擴展一個metaLUN不需要再調整了。如果用了分區工具的方法，這個調整只需要在用戶第一次對LUM區的時候來做。用什么方式來做當沒有基丁主機的程序在使用的時候，我們可以使用LUN對齊位移的方式。LUN對齊位移方法對一些復制的軟件操作，如clonesyncI/O,SnapViewCopyOnWriteopertions,MirrowViewsyncI/O,SANCopyI/O等，造成磁盤和strip跨盤的問題。如果可以，使用基丁主機的分區工具方式。避免使用LUN^齊位移方法，假如你在這個LUN上使用了SnapView,SANcopy,MirrorView。相反，應該使用基丁主機的分區工具方式。LUN的位移LUN的位移方法使用把LUNte移，來達到對齊stripe分界的分區。LUNM第一個RAID的stripe的末端開始。換一句話說，將LUN的位移設置成RAIDstripe的大小，會讓（緊接著MB初始的）文件系統對齊了，如下圖2所示。LUN對齊位移的不足之處是它可能會造成任何要對RawLUN?行操作的軟件的I/O請求的不對齊。CLARiiON的復制會對rawLUN操作，如果LUN^位移了，這也會產生跨磁盤的操作。Navisphere中,當LUN被bound的時候和block大小被設置成512byte的時候，位移會被設置成特定的。例如，在一個windows2003系統，將會把63個block設置為位移量。FLARE會調整stripe，因此用戶的數據就會從stripe的開頭來開始。圖2：IntelMBRwithpartitionandLUNoffsetcorrection磁盤分區的對齊基丁主機的分區程序使用增加可設定地址的區域的起始部分，來校正對齊的問題；因此，可設定地址的空間在RAIDstripelement的起始部分開始算起，或者在整個strip的起始部分。因為LUN從正常的地方算起，在RAIDstrip的起始部分，復制軟件操作也是對齊的。事實上，對丁鏡像操作，當secondary被寫入的時候，primary的對齊是被保護了的，因為增加了的分區目錄被寫入了源LUN磁盤分區對齊和windows的系統在WindowsNT,2000,2003系統中，分區軟件，作為WRKWindowsResourceKit）的一部分，可以用來設定分區位移的開始。你必須要在數據寫入LUN^前做這件事，因為diskpar會重新寫分區表：所有在LUN±出現的數據都會丟失掉。對丁隨機訪問操作或者是metaLUN在diskpart中設定起始位移的大小，跟對被用來BindLUN的stripeelementsize的大小一致（一般128blocks）。對丁高帶寬要求的應用，設定起始位移的大小跟LUNstripesize的大小一致。開始，用DiskManager來獲得磁盤的數目。在命令行中，使用diskpar加上-i的選項：diskpar-ix（新的大小是磁盤個數）來檢查已經存在的位移：C:\>diskpar-i0Drive0GeometryInformation<deletedforbrevity>DrivePartition0InformationStatringOffset=32256PartitionLength=664HiddenSectors=63。。。注意HiddenSectors的值。這就是分區的位移的數值1.假如磁盤X有數據你不想丟失，那么備份那個數據2.假如磁盤X是一個RawDrive,跳到第四部。3.刪掉在磁盤X上所有的分區，使之成為一個RawDisk。在命令行中使用diskpar-sX（X是磁盤個數）5.輸入新的起始位移（單位sectors）和分區長度（單位MB*這一步驟寫入為那個磁盤寫入新的MBR和創建新的分區。在你輸入起始位移和分區大小，MBRft被修改了，而新的分區信息出現了。6.在commandprompt輸入diskpar-ix（x為磁盤個數）來復查新近創立的分區上的信息。64位windows系統在64位的windows系統里面，如果按照默認創建，MB啖型的磁盤是對齊的；GPT^區也是按默認對齊，盡管他們有一個小的保留區域（32MB是沒有對齊的。在linux系統中的磁盤分區調整在linux中，在數據寫入LUNN前對齊分區表(table),因為分區影射(map)會被重寫，所有在LUN上的數據都會毀壞。在接下來的例子里，LUN被影射到/dev/emcpowerah，而且LUNstripeelementsize是128blockofdisk軟件工具的使用方式如下所示：fdisk/dev/emcpowerahx#expertmodeb#adjuststartingblocknumber1#choosepartition1128#setitto128,ourstripeelementsizew#writethenewpartition對丁那些會使用snapshot,clone,MirrowView的鏡像構成的LUN^說，這個方法比LUN對齊位移方法更加適用。這對SANCopy中的sources和targets是一樣適用的對丁VMWare勺磁盤分區調整VMware會更加復雜，因為會有兩種情況存在。當對齊rawdisk或者RawDeviceMapping(RDM)卷，實在虛擬主機(VM)層次上來實現對齊的。例如，在windows的虛擬主機上使用diskpar來實現對齊。對丁VMRB，會在ESXServer的層次上使用fdisk來實現對齊，正如diskpar在VM層次。這是因為不管是ESXServer還是客戶端都會把MBF^到LUN上面去。ES泌須對齊VMF箍，而客戶系統必需對其他們的虛擬磁盤。對齊ESXServer:Onserviceconsole,execute"fdisk/dev/sd<x>”,wheresd<x>isthedeviceonwhichyouwouldliketocreatetheVMFSType"n"tocreateanewpartitionType"p"tocreateaprimarypartitionType"n"tocreatepartition#1SelectthedefaultstousethecompletediskType"x"togetintoexpertmodeType"b"tospecifythestartingblockforpartitionsType"1"toselectpartition#1Type"128"tomakepartition#1toalignon64KBboundaryType"r"toreturntomainmenuType"t"tochangepartitiontypeType"fb"tosettypetofb(VMFSvolume)Type"w"towritelabelandthepartitioninformationtodisk通過把分區類型聲明為fb,ESXServer會將這個分區認為一個沒有被格式化的VMF箍。你應該能夠使用MUI或者vmkfstools，把一個VMFSC件系統放上去。對丁Linux的虛擬主機，按照上面歹0出的程序步驟來做。對丁windows的虛擬主機，也是按照上面的程序步驟來做。［施］的I/Ofragementing對丁linux來說，避免對一個LUN±的多個大文件的并發訪問是很重要的。否則，這回造成來自不同的線程的許多個訪問，使用不同的虛假設備來訪問同一個潛在的設備。這種沖突減少了寫操作的coalescing。最好還是使用很多個小的LUN每一個有一個單一的大的文件。動態LUN的融合和偏移如果你使用一個基丁主機的分區工具來對齊數據，在你融合幾個LUN的時候，這個對齊也會被保留。這是假設所有LUN的LUNstripesize是一致的。假如NavisphereBindOffset被融合的源LUN所使用，那么目標LUN在bound用來調整stripe對齊的時候，必須要使用BindOffset。［也］4.卷管理器VolumeManagers對卷管理器的主要性能影響因素，是CLARiiONLUN使用了stripe的方式（我們所說的plaid或者stripeonstripe）。我們要避免使用基丁主機RAID而且使用校驗（如Raid3,Raid5）的應用。這會消耗掉主機的資源來實現這一服務（校驗保護），而這其實讓存儲系統來實現這個服務會更加好。圖三顯示了在以下章節中討論到的三種不同plaid技術對丁所有的情形，都會遵從以下規則：［施］Plaid應該做的把主機管理器的stripe深度（stripeelement）設成CLARiiONLUN的stripesize。你可以使用整數倍的，但最好還是把stripeelement設定在512KB或者1MB簡而言之，從基本的CLARiiONLUN上來考慮建立逐級管理器的stripe。從分開的磁盤組來使用LUN這個組應該有相同的參數（stripesize,diskcount,RAIDtype,等等）。［］Plaid不應該做的千萬不要在同一個RAIDgroup里把多個LUNstripe（譯者注：stripe和concatenate都是meteLUN勺一種方式，下文中的英文部分的stripe都是特指這個）在一起。這是因為會造成大量的磁盤尋道。如果你從一個磁盤組需要捆綁多個LUN使用concatenate來實現-千萬不要使用striping的方式。不要使主機的stripeelement比CLARiiON的RAIDstripesize小。不要對那些具有不同RAIDtype和stripesize的RAIDGroup,或者根本不同磁盤組的LUN使用plaid的方式在一起。結果并不一定是災難性的，但很可能會出現未知的因素。［穿］Plaid為高帶寬的設置plaid在以下幾個原因使用在高帶寬的應用里面：plaid可以增加存儲系統的協作（并行訪問）。plaid允許多丁一個的主機HBM和CLARiiON的存儲運算器（SD共同為一個volume所用。非常大的卷可以被分布到多丁一個的CLARiiON系統之上。增加協作Plaid在應用是單線程（也就是說，讀一個單一的大文件）的時候會比較有用。如果應用的I/O的大小正好跟卷管理器的條帶大小一致，那么卷管理器可以訪問那些可以包裝成卷的并發的LUN從多個存儲器分布式訪問跨越存儲系統，正如在圖三的配置B里面所演示那樣，僅僅當文件系統的大小和帶寬要求需要這樣的一個設計的時候，才被建議使用。例如，一個30TB的地質信息系統數據庫，要求的寫的帶寬超過了一個array所能達到的極限，將會是一個多系統plaid的候選者。必須注意的是，一個軟0的更新或者任何存儲系統的出錯一-例如因為一個存儲系統上的一個組件的出錯而導致的寫緩存的停用一-將會影響到整個文件系統。［外］PlaidsandOLTPOLTF?用是難以去分析，也難以去忍受一些熱點。Plaids是一種有效的策略來使I/O從多個軸來分布式訪問。一個可以讓很多個磁盤處丁忙碌狀態的應用，將會從多個硬盤數中得益。注意一些卷的管理建議小的主機stripe（16KB到64KB。這對使用一種stripe的Raidtype的CLARiiON來說并不正確。對丁OLTP卷管理器的stripeelement應該跟CLARiiON的stripesize（典型來說是128KB到512KB。Plaid對丁OLTP主要的開銷，在丁大部分的用戶以跨plaid的方式結束。跨plaid磁盤一-連同磁盤組一-會變得更大；因此，用戶也常常會因為好幾個主機卷被同一個CLARiiON的Raidgroups所創立（一個跨plaid—看圖三中的配置C）而結這個設計的基本原理是在丁以下的情況：對丁任何一個卷組的隨機行為的爆發，將會分布到多個磁盤上去。這個的不足之處在丁測定卷之間的相互作用，是相當困難的。但是，一個跨plaid也有可能是有效率的，當以下情況存在的時候:.I/Osizes比較小（8KB或更小）和隨機的訪問.卷是受制丁一天中不同時間的爆發，而不是同一時刻。［穿］5.主機HBA勺影響用來實現主機附加的拓撲，取決丁系統的目標。高可用性要求雙HBA^和到存儲器的雙路徑。雙路徑對性能的影響，主要看管理者如何去從系統資源里得到負載均衡的能力。在對存儲系統調優的時候，必須牢記HB"和驅動的作用。EMC勺E-Lab提供了設置磁盤和固件的建議，而我們必須要按這些建議來操作。［穿］HBA卡的限制HBM的固件，HBA#使用的驅動的版本，和主機的操作系統，都可以影響到在存儲陣列中的最大量的I/Osize和并發訪問的程度。［外］Powerpath如果操作系統可以使用，Powerpath這個軟件應該總是要使用的一-不管是對丁一個單一連接到一個交換機的系統（允許主機繼續訪問，當軟件升級的時候）還是在一個完全冗余的系統。除了基本的failover之外，Powerpath還允許主機通過多個存儲處理器（SP）的端口來連接到一個LUN上面一--一種我們通常稱之為多路徑的技術。Powerpath通過負載均衡算，來優化多路徑訪問LUNPowerpath提供了幾種負載均衡的算法，默認的那種ClarOpt是我們所推薦的。ClarOpt可以調整傳輸byte的數量，正如隊歹U的深度一樣。連接到所有目前的CLARiiON的型號的主機，都可以從多路徑中獲益。直接連接的多路徑需要至少兩張HBM;實際的SAN^路徑需要兩張HBM,其中的每一個都會被分配到多丁一個SP端口的區域。多路徑的好處在丁：在同一個SP中，可以從一個端口failover到另一個端口，修復一個事件的系統工作。在SP的端口和主機HB"中的負載均衡從主機到存儲系統中獲得更高的帶寬（假設主機里，路徑能使用足夠多的HBA^）當Powerpath提供了所有可行路徑的負載均衡，這會帶來一些附加的開銷：一些主機的CPUS源會被一般的操作所使用，正如會被failover的時候使用。在一些情形下，活躍的路徑會增加一些時間來failover。（Powerpath在嘗試幾條路徑之后，才會trespass一個LUNM一個SP到另一個SP）因為這些事實，活躍的路徑應該受到限制，通過zoning,到兩個存儲系統的端口對應一個HBA卡來影射到一個被主機綁定的存儲系統。一個例外是，在從其它共享存儲系統端口的主機所爆發的環境，是不可預知和嚴峻的。在這個情形下，四個存儲系統的端口都有一個各自的HBA#,這是可以實現的。［施］6.MetaLUNsMetaLU說一個所有CLARiiON系列存儲系統都特有的功能。我們從好幾個方面來討論什么時候和怎么用metaLUN［址］對比metaLUN^卷管理器在一個CLARiiON存儲系統,metaLUN^當作一個在RAID引擎之上的層，在功能上來說相似丁主機上的一個卷管理器。但是，在metaLUN^卷管理器之間還是有很多重要的明顯的區別。單一的SCSI目標對比很多的SCSI目標要創建一個卷管理器的stripe,所有構成的LUN必須設定成可以訪問到主機的。MetaLUN?求只有一個單一的SCSILUN被影射到主機；這個主機并不能看到組成這個metaLUN的多個LUN這會讓管理員在以下幾個情形下得益：對丁因為O部艮制而有受限制的LUN可用的主機對丁那些增加LUN導致SCSI設備重編號的主機；經常一個內核需要重建，用來活除設備的條目。在這些情形下，使用metaLUN而不是卷管理器會簡化在主機上的管理。沒有卷管理器不是所有的操作系統都有卷管理器的支持。MS的ServerWin2000/2003集群使用MicrosoftClusterServices（MSCS并不能使用動態磁盤。MetaLUNU一個可以為這些系統提供可擴展的，stripe和concatenated（連接的）卷的解決方案。卷的復制如果卷是要被使用SnapView,MirrorView或者SANCopy的存儲系統所復制的話，一個可用的鏡像會要求持續的處理分離的能力。采用metaLUN^簡化復制。卷訪問共享的介質當一個使用了stripe或者concatenate的卷必須要允許在主機問共享訪問，一個卷管理器不能許可共享訪問,而metaLUW以使用并實現這個功能。MetaLUN可以在兩個的主機存儲組之間應用。存儲處理器（SP）的帶寬卷管理器的卷和metaLUN^問的一個重要的顯著區別是，metaLUN^可以被一個CLARiiON存儲系統上的一個存儲處理器完全的訪問。如果一個單一的卷需要非常高的帶寬，一個卷管理器仍然是最好的方式，因為卷可以從不同的SP上的LUN上來建立。一個卷管理器允許用戶訪問存儲器，通過很多個SP的集合起來的帶寬。卷管理器和并發訪問正如在“Plaids：為高帶寬設置”章節里指出的那樣，基丁主機的stripe的卷的使用，對丁有多線程的大的request（那些有多丁一個卷stripesegment組成的request）,會有比較高的效果。這會增加存儲器的并發訪問能力。使用metaLUW會帶來多線程上好的效果，因為componentLUNL±的多路復用是由存儲系統來實現的。［施］MetaLUN的使用說明和推薦MetaLUNfe含了以下三種類型：條帶的（stripe），結和的（concatenate）,和混合的（hybrid）。這個意節會做出幾個通常的推薦。對那些想要更多細節的人來說，接下來的意節中將會定位建立metaLUNffi相關每種類型的優點的策略和方法。什么時候使用metaLUN通過前面的卷管理器的討論，應該在以下情形下使用metaLUN當大量的存儲整合變得有必要的時候（每一個卷都需要非常多的很多磁盤）當要求LUN的擴展的時候當你建立一個metaLUN的時候，你可以控制以下的要素：componentLUN的類型，metaLUN勺類型，和stirpemultiplier（增加的）。ComponentLUN的類型用來綁定在一個metaLU時的LUN的類型應該能反映metaLU壯要求的I/O的形式。例如，使用在這份白皮書里面建議的各種不同的Raid的類型（“Raid的類型和性能”提供了更多的信息），來匹配I/O的形式。當綁定componentLUN的時候，使用以下規則：當為metaLUNO定LUN的時候，總是使用默認的stripeelementsize（128block）總是激活讀緩存和寫緩存確保為componentLUN設置的write-aside的大小為2048。（write-aside在“RAID引擎緩存”里面會被提到）避免在RAID5的磁盤組里使用少于4塊的硬盤（或者說，至少是要3+1模式）使用RAID1/0磁盤組的時候，至少使用4塊硬盤（新的1+1并不是對metaLUN勺一個好的選擇）不要使用componentLUN位移來校正stripe的對齊。MetaLUNW他們自己的位移值。MetaLUN的類型一般來說，盡可能的使用stripe方式的metaLUN因為他們能體現出我們能預知的更好的性能。Concatenat—個單獨的LUN給一個metaLUN會更加方便；這可能在擴展一個對性能并不敏感的卷會更加合適。HybridmetaLUN使用stripe的方式捆綁concatenate的LUN這個方式被用來克服stipe擴展的成本（這樣會比較低）。一個采用stripe方式的metaLUNM以通過concatenate另一個stripecomponent的方式來擴展。這樣保持了stripecomponent可預計的性能，也允許用戶用來擴展一個stripe的metaLUNffi不用隊已經出線的數據的重組（性能將會受到影響，當重新條帶化操作進行的時候）圖四展示了這一點。圖四hybrid-stripedmetaLUN在理想的情況下，在擴展stripe設置的LUN務會分布在同樣RAID類型的不同的RAID組里面，也會表現得更原始的stripecomponent一致。大部分最直接的方式是使用同一個RAID組作為基礎的component。這個RAID組是被最先擴展的，以便使空間變的可用。這個方式在“metaLUN擴展方法”里會演示。RAID組的擴展是更加有效率的，對比metaLUNrestripe（把這個重分條過程設置成中等優先級別），也會對主機性能有更小的影響。MetaLUNstripemultiplierstripemultiplier決定了metaLUN勺stripeelementsize:Stripemultiplier*baseLUNstripesize=metaLUNstripesegmentsizeMetaLUNstripesegmentsize是任何componentLUN能收到的最大的I/O。所有的高帶寬性能和隨機分布都要求metaLUNstripeelement的大小為1MB左右。而且，在下面的RAID組還可能被擴充。我們需要確保metaLUNstripeelement是足夠大，大到跟寫的完全的stripe一樣，用來擴展componentLUN（圖表1）。使用以下規則來設置stripemultiplier:除非使用RAID0,使用最少四個磁盤的磁盤組，來組成作為componentLUN主機的RAID組。為磁盤組的大小來測定選擇有效的磁盤個數。例如，六個磁盤的RAID1/0是3（3+3）。五個磁盤的RAID5是4（4+1）通過圖表1,為有效磁盤的個數而選擇multiplier如果有疑問，使用4作為metaLUN的stripemultiplier。對大部分情形來說,這是一個默認的，也是一個好的選擇。MetaLUNM齊的位移如果你計劃通過metaLUM使用SnapView或者MirrorView,把metaLUNM齊位移值設為0。使用磁盤分區工具來調整分區的位移。MetaLUNfflATA磁盤在這個時彳，ATA并不適合繁忙的隨機I/O訪問的方案。這個章節集中在使用ATA磁盤作為高帶寬的應用。保持RAID組的足夠小，是metaLUNffi略的一部分。這會使ATA硬盤更加合理，因為小的磁盤組比大的會有更小的重組時間。但是，必須意識到的時，metaLUN會被一個單一的磁盤組的rebuild所影響，而ATA磁盤的rebulid時間是冗長的。基丁數據可用性的考量，在非常多的環境里，我們最好避免使用ATA硬盤來做metaLUNB非動態擴展或者需要非常大的一個容量。CLI例子：建立一個metaLUN在接下來的例子的代碼，我們建立一個stripe方式的使用baseLUN30的metaLUN沒有建立metaLUN的命令；你需要擴展一個已經出現的FLARELUNfE建立一個metaLUN在命令中設計而成的LUN都是相同RAID的類型和容量的FLARE_UNLUN30會變成基本的一新的metaLU抵把30作為他的identifier。Matalun-expand-base30Tus313233-nameP1H00-elszm4-typeS擴展的類型被設置成S,作為stripe方式，而選擇elementsize(4)是因為LUN是建立在5塊硬盤的RAID5組里面。［也］MetaLUN的擴充戰略對丁有長期擴展計劃的用戶來說，有好幾種使用策略。使用一種策略，你必須要確認你的目標。在接下來的章節會出現的一些可能的目標如下：把本地的爆發的隨機數據分布到多個磁盤上去好的順序/帶寬的性能有效的利用容量靈活的擴展設備這些都是使用metaLUN的用戶的主要的目的。擴展模式的初始化配置初始化安裝的規則在圖5中闡明。這些規則是：為初始化容量部署，來部署所需要的磁盤建立合適大小的磁盤陣歹0組：對于RAID1/0，使用4或6個硬盤對于RAID5或者RAID3使用5個硬盤把磁盤組按照每一個set有4-8個RAID組的方法來組織。（如果要求高的隨機I/O,那么需要更多的磁盤組）對于每一個metaLUN根據歸屆來確定Raid組的set。對每一個計劃要做的metaLUN通過用RAID組在自己的RAID組set里面的數目來分metaLUN的大小,來確定componentLUN的大小。從每一個在自己set里的RAID組里，為每一個metaLU睡立一個component。建立metaLUN勺時候，請讓組成這個metaLUN的LUN跨越所有的的RAID組set里的RAID組。圖5是一個set的metaLUNO他們的RAID組set的例子Figure5.metaLUN里面的存儲的初始化分布注意到在圖5,每一個metaLUN由一個對應一個RAID組的LUNffl成。因此，每一個LUN的負載是分布在所有在那個set里的RAID組。但是，這些metaLUN?和對其他RAID組的set的數據訪問是分隔開的。為什么要使用RAID組的set如果我們不允許一個metaLUM擴展到自己的set以外，我們可以做出一定級別的隔離，將這種影響控制在磁盤的級別。例如，一個RAID組的set可能為一大群文件服務器所設立，而另一個RAID組的set是為RDBMS數據目錄這時一對普通的RAID1組可能被使用作為RDBMS日志設備。圖6展示了這一點。圖6:用RAID組的set和metaLUN^做數據分隔的例子在圖6里面顯示的例子，通過訪問到NFS的共享metaLUN并不會十涉到Oracle服務器訪問他們自己的數據目錄或者日志。擴展模式的的擴展程序下一步是建立擴展的策略。擴展的目標：維持擴越很多磁盤的分布更有效的利用容量達致這個目標的途徑當容量對metaLUM說是可以預計的，把磁盤增加到set已經出現的RAID組里面。對metaLUNfi的set里面的RAID組進行擴展對metaLUNfi增加擴展的LUN乍為一個新的stripe的componentMetaLUN的擴展例子這個例子里使用的途徑，和metaLUN?置的原始的目標是緊密結合的I/O分布在所有的磁盤上。第一步，IS部門確定MetaA的容量使用率超過了他的警戒線一85%--同時也會告知用戶要注意這個metaLUN在周末的時候，IS接受一個外加160GB請求。這個系統的操作員增加2個磁盤，至UmetaLUNA所在的set里的每一個RAID組。RAID組的擴展被設置成中等優先級別，這對性能影響會非常小。每一個組的存儲增加了一個磁盤的容量（66GB,如圖7所示。圖7.對metaLUN勺擴展：第一步下一步是對metaLUNset的每一個RAID組綁定一個LUN他們必須要擴展的總的容量是160GB而我們在這個metaLUNset里面有四個RAID組，所以160/4=40。一個40GB的LUN必須限定在set里的每一個RAID組。最后一部是使用4個建立的LUN來擴展metaLUN操作員指派要被增加的LUN并且把擴展設置為concatenate的方式。因為擴展的LUN^P是一樣的大小，所以navisphereconcatenate一個新的stripe的component至UmetaLUN來組成這些LUN（圖8）圖8:MetaLUN的擴展：第二步接下來的是一個CLI方式（命令行）的命令的例子：通過concatenate一個新的stripecomponent來擴展metaLUN這個metaLUN的identifier是30。FLARELUN34,35,36,37都有一樣的RAID的類型和容量：metalun-expand-base30-lus34353637-typec擴展的類型被設置成C,代表concatenate的方式。Navishpere會以stripe方式把LUN捆綁成一個新的component,然后加到已經出現的metaLUNmetaLUN30上面去。基丁LUN堆疊的metaLun正如前面的例子那樣，當從一個set的RAID組里建立多個metaLUN掉轉你為每一個metaLUN定位的baseLUN里的RAID組。這可以把磁盤組里的數據庫，文件系統，甚至是一個備份的過程里的hotedge分布開去，如圖9所示。每一中顏色的stripe表示不同的metaLUN每一個meta的baseLUN在不同的RAID組里面。圖9:基丁LUN^疊的metaLUN［外］7.存儲控制器的影響這個章節指導用戶怎樣使用CLARiiON的硬件來匹配相對應的性能要求。［穿］CLARiiON的存儲控制器EMC勺CX系列陣列的存儲控制器跟以前的型號不同的地方，是他們支持了連接到前端主機和后段磁盤的4Gb/s和2Gb/s的速度；事實上，在同一個存儲系統，兩種速度都可以實現。相對低端的產品，CX3-20和CX3-40,當使用了4Gb的硬盤的時候，在帶寬方面的性能跟我們老的CX500和CX700相對應。如果配置成2Gb的硬盤，會導致只有一半的可用的帶寬，因而工作的負載應該在只升級SP的時候仔細的調研。基丁磁盤的OLTP應用受到后段的loopspeed的影響很小，所以我們應該把大部分注意力放在備份和DSS的帶寬狀況尚。CX3存儲器家族的參數特點如下：針對Rlease22的新的架構和調整，相當地改進了rebuild的時間。在（4+1）Raid5的測試中，如果沒有負載的情況下，對hotspare的4Gb15k73G硬盤的rebuild大概需要30分鐘，比CX700少了50%如果持續的8KB隨機負載（Read/Write=2?:1）占用了70%勺磁盤利用率（典型的OLTP^載），則這個過程需要55分鐘。吞吐量下降了大概50%High,Medium和Low三種設置相對應的rebuild時間是6,12和18小時,這對主機的負載很小［址］磁盤的級別和性能CLARiiON存儲系統通常使用RAID5來做數據保護和性能的應用。當適當的時候,也會使用RAID1/0，但使用RAID1/0往往不是基丁性能方面的考慮。我們可以通過CLARiiONBlockStorageFundamentals白皮書來了解為什么RAID5^有更好的性能。什么時候使用RAID5消息，數據挖掘，中等性能的流媒體服務，和在DBA?用read-ahead和write-behind策略的RDBM應用，使用RAID5是能獲得比較好的性能的。如果主機的OSffiHBAM以支持大丁64KB的transfer的時候,RAID5是不二的選擇。以下的應用類型，使用RAID5是比較理想的：有適度的IO/s-per-gigabyte要求的隨機的工作負載當寫操作只占用了30%￡者更少的工作負載時的高性能隨機I/O一個順序訪問的決策支持系統（DSS的數據庫（計算銷售記錄的統計分析）任何記錄大小大丁64KB和隨機訪問的RDBMS的目錄空間（個人的二元內容的紀錄，例如照片）RDBM的日志行為消息應用圖像/流媒體什么時候使用RAID1/0在使用非常小的，隨機的，和write-intensive的I/O（其中30%勺負載都是用來執行寫操作）時，RAID1/0在負載方面會比RAID5更具有優勢。一些隨機的，小I/O的工作負載的例子：繁忙的事務性的OLTP大的消息的安裝實時的數據/業務記錄包含了經常更新的小的記錄的RDBMS據目錄（賬目平衡）對一些特定的降級模式一--也就是，當寫緩存被關閉或者在RAID組里面一個磁盤出現問題的時候，RAID1/0也會有更好的表現。什么時候使用RAID3新的RAID5的設計使每八個stripe后寫入校驗的磁盤，這樣使RAID5也能像RAID3那樣在順序的工作負載中得到好處。RAID5實質上可以達到RAID3一樣的帶寬。對丁順序寫的工作負載，當以下三個要求達到的時候，RAID3在配置里可以實現更高的讀帶寬：1）磁盤個數決定了帶寬（后段磁盤loop只有很少個數的磁盤）2）文件很大（大丁2MB3）文件沒有打碎。必須了解的是：對丁許多的順序的應用，從陣列得到的帶寬，通常是取決丁component的容量，而不是取決丁像ATA的盤柜的BBC卡和/或后段loop的硬盤個數。在這些情形下（在任何有隨機的工作負載的情形），最好還是使用RAID5來取代RAID3因為RAID3固定的校驗盤會變成非順序的工作負載中的component的瓶頸。什么時候使用RAID1在R16里介紹了1+1RAID1/0的好處，我們沒有任何好的理由來使用RAID1。RAID1/01+1模式是可以擴展的，而RAID1模式則無法做到這一點。［施］引擎的緩存這個章節討論了使用合適的緩存頁面，如何使用預讀取緩存的大小，在哪里設置警戒線，和其他的一些如SP的負載均衡等方面的技巧。［辿］A.緩存的大小和速度在EMCCLARiiONFibreChannelStorageFundamentals白皮書里面，對丁cache大小對性能的影響，我們有全面的信息。對丁那些有1GB或者更少的可用cache內存的存儲器，使用其中的20%乍為讀緩存，把其余作為寫緩存。對丁其他所有的系統，使用最多的可允許的數值作為寫緩存，而其他的作為讀緩存。Cache設置的腳本在很多環境里，產品的工作負載對丁一天的不同時間來說，變化是非常多的。例如，從8:00am到5:00pm工作負載可能會是OLTP居多；而從5?:00PM到8:00PM工作負載可能變成作為報告的多線程的順序訪問DSS而從8:00PMfe后,備份系統工作開始。如果需要為不同類型的工作負載調優，可用NavisphereCLI的腳本來調整cache的參數。一些參數，例如SP的讀緩存的開啟/關閉，SP的讀緩存的大小，LUN的讀和寫的緩存的開啟/關閉，LUN預讀取設置，和警戒線的設置，都可以被不問斷存儲器工作的情況下被改變。另外，如SP的寫緩存的大小和頁面大小的調整，會要求SP寫緩存被關閉，這個時間段會嚴重影響寫操作的響應時間，因而操作要盡快完成。［穿］B.緩存的設定在CLARiiON存儲系統里面，以下列出的緩存參數，都有適用丁大部分用戶的默認的設置。緩存的開啟/關閉大部分工作負載都會從讀緩存和寫緩存里面得到好處；兩者默認的設置是開啟。用來節省一個非常短的服務時間（當讀操作到來時，檢查緩存有無命中的毫秒級別），關閉LUN上的讀的緩存并不會使系統性能受益。例如，有非常多隨機讀操作的環境（沒有順序訪問）的LUN并不會從讀緩存里受益。同樣的，有很多同時的順序訪問的數據流（通常是DSS的LUN可以從關閉讀緩存（或者關閉預讀取）來避免數據傳輸的“顛簸”。當同步的clone進行時，一些用戶會關閉緩存來得到一個“中間”的帶寬，即在盡快的模式和最小的SP利用率之間取得平衡。當準備為備份設置時，使用NavisphereCLI腳本來開啟LUN的讀緩存。寫緩存是很有效的，除了最極端的寫環境里面。寫緩存的鈍化最好是使用每一個LUN的write-aside的設置。（可參考“write-aside的大小”）。頁面大小在I/O的大小是非常穩定的情形下，你可以通過設置cache的頁面大小跟存儲系統所見的要求的大小（文件系統的block的小，或者在使用裸分區使用時的應用的block大小）一致，來獲得性能。在有大量I/O大小的環境,8KB的頁面大小是最佳的。大量使用SnapView,MirrorView/A，或者增量SANcopy的系統，會從16KB的緩存頁面大小設置中得益，因為內部的頁面調度是使用64KB大小的block。如果應用的工作負載是由小block所支配的，警戒線應該設置到60/40。當使用2KB的緩存頁面大小設置的時候，要注意。使用多丁5個的硬盤的，到校驗RAID組的順序寫操作，可能會受到影響。“CLARiiONRAID5stripoptimizations”里有更多的相關信息。HAvault的選項和寫緩存的行為我們可以在存儲系統的屆性對話框里的Cache標號上找到HACacheVault選項,上面默認的設置是開啟的。在EMCCLARiiONFibreChannelStorageFundamentals白皮書上有關于這個默認設置方面的描述。幾種故障（在那個白皮書里有說明）會導致寫緩存的關閉和把緩存上的內容導到系統硬盤里面（vault）。其中一種故障是系統硬盤里的一個磁盤。如果用戶活除了HACacheVault選項，那么一個系統磁硬盤的故障就不會導致寫緩存的關閉。因為關閉寫緩存會顯而易見地影響主機的I/O,所以要盡可能的讓寫緩存保持在開啟的狀態。因而，用戶可以自己選擇。為什么這作為一個選擇呢活除這個選項，會導致顧客有可能遭遇到數據丟失的三種情形：假如一個系統硬盤壞掉了，那么數據將不會倒入。假如另一個系統硬盤在第一個壞的硬盤被更換之前壞掉，和系統遭遇了一個電力系統的故障，緩存里面的內容就會丟失。相類似的是，如果在初始化的系統硬盤壞掉了之后，乂遭遇電力的中斷，然后第二個硬盤在數據倒入期間或者在隨后出現故障，數據也會丟失。用戶需要在性能的提升和風險之間作一個決定。預讀取的設定預讀取（變量，segment和倍數都設置為4）的默認設置對大部分工作負載來說，都能有效地利用緩存。改變倍數會導致無法預計的結果；當順序性能需要調優的時候，最好和CLARiiONSPEEDS家一起使用。高和低的水位線和flushingCLARiiON的設計有兩種稱之為水位線（watermark）全局的設置一--高和低用來管理flushing。細節方面的內容，在storagefundamentals白皮書有敘述。對于大部分的工作負載來說，默認的設置（80%乍為高水位線，60%乍為低水位線）可以提供最好的性能。如果寫操作的爆發導致了足夠多的flush,影響了主機的寫的工作負載，那么需要降低水位線。降低水位線會導致更加劇烈的flush,這會讓更多的空閑的緩存頁面來存放爆發的數據，這樣的代價是從寫緩存里讀命中會更加的少。對于小一些的CX系統，降低水位線到60/40可以幫助降低flush的條件。當改變的時候，高和低的水位線一般來說增加或減少同樣的數量。Write-aside的大小write-aside的大小跟每一個LUN的設置有關。這個設置會指定會被載入緩存的最大的寫請求。謝操作大于這個大小的，會不經過寫緩存。Write-aside使大的I/O不會占用了寫緩存鏡像的帶寬，也讓系統有可能得到超越了寫緩存鏡像的最大帶寬。這個代價就是被旁路的那些I/O會比載入緩存的I/O有更長的主機相應時間。要像得到超越寫緩存最大帶寬，則必須要有足夠多的磁盤來承擔這些負載。更進一步說，如果使用了帶校驗的RAID(RAID5或者RAID3,必須保證以下條件：I/O跟LUN的stipe大小一致或者是倍數主機能生成足夠的并發，來保證LUN呆持在繁忙中I/O對起stripe達到FullStripeWrites的要求(請參看“CLARiiONRAID5stipeoptimizations")這些條件對丁帶校驗的RAID來說，是至關緊要的，而且是不能被輕易改變的。使I/O對齊來實現有效的write-aside并不容易。如果有疑問，還是使用寫緩存。使用write-aside的折衷如下：數據像這樣的寫入，在緩存里為一個并發的讀來說，并不是可用的。這樣的寫操作的響應時間比用緩存的寫操作的響應時間要長。必須要注意的是完全的SANCopy是使用512KB的傳輸大小。默認的write-aside的值是2048block或者1MB因而，完全SANCopy的寫默認來說都是有緩存的。多個完全SANCopy的操作可能會加重目標陣列的寫緩存；在這個情況下，write-aside的值可以固定在1023block()或者關閉目標LUN的寫緩存。注意,只有2+1,4+1，和8+1RAID5或者4+1和8+1RAID3的拓撲能在這種情況下得到完全stripe寫的好處，提供沒有LUN綁定的位移。NavishpereCLIgetlun命令可以顯示一個LUN的write-aside的大小。要改變write-aside的大小，使用NavisphereCLIchgluncommand。在兩個SP(存儲控制器之間)取得負載平■衡我們把LUN分布在兩個SP上，以便讓兩個SP上的工作能取得負載均衡；這避免以下這一情景的出現：當一個SP有很多的空余的能力的時候，而另外一個SP卻成為瓶頸。NavisphereAnalyzer可以用來監測負載的不均衡。［施］9.后端設備(磁盤的子系統)［址］B.LUN的分布使用LUN的分布的主要目的在丁:后端總線涉及到一對所有CLARiiON#儲系統都用來訪問硬盤的冗余的光纖loop（一個對應一個SP）。（一些CLARiiON存儲系統有一對后端總線總共4條光纖的loop,有些有4條后端的總線）一個RAID組會分成多個LUN或者說，一個來自丁這樣的一個RAID組的LUN會被分別稱之為分了區的RAID組或者分了區的LUN一個只有一個LUN的RAID組被稱之為專有RAID組或者專有LUN如果要更有效的把I/O分布在光纖硬盤上，把LUN分布在多個RAID組上面。當作LUN的分布的計劃的時候，把LUN的容量歹0個賬目。計算經常要訪問的存儲的容量，并把容量適當的分布在RAID組里。在需要高帶寬的應用里面，應該要小心謹慎的去分布那些涉及到跨越后端loop的LUN以便讓所有后端的loop都能被用到。這有時可能會導致使用多個硬盤柜來組合。例如，一個系統需要在一個擁有8條后端loop的陣歹U（CX3-80或者CX700上使用80個硬盤，那么我們應該需要把磁盤分布在8個磁盤柜以便讓所有的后端的loop都能充分的使用到。另外的，要用兩個SP來實現負載均衡。要來達到這個目的，分配好SP的工作：對每一個LUN的默認的歸屆是專有的，這樣確保了LUN能正常地訪問一個SR當對一個ATA硬盤的RAID組分區的時候，讓所有來自每一個RAID組的所有的LUN被一個單一的SP所擁有。當作MetaLUN勺計劃的時候，注意所有的組成那個metaLUN勺所有LUN勺歸屆權,都會轉交給那個對擁有baseLUN的SP;他們原先默認的歸屆權將會被取代。因而，當作metaLUN的計劃的時候，計劃好SPA和SPB的LUN的資源池，以確保在SP問，所有的LUN的訪問都是負載均衡的。［辿］系統和啟動硬盤的影響在CX系統系統里面，在第一個硬盤柜里的前5塊硬盤，是被作為幾種內部的工作的。作為緩存的系統硬盤0-4塊硬盤是作為緩存的系統硬盤。緩存的系統硬盤在以下情況下會有重大的I/O的改變：當系統關閉了寫緩存的時候（把緩存里面的數據倒入到系統盤里）當系統正在從一個停電中恢復過來（在此期間沒有主機的訪問）當系統盤正在rebuild（發生在系統盤的故障后：硬盤0-4）所有的這些情形都會在一個存儲器故障的時候適用。在主機訪問時發生故障的主要的影響是寫緩存被關閉了。如果寫緩存被關閉了，整體性能會受到影響，主機的寫操作會有一個更加長的相應時間（尤其對RAID5）。而對系統硬盤的訪問（包括讀和寫）速度，都會在把數據倒入系統盤的時候變得緩慢，而且這個dump的過程需要一段時間來完成。因而，一個正在Rebulid的RAID組會非常的繁忙。（如果把Navisphere里的HAVault的選項活除掉，那么影響會降少。在那種情況下，緩存在系統硬盤rebuild的時候仍然保持開啟，代價是失去了對緩存中的數據的一小部分的保護。“TheHAvaultoptionandwritecachebehavior”章節會有更多的細節。）系統硬盤的重建比其他RAID組里的硬盤的重建更加重要，因為系統硬盤是一個校驗保護的區域，所以所有系統硬盤在重建的時候都會非常的繁忙。同時，另外一些到FLAR改據庫和PSM勺系統訪問仍可以繼續。（看以下說明）根據這些實際情況，我們推薦用戶最好不要使用系統硬盤作為響應時間非常重要的數據，包括以下應用：微軟的Exchange數據卷主機啟動卷群集的共享磁盤的卷有較重負載的RDBMS錄表如果系統是小的（30個硬盤或者更小），而用戶也要求使用這些硬盤來作為中等程度到高負載的環境下的話（60I/O每個硬盤或者更大），那么HAVault這個選項應該被活除掉。任何在系統硬盤里的數據LUN在系統硬盤故障之后的寫緩存的重新開啟需要更多時間，這是因為數據的重建。這就意味著在陣列里所有的LUN^P會在一個很長的時間里，忍受著非常糟糕的響應時間。OS的啟動硬盤這前四個硬盤也被用作（存儲控制器的）操作系統的引導和系統的配置。一旦系統開始啟動,FLARES作系統在引導分區很少有操作。所以，使用這些硬盤作為啟動的設備，并不會影響主機的I/O。FLARE數據庫硬盤和PSM前三個硬盤也包含了FLARE勺配置數據庫系統和持久存儲管理器（PSM,這是一個對配置數據的三鏡像的保存。這些硬盤為性能方面做了一些考慮。Navisphere使用PSME那些在軟件升級過程中被用到的數據裝載入緩存之中。在軟件升級過程中的繁重的主機I/O,可能會造成升級過程的中止聯結，所以我們推薦在開始進行軟件升級之前，主機的負載必須減少到每個硬盤100IO/s。因而，在這個三個硬盤里有非常繁重的主機I/O的情況下，會導致Navisphere命令的響應時間。因此，對丁基丁性能計劃的考慮，建議把這些硬盤當作已經有一個LUN指定給他們。主機的I/O性能并不會受系統訪問的影響，但如果這些硬盤已經有很重的負載的時候，可以通過分布數據的訪問來確保Navisphere能得到好的響應時間。［外］使用LUNffiRAID組的編號方式這個建議并不會幫助提高性能，但會幫助你管理好一個設計得很合理的系統。根據你的習慣使用RAID組的編號方式和LUN的編號方式。例如，對LUN進行編號，因而可以讓所有SPA擁有的LUN的編號都是奇數的，而所有SPB擁有的LUN的編號都是偶數的。一種更加有效的方式是使用可預計的RAID組的編號方式，通過在RAID組號碼后面增加數字來編號LUN的號碼。這會更加容易的為metaLUM擇LUNRAID組的號碼包含在LUN里面，會讓你可以從多個RAID組里面來選擇LUN（Table3）例如，如果要選用擴展成FLARELUN10儡號的LUNO定給一個metaLUN選擇編號201和301的LUN因為所有這三個LUN^K屆丁同一個SP（metaLUN的所有組件都會轉移到同跟BaseLUN同屆的一個SP上）。同樣，新的metaLUN101上的所有I/O，都會分布在三個RAID組里面。在Table3里面SP的分配計劃被稱之為AB的歸屆權，因為在每一個RAID組里,LUN交替地分配到SPA和SPB。AB歸屆權對FC和LCFC勺硬盤有充分理由的，因為他們都是真正的擁有雙端口；但這卻非常不適丁ATA硬盤，因為性能會受到ATA硬盤的單端口（多路復用）訪問的嚴重影響，尤其是在高度帶寬要求的應用。（這是一個原則性的原因：在Navisphere管理器里對RAID組的默認歸屆權的交替，是基丁綁定時間，而不是基丁LUN的交替，這也是過去所遵行的情形。）在一個RAID組里的AB歸屆權，并不能保證SP的利用率會得到平■衡，尤其是當LUN分配到主機的操作已經完成特別是沒有考慮預期的工作負載的時候。［外］最小化硬盤的競爭因為硬盤的大小持續的增長，對RAID組分區也變得更加尋常，同時也讓優化硬盤的性能變得更加困難。CLARiiON的設計是非常靈活的，而且可以提供非常好的性能，甚至是在硬盤個數有限的情況下。但是，對丁高性能要求的環境，以下的指導方針是必須遵循的。在生產過程中備份跟生產并發的，要求順序的讀操作（在線備份）的環境，會從RAID1/0的設置里得到非常好的性能，因為讀操作可以分布在非常多的軸里面。在中度的負載如消息應用下，RAID5也可以提供非常好的讀的吞吐量。這些安排應該在部署之前作測試。當備份的時候，保持寫操作充分的利用寫緩存一如果緩存的flushes的優先級提高了，那么會降低讀的訪問速度。保留的LUN資源池和clone的LUN把保留的LUN資源池和將要作snap的源LUN放在同樣的硬盤上，并不明智。寫操作會導致非常高的尋道時間和非常差的性能。同樣的事情也會發生在cloneLUN上面：把cloneLUN和他們要clone的LUN放在不同的硬盤組里面。一般來說，ATA硬盤并不推薦用作保留的LUNK源池和clone的RAID組。當他們工作在一些情形下，他們更差的性能會使他們成為瓶頸，尤其是當源LU思綁定在光線通道的RAID組里面而且主機的寫操作處在一個非常高的速度上。［址］Stripe和Stripeelement的大小stripeelement的大小是128block或者64KB沒有任何的理由來改變它。［外］CLARiiONRAID5的stripe優化有時EMC勺員工會推薦只使用4+1或者8+1的RAID5。這通常是不必要的，而且通常是基丁對CLARiiONRAID技術的不完全的理解。對大部分情形，用來綁定一個要求的硬盤的RAID組的大小，應該是基丁要素，而不是基丁性能。4+1/8+1神奇的主要根據是他們有stripe-write（帶寬）的優化。當整個stripe都被放置到SP的內存，而且校驗是在fly里面計算的時候，校驗的RAID的類型達到了他們最好的性能。這是被稱為FullStripeWrite和常常在應用RAID5時被提及的ModifiedRAID3（MR3。要RAID5實現MR3ffi化的要求，有時候被誤解了。許多EMCW員工相信CLARiiONRAID的優化只在4+1或者8+1模式下有效，而這是錯誤的MR3可以跟任何大小的RAID5硬盤組下使用。當一個I/O正好填充了一個RAID的stripe,MR獄發生了，無論是因為I/O很大而且和stipe對齊，還是順序I/O一直在緩存里面直到他填充了這個tripe。但是，這個步驟仍然有以下的要求：緩存的頁面大小是4K己或者，對丁512KB或者更大的stripe,8KB或者16KBstripe的element大小是64KB（128block）或者更小而且是8的倍數。例如，對丁12+1的RAID5組和一個64KB的stripeelement,stripe的大小是12*64KB=768KR對丁MR3必須使用一個8KB或者更大的緩存頁面大小，這是因為4KB的頁面太小了。［辿］每一個RAID組的硬盤的個數大丁10個硬盤的RAID組會導致以下問題：更長的rebuild時間（校驗RAID）更長的同步時間，因為處理器等待多個設備來完成一個I/O對丁高帶寬，避免使用非常大的硬盤組（大丁10個）因為會有額外的尋道的延遲，因為所有的硬盤必須為同一個特定的I/O對齊。如果非常多的硬盤需要用來滿足一個LUN的性能要求，最好使用更小硬盤組的metaLU釁實現。大的軸的數量跨越許多個硬盤的數據分布，對那些隨機訪問的，而且主機能產生足夠多的并發的I/O來讓硬盤保持滿載的工作負載，是非常有效的。當應用有并發的處理或者線程，或者處理采用同步的I/O,那么高的并發訪問是可以達到。一個大的硬盤的數量可以允許并發的要求來達到獨立性。對丁隨機的和爆發性的工作負載，stipe類型的metaLU說一個理想的方法。由多個RAID組構成的MetaLUNte不同的時間里，都能理想的應對峰值。例如，如果幾個RDBM服務器共享RAID組，導致checkpoint的行為是不能設置成交迭的。［也］I.在一個存儲系統里應該使用多少個硬盤增加硬盤并不能線形地擴展工作負載，這就使性能會像上升后的一個平坦的曲線。這些都會在“sizingthestoragerequirement”里面談及，但以下是嚴謹的最大化性能一些大體的方針。列在Table4里面的硬盤的個數，是在不變的和從中等變為高負載的情形下，為并發的活躍的硬盤而設置的。［址］J.硬盤的類型和大小目前來說，CLARiiON系統可以使用以下的硬盤類型和大小：10000rpm的光纖通道硬盤（73,146,300GB15000rpm的光纖通道硬盤（73,146GB5400rpm的ATA硬盤（320GB7200rpm的SATA硬盤（250,500GB7200rpm的低成本光纖硬盤（500GB硬盤大小的影響盡管硬盤生產廠商都宣稱更新的，更高容量的硬盤可以獲得更高的傳輸率，但在硬盤和主機之間的協議層次，還是會使硬盤