存儲極客
這是一群存儲偏執狂
為存儲而生，跟存儲死磕
各具獨家秘笈
有觀點，有碰撞，有干貨
從8月18起
做客存儲極客欄目
與你分享存儲里的那點事兒
大家都知道，在傳統的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仿真扇區大小。
上表列出了3種硬盤扇區格式類型。512n——物理格式化和向主機呈現的邏輯扇區字節數均為512byte，早期的硬盤都是這樣；512e——物理扇區大小為4096字節，邏輯上仿真為（8個）512字節扇區，為了兼容性的一種過渡；4Kn——即原生4KB，物理和邏輯扇區字節數都是4KB。
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高級格式化、路線圖
原生512n每個扇區都有50bytes的ECC糾錯碼；4KB扇區將這個ECC區域合并、擴大（但沒有50bytes的8倍那么大），并省去了間隔、地址標記等空間，因此格式化效率提升到大約97%，并且能否檢測和糾正更大的介質錯誤。
也就是說，在磁記錄密度不變的情況下，“高級格式化”能夠提供更大的實際可用容量。隨著硬盤上的記錄單元——磁極尺寸不斷縮小，容量增速放緩，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）之前的操作系統，并且與上文中我們介紹的生態系統密切相關。
物理、VMware虛擬機環境的“對齊/非對齊”寫入
這一段的幾張截圖來自IBM的一份文檔，其中“Misaligned”和“Aligned”分別表示在使用512e硬盤時非對齊和對齊的4KB I/O塊操作。由于4KB塊（比如對應文件系統的頁面）操作需要先以8個512bytes邏輯扇區寫入到硬盤，再合并記錄到4KB物理扇區，在非對齊的情況下，一個4KB邏輯寫I/O對應到2個物理磁盤扇區，如果是新寫入就會產生2次I/O；若是改寫之前物理扇區中的數據，則需要讀-更改-寫的操作，這種非原子寫入（non-atomic）最多可能產生4次I/O。
而對齊的情況則簡單多了，盡管中間要經過硬盤模擬512bytes扇區的過程，但每個4KB的I/O操作都是對應到一個物理扇區。屬于比較理想的情況。
我們參考下這個表格里不同操作系統對高級格式化的感知情況。其中，Windows從Server 2008開始能夠感知512e硬盤并自動對齊分區；Server 2012進一步加入了對原生4Kn設備的支持。RHEL 6可以感知512e和4Kn硬盤并能自動對齊；SLES 11能感知512e和4Kn硬盤卻無法自動對齊？VMware ESXi 4.x和5.x都無法感知512e和4Kn硬盤，但支持自動分區對齊。這里有必要進一步解釋下。
首先對于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官方支持。
上圖截自VMware網站，供大家參考
這張圖演示了在虛擬化環境下對齊和非對齊分區的情況。當“Aligned”對齊時，在Hypervisor層VMFS-5的文件塊大小統一為1MB，子塊（Sub-Blocks）大小8KB正好對應2個物理扇區上的16個邏輯扇區。此時如果虛擬機的OS block正好與VMFS子塊對齊的話，等于就是與物理磁盤扇區對齊了，這樣還算好一些的情況。
而對于“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扇區支持
如上圖，左邊是比較早的戴爾服務器SAS RAID卡、HBA、主板集成軟RAID和MD家族陣列控制器。它們能夠支持512e仿真扇區的硬盤，對于較早的操作系統可能需要補丁、對齊工具（比如讓NTFS文件系統的簇與物理扇區對齊）和驅動更新。
對于這些傳統磁盤控制器，對上層主機呈現的LUN（邏輯盤）都是512byte扇區。
到了新一代的PERC 9、MD38xx陣列控制器，以及未來的服務器軟件RAID，已經能夠支持原生4K扇區硬盤，并提供給主機4K格式的LUN。有同行朋友說這樣做在一些場景下有性能的改善，也聽到有專家說微乎其微。而我們想提醒大家的是：在選擇這種“前衛”的配置之前，部分存儲產品已經做好了準備，但上層軟件兼容性需要用戶自己注意，參考包括本文在內的資料，征詢工程師/技術顧問的建議，必要情況下進行測試。
如上圖，這臺戴爾服務器配置了PERC 9系列RAID卡中的H730P Mini，它識別到當前選定SAS硬盤的物理和邏輯扇區大小都是512Byte。
組建RAID之后的虛擬邏輯盤（LUN），自然也是512Byte扇區格式。當您閱讀本文到這里，在此機器上如果換成512e或者4Kn的硬盤，會產生什么樣的結果、有哪些注意事項就比較清楚了吧？
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硬盤。
京公網安備 11010502049343號