存儲極客 | 4KB扇區硬盤來了，RAID、VMware兼容不？
大家都知道，在傳統的PC架構中基本的I/O單元——磁盤扇區大小是512byte(字節)。時至今日，4KB扇區硬盤已經在消費級市場廣泛應用，那么企業存儲的情況如何呢?物理4KB扇區還需要模擬成512byte嗎?
圍繞4KB扇區硬盤，由于大家在這方面了解的基礎不同。可能會有如下的疑問：
1、為什么會有4KB扇區硬盤?好處在哪里?2、原生4KB扇區和模擬512byte，兼容性有什么差別?3、4KB扇區對性能的影響4、軟硬件生態系統，需要做哪些配合?5、SSD目前主要還是仿真磁盤塊設備來使用，它是512byte還是4KB設備呢?6、在RAID陣列和虛擬機環境，硬件與Guest OS之間多了一個抽象層，這是否也會影響到4KB兼容?
以上6點相互關聯，因此在本文中都會有所涉及。首先引起我們注意的是，近日有一份來自戴爾的資料，其中提到了2.5” 2TB 7.2K NLSAS(近線SAS)HDD的引入，這款硬盤采用的是512byte仿真扇區大小。
4KB扇區硬盤與生態系統概述
由于IT棧中的組件默認針對512b扇區大小已經30年了，下面我們來看看針對4KB扇區硬盤，整個生態系統需要分析/升級的地方。
➤ 服務器BIOS/UEFI – 支持4K可能需要UEFI – 傳統BIOS需要修改來增加針對4KB原生驅動器的支持。
➤ 存儲控制器(HBA)– 驅動和firmware需要改變。
➤ RAID stack(位于RAID卡和陣列控制器)–驅動和firmware需要改變。
➤ OS stack – 操作系統必須是4K感知才能使用4K原生驅動器;512e驅動器對于許多組件都支持，但是扇區對齊決定了獲得***性能。
➤ 文件系統 – 基于不同OS版本，這里可能有一些問題。微軟對NTFS 做了一些改動，針對在Windows 7/2008 R2中支持512e。
➤應用 – 需要理解那些進行unbuffered(未緩沖)寫入的應用。
➤ Hypervisors – 512e可以被用于當前的微軟/VMware hypervisors(性能可能變差)，但 VHD 1.0是硬性編碼到512 byte并且沒有當前的hypervisor支持4K原生 – 必須支持VHD 2.0規范來獲得4K原生支持。
➤ 開發工具 – 分區對齊對于在512e 驅動器上達到***性能是個關鍵。4K原生– 還沒有數據來理解開發方面的問題。
什么是4KB高級格式化、路線圖
也就是說，在磁記錄密度不變的情況下，“高級格式化”能夠提供更大的實際可用容量。隨著硬盤上的記錄單元——磁極尺寸不斷縮小，容量增速放緩，4KB扇區是未來大容量硬盤的趨勢。
參考上圖，512byte原生扇區硬盤的生命周期將在2017年終止(部分企業級產品和老型號可能例外)。按照這個之前的預計，以3.5” 7200轉為例***是4TB，超出該容量物理扇區只有4KB了?實際上我們看到有硬盤廠商推出6TB 512byte物理扇區的型號，包括密封充氦7碟片和非充氦普通6碟片，但繼續增大容量還是需要4KB扇區。
4KB扇區仿真512byte已經廣泛應用于客戶端，畢竟即使出現寫放大或者未對齊寫入產生更多I/O，PC用戶對磁盤性能也沒有那么敏感，但企業級應用則要保守多了。除了4KB扇區仿真512byte，原生4KB扇區硬盤直到2014年晚期才發布針對企業級市場的版本，它無法工作在Windows Server 8(2012)之前的操作系統，并且與上文中我們介紹的生態系統密切相關。
而對齊的情況則簡單多了，盡管中間要經過硬盤模擬512bytes扇區的過程，但每個4KB的I/O操作都是對應到一個物理扇區。屬于比較理想的情況。
首先對于Windows Server 2003、RHEL 5和SLES 10來說，512e硬盤首先是可以用的，只是操作系統“意識不到”而當成512n來用了。微軟如今已經停止了對Server 2003的支持(戴爾等廠商為用戶提供遷移方案和服務)，如果我們在這些較早的操作系統上使用第三方分區工具，或者手動指定開始扇區建立對齊的分區，應該可以規避一部分性能影響。
對于4Kn來說，這三款操作系統應該就沒有辦法兼容了，同樣的還有VMware ESXi 4.x和5.x。盡管，VMware Hypervisor支持自動分區對齊(VMFS-3和VMFS-5分別以第128和2048為起始扇區)，但目前的ESXi 6.0和VSAN版本還是無法感知512e和4Kn，其中512e硬盤由于潛在性能問題而不被VMware官方支持。
而對于“Misaligned”未對齊配置，如果要寫入到虛擬機中的OS block 1，有2個VMFS子塊被寫入，并且每個子塊需要2次讀-修改-寫周期(指改寫而不是寫入空白塊，因為每半個VMFS block在“錯位”情況下也會對應到2個物理扇區)。這樣就有可能在底層產生8次I/O?
我們在VMware網站查詢了更多關于4KB扇區兼容的情況，這方面應該還在遙遠一些的Roadmap中。畢竟對于Hypervisor而言廣泛的向后兼容性相當重要，512e我覺得將來會支持，而如果上層虛擬機就是要在4Kn硬盤上進行512byte的磁盤I/O，軟件廠商沒義務去做這個轉換啊。
既然VMware如此，估計KVM和Xen的情況也不會好多少，對此我了解有限就不班門弄斧了。而Hyper-V可能是個特例吧，因為微軟虛擬化平臺上跑Windows虛擬機比較多，那么用VHD 2.0規范的4K原生磁盤格式運行Server 2012虛擬機應該不會出問題。
“對齊”并不代表性能就完全達到512n的水平，如果是小于4KB的隨機寫入512e硬盤還是會產生寫放大或者懲罰。上面的軟件兼容情況也適用于RAID卡和磁盤陣列的LUN，因為操作系統和虛擬機HyperVisor對它們是與本地磁盤同樣的方式來看待。下面我們再來談一下磁盤控制器對4KB扇區的兼容支持情況。
PERC卡和MD控制器的4KB扇區支持
對于這些傳統磁盤控制器，對上層主機呈現的LUN(邏輯盤)都是512byte扇區。
到了新一代的PERC 9、MD38xx陣列控制器，以及未來的服務器軟件RAID，已經能夠支持原生4K扇區硬盤，并提供給主機4K格式的LUN。有同行朋友說這樣做在一些場景下有性能的改善，也聽到有專家說微乎其微。而我們想提醒大家的是：在選擇這種“前衛”的配置之前，部分存儲產品已經做好了準備，但上層軟件兼容性需要用戶自己注意，參考包括本文在內的資料，征詢工程師/技術顧問的建議，必要情況下進行測試。
SSD的“扇區”是多大?
這里也要提一句SSD，據我們了解目前大多數的SAS/SATA SSD，在RAID卡和磁盤控制器管理程序中顯示的物理和邏輯扇區大小都是512Byte，同樣是兼容性考慮。其實閃存的最小寫入單元——頁面大小目前一般為4KB或者8KB，那么“扇區”也都是模擬出來的。測試反映這種模擬對性能的影響不大，因為FTL的存在，數據在SSD上的邏輯地址與物理閃存位置的對應關系都是可變的，來自主機小于4KB的寫入也可能會合并到一個閃存頁面上。
PCIe SSD(閃存卡)的情況不太一樣，有些廠商在出貨時“格式化”為4KB扇區，如果遇到軟件應用不兼容的情況(比如Oracle數據庫等)，可以使用專門的工具轉換格式為512byte扇區大小。
當存儲虛擬化網關遇上“4KB LUN”
從前端到后端都呈現4KB也許會在未來某個時候流行。而對于存儲控制器而言，使用原生4KB扇區硬盤，卻向上給主機呈現512byte的LUN單從技術實現上看卻也可行，只要您不在乎性能打折扣——小于4KB的IO都會被放大至一個硬盤扇區，一次下發8個512byte寫請求也可能會落到2個4KB扇區上(如果文件系統/應用層未對齊的話)。
這就是在控制器層面的“欺騙”，之前講的512e是在硬盤層面上“欺騙”。
欺騙一詞，用在這里并不是貶義。RAID技術本身就是將一組硬盤“虛擬化”為一塊盤呈現給主機。由此我們還聯想到被戲稱為“上騙主機，下騙陣列”的存儲虛擬化設備，它們與RAID控制器***的不同就是其后端管理的存儲單元由磁盤/SSD變成了陣列的LUN。
存儲虛擬化對于后端陣列表現為“主機”，而在前端主機看來它又是一臺“陣列”，基本原理可以簡單解釋為用Initiator導入LUN，再將其用Target導出給主機，中間可選加入數據服務。目前我們還沒留意到有存儲虛擬化產品宣稱兼容4KB扇區格式的LUN?這一點在技術上實現估計并不是太難，關鍵取決于兼容性測試的工作量，以及實際的需求。
舉例來說，一些存儲虛擬化產品根據設置會在后端設備的LUN上再做一次條帶化，以前都是按照512byte扇區來考慮，數據切塊大小可以直接按一定數量扇區來計算就行。而如果扇區大小變成4KB，要是繼續保持原有扇區數的話就意味著“條帶”增大了8倍。對于導出給前端主機的LUN容量，也會存在類似的問題。
總結硬盤廠商對4KB扇區支持的動力毋庸置疑，但在邏輯上是否繼續模擬512byte則取決于生態系統的進展。
對于企業存儲而言，由于一些傳統應用(如：Oracle數據庫)的I/O操作最小單位仍小于4KB，使用原生512byte扇區硬盤可以保證***的性能;模擬512byte能夠兼容，但容易產生性能影響;至于原生4KB硬盤，則要求文件系統、卷管理器具備相應的支持，否則會報錯。
目前一些比較新的服務器、磁盤陣列上的存儲控制器，已經能夠兼容原生4KB硬盤。
