【文章內(nèi)容簡介】 16塊磁盤是SAS磁盤的默認RAID Group Size（缺省為16），可在性能和數(shù)據(jù)安全性方面得到良好的平衡，因此Aggregate的RAID Group Size采用默認的16，創(chuàng)建Aggregate時磁盤總數(shù)盡量接近16的倍數(shù)。n 在Active控制器中，考慮性能和容量滿足的前提下，設(shè)置盡可能多的熱備份盤（本次設(shè)置4塊熱備份盤），以備將來根據(jù)各Aggregate的需求來使用熱備份盤擴容。n 在Standby控制器中為了節(jié)省空間，只使用最少3塊磁盤創(chuàng)建1個Root Aggregate，并僅僅用于存放Data ONTAP操作系統(tǒng)的Root Volume（根卷）。n 在Standby控制器中為了節(jié)省空間，只預(yù)留1塊HotSpare Disk（熱備磁盤）。 NetApp存儲的Volume設(shè)計原則在NetApp的最佳實踐里，我們推薦LUN所在的FlexVol的尺寸是LUN的2倍大小，這其實是與Volume的Fractional Reserve機制有著密切關(guān)系，這完全是出于NetApp快照空間預(yù)留和LUN Overwrite而考慮的。圖45. NetApp推薦的LUN所在的Volume容量布局NetApp建議在部署Thin Provisioning模式的LUN的同時，也對LUN所在的FlexVol啟用重復(fù)數(shù)據(jù)刪除功能，并將這些LUN以1對1的方式（一個FlexVol內(nèi)只包含一個LUN）部署到同樣采用Thin Provision配置、。通過以這種方式部署LUN，F(xiàn)lexVol將僅僅充當一個配額（Quota）的作用，而LUN所實際占用的存儲量會在FlexVol卷和包含它的Aggregate中所呈現(xiàn)。因此，我們推薦在NetApp存儲環(huán)境中，LUN所在的Volume尺寸也不要太大。若您考慮使用2TB的LUN，那么我們則推薦LUN所在的FlexVol尺寸為4TB即可，并且FlexVol也配置為Thin Provision模式即可。 各應(yīng)用程序類型對存儲I/O需求的通用參考在設(shè)計存儲解決方案階段，了解放置在共享存儲上的虛擬機I/O需求是至關(guān)重要的，I/O配置文件是應(yīng)用程序和服務(wù)器I/O模式的描述。某些應(yīng)用程序可能是側(cè)重于讀取操作，而有些應(yīng)用程序可能是側(cè)重于寫入操作，并且每種應(yīng)用程序有著不同的順序或隨機讀取比例。下列表格中所描述的不同應(yīng)用程序?qū)?yīng)的I/O大小、讀寫比例、隨機和順序比例。表格中的比例為一個通用的參考值，比例接近真實各種應(yīng)用的I/O類型。但不能包含全部的應(yīng)用類型，因為根據(jù)不同生產(chǎn)環(huán)境，數(shù)值也會有很大的差異，這里的數(shù)據(jù)僅作為參考。表44 . 存儲I/O需求的通用參考應(yīng)用類型I/O大小讀寫比例隨機與順序讀寫比例Web Server4KB、8KB、64KB95%讀取 / 5%寫入75%隨機 / 25%順序Web Server Log8KB100%寫入100%順序OS Paging64KB90%讀取 / 10%寫入100%順序Exchange Server4KB67%讀取 / 33%寫入100%隨機Workstation8KB80%讀取 / 20%寫入80%隨機 / 20%順序Media Streaming64KB98%讀取 / 2%寫入100%順序OLTP – Data8KB70%讀取 / 30%寫入100%隨機OLTP – Log512bytes – 64KB100%寫入100%順序根據(jù)客戶所提供的歷史性能信息，評估出Application Server類型的虛擬機需要大約175個IOPS。表45 . 不同應(yīng)用類型的虛擬機IOPS需求虛擬機類型%Read%Write平均IOPSRAID寫入懲罰I/O配置文件Application Server（Oracle WebLogic）60%40%175 IOPS2 IOPS245 IOPSOLTP（Oracle Database）70%30%1200 IOPS2 IOPS1560 IOPS我們假設(shè)每臺Application Server類型的虛擬機潛在的平均I/O需求以175個IOPS來計算。根據(jù)客戶所提供的Read/Write比率分析，Application Server類型的虛擬機通常是60%的讀取操作，40%的寫入操作。表 46. 各種RAID類型的寫入懲罰值RAID類型RAID寫懲罰RAID01RAID12RAID54RAID66RAIDDP（NetApp專用）2RAID102當使用RAIDDP時，這將導(dǎo)致每臺虛擬機產(chǎn)生如下的IOPS需求，考慮到RAIDDP的RAID懲罰，由于每次寫入操作，會導(dǎo)致奇偶校驗必須被寫入到兩個校驗磁盤中，因此懲罰值為2。表47. IOPS需求計算公式IOPS需求計算公式：IOPS Requirements Pre VM =（Total IOPS%Read）+（（Total IOPS%Write）RAID Penalty）虛擬機類型IOPS需求：Application Server（Oracle WebLogic）（17560%）+（（17540%）2）（105）+（（70）2）105 + 140 = 245（約等于245個IOPS）OLTP（Oracle Database）（120060%）+（（120040%）2）（840）+（（360）2）840 + 720 = 1560（約等于1560個IOPS）通過計算得出的結(jié)論是，若我們假設(shè)定義單臺Application Server類型的虛擬機需要175個IOPS的話，在存儲上實際需要產(chǎn)生約245個IOPS才能滿足該虛擬機的I/O需求，而OLTP 類型的虛擬機若需要1200個IOPS的話，在存儲上實際需要產(chǎn)生約1560個IOPS才能滿足該虛擬機的I/O需求。從性能的角度而言，該配置文件的計算方式和結(jié)果將與NetApp顧問進行了深入討論，確定出一個最優(yōu)的策略。 Datastore的容量需求估算：下列表格提供了所觀察到的被候選為虛擬化的物理主機所實際消耗的存儲容量信息。表 43. 虛擬機存儲容量配置文件AVG C:\ SIZE（GB）AVG C:\ USED（GB）AVG “OTHER”:\ SIZE（GB）AVG “OTHER”:\ USED（GB）40GB100GB在這種情況下，平均每臺Application Server類型的虛擬機的存儲容量需求大約為50GB左右（C盤驅(qū)或“/”，）。我們假設(shè)每臺虛擬機平均需要50GB的存儲容量，并且虛擬機配置為8GB Memory的情況下，在這種情況下您可以通過計算的虛擬機實際所需磁盤空間消耗，估算出每個Datastore所能容納的虛擬機數(shù)量（虛擬內(nèi)存占用vSWAP 空間容量后面有闡述）。之前我們已經(jīng)定義過每個Datastore的Size為2TB，這就意味著約等于2048GB，計算公式如下：LUN容納虛擬機數(shù)量計算公式：LUN Size 247。每臺虛擬機實際所需磁盤空間消耗 = 每個 Datastore 所能夠容納的虛擬機數(shù)量2048GB 247。 50GB ≈ 40 Datastore的IOPS需求估算：考慮到每個Datastore最多提供40臺虛擬機的運行，這需要每個Datastore必須能夠提供至少9800個IOPS，計算公式如下：表 49. DataStore 的IOPS 每LUN所需的IOPS計算公式：每個 Datastore 所能夠容納的虛擬機數(shù)量每個臺虛擬機實際IOPS消耗 = 每個 Datastore 所需的IOPS數(shù)量35臺245 IOPS =9800 IOPS根據(jù)估算，一塊15K RPM的磁盤可以具有175 IOPS，而一塊10K RPM的磁盤大約能具有125 IOPS。出于性能和安全性的考慮，NetApp對SAS磁盤的RAID Group Size默認定義為16塊磁盤，DataStore需要 SAS磁盤數(shù)量才可滿足IOPS需求，計算公式如下：9800IOPS 247。125 IOPS ≈ 79塊10K RPM的SAS磁盤因此，建議每臺NetApp存儲控制器將配置具有512GB的Flash Cache緩存模塊（PAM II），從而減輕磁盤的讀取任務(wù)I/O壓力，并提高讀取響應(yīng)時間，以滿足vSphere環(huán)境中的磁盤I/O需求。 存儲設(shè)計要點創(chuàng)建虛擬機時，在Datastore中所自動創(chuàng)建出的目錄被稱為“虛擬機主目錄”。默認情況下，虛擬機的所有組成文件都放置于虛擬機主目錄內(nèi)。主目錄包括虛擬機的配置文件，虛擬磁盤和虛擬描述符文件，以及VMKernel交換文件，快照文件，NVREM等等。每當虛擬機一旦被啟動時，就會通過VMKernel自動創(chuàng)建出每臺虛擬機所需的vSWAP文件。默認情況下，vSWAP文件的大小是等同于每臺虛擬機所配置的虛擬內(nèi)存大小。由于vSWAP是用于存放臨時性內(nèi)存交互數(shù)據(jù)的，無論是從備份副本恢復(fù)虛擬機，還是使用的Site Recovery Manager進行災(zāi)難恢復(fù)，NetApp都推薦將每臺虛擬機的vSWAP文件從虛擬機的主目錄中重新定向到一個單獨的Datastore上。因此，我們推薦所有虛擬機的vSWAP文件應(yīng)統(tǒng)一放置在一個單獨的共享Datastore上。圖46. NetApp推薦的虛擬機vSWAP文件布局如圖所示出，這種虛擬機的文件布局圖。其先決條件是在NetApp存儲上創(chuàng)建一個專門用于存放虛擬機vSWAP文件的Datastoe。因為VMware的vSWAP文件對于存儲的需求是動態(tài)的，所以NetApp的建議是創(chuàng)建一個自動精簡配置的LUN或啟用了卷自動增長功能的FlexVol。當用于存放vSWAP文件時，自動精簡配置的LUN和自動增長的FlexVol卷，提供了非常高的性價比。這種設(shè)計避免了經(jīng)常需要對vSWAP存儲空間的變化調(diào)整，并且減少了存儲的使用率。如果您的交換空間過小，虛擬機將會無法啟動。相反，如果交換空間過大，將會導(dǎo)致存儲空間的浪費。整個vSphere Cluster將使用一個單獨的Datastore用于存儲所有虛擬機的vSWAP文件。 NetApp并沒有建議將每臺ESXi主機的Local Datastore作為虛擬機vSWAP的存儲空間，因為這種配置方式可能會給虛擬機的vMotion帶來的負面影響，例如導(dǎo)致遷移時間過長等問題。在屏幕的右側(cè)的數(shù)字描繪了簡單的VMKernel交換vCenter Server中配置一個中央數(shù)據(jù)存儲，虛擬機的vSWAP文件都被指定放置到一個單獨的共享存儲上，但是與虛擬機的主目錄是分離的。這樣的優(yōu)勢是能夠增加虛擬機的vMotion速度、增強虛擬機的備份速度，因為SWAP文件不會被備份，由此也能帶來節(jié)省備份成本的優(yōu)勢。表410. 關(guān)于vSWAP文件布局方式的對比優(yōu)/略勢NonDedicatedDedicatedLocal優(yōu)勢：可提高vMotion速度?？商岣遶Motion速度。可減少存儲復(fù)制帶寬需求?？蓽p少存儲復(fù)制帶寬需求。略勢：增加存儲復(fù)制帶寬需求?？赡軙黾宇~外的管理成本。增加存儲復(fù)制帶寬需求。可能會增加額外的管理成本。通過對比，最終我們還是推薦農(nóng)銀人壽考慮單獨劃分出一個專屬（Dedicated）用于存放虛擬機vSWAP文件的Datastore，以提高虛擬機的vMotion速度，并降低存儲在執(zhí)行容災(zāi)復(fù)制過程中對網(wǎng)絡(luò)帶寬的需求。 虛擬化存儲設(shè)計 隨著業(yè)務(wù)和公司發(fā)展的不斷壯大，應(yīng)用系統(tǒng)等不斷增加，對存儲的需求成指數(shù)上升。根據(jù)預(yù)測，未來兩年對存儲的需求增長為每年41%。同時，存儲面臨多重挑戰(zhàn)：首當其沖的就是如何在滿足不斷激增的應(yīng)用和存儲需求的同時，滿足客戶的SLA。其后，是故障排除和數(shù)據(jù)遷移過于復(fù)雜。如何在更少的時間應(yīng)用更少的成本滿足業(yè)務(wù)部門的SLA需要，在不失策略控制的前提下，簡化、自動化管理流程，成為企業(yè)IT部門在存儲領(lǐng)域的關(guān)切點。以前，存儲都是在項目開始階段配置和部署的，在其生命周期中不再更改。如果要求更改虛擬機所利用的 LUN 或卷的某些方面或功能，則在許多情況下，需要刪除原始 LUN 或卷并創(chuàng)建具有所需功能的新卷。這是 一項干擾性很強且非常耗時的操作，可能需要花費數(shù)周的時間進行協(xié)調(diào)。 圖：存儲壓力來源 存儲面臨挑戰(zhàn)第一個挑戰(zhàn)是管理復(fù)雜、不靈活。存儲一直是虛擬化架構(gòu)設(shè)計中最關(guān)鍵的環(huán)節(jié)之一。很多性能的問題都和存儲有關(guān)。虛擬化架構(gòu)師需要了解很底層的存儲設(shè)備及其特性，需要在IOPS，Latency和容量等各個方面優(yōu)化。另外存儲的分層、擴展和運維都有很多考慮的方面。在引入軟件定義的存儲以前，存儲都是在項目開始階段配置和部署的，在其生命周期中不再更改。如果要求更改虛擬機所利用的LUN或卷的某些方面或功能，則在許多情況下，需要刪除原始LUN或卷并創(chuàng)建具有所需功能的新卷。這是一項干擾性很強且非常耗時的操作，可能需要花費數(shù)周的時間進行協(xié)調(diào)。第二個挑戰(zhàn)是費用昂貴。如果數(shù)據(jù)量很大，特別是用存儲光纖網(wǎng)絡(luò)（SAN）的情況下，那是虛擬化平臺燒錢的很大一塊，平庸的存儲設(shè)計看起來四平八穩(wěn)循規(guī)蹈矩，殊不知可能會在存儲上開銷很大。第三個挑戰(zhàn)是無法確保差異化服務(wù)等級。由于數(shù)據(jù)存儲選擇LUN時并不考慮每個虛擬機的性能和可用性要求，因此難以在存儲方面保證SLA。在每個卷中包含多個VMDK的情況下，很難排除性能問題。虛擬環(huán)境的數(shù)據(jù)中心，要求存儲能夠提供新的特征：l 提供虛擬機精確控制l 在應(yīng)用高度整合的情況下滿足性能要求l 提供與vSphere相同級別的應(yīng)用和數(shù)據(jù)移動性l 支持快速調(diào)配零停機操作l 按需動態(tài)擴展l 支持VDI和大數(shù)據(jù)等新應(yīng)用這些新特性是傳統(tǒng)的存儲所不能滿足的，因此軟件定義的存儲應(yīng)運而生。它從前文提及的三個維度解決虛擬化數(shù)據(jù)中心面臨的問題和挑戰(zhàn)：簡化存儲的管理、降低總擁有成本、實現(xiàn)端到端的SLA交付。 虛擬存儲設(shè)計Virtual SAN利用多個服務(wù)器的本地存儲構(gòu)建成一個共享的分布式數(shù)據(jù)