Q：PowerFlex文件功能是"原生内嵌"还是NAS网关，其规模有多大？
Q：NVMe/TCP的好处是什么、它又有哪些限制？
注：我不是PowerFlex、分布式存储方面的专家，下文中如有错误，恳请大家批评指正。
分布式存储性能已过剩？
提到PowerFlex我自然想到其前身，也就是EMC在2013年收购的ScaleIO。5年前我还写过下面这两篇：
《为什么ScaleIO和VSAN不要求三副本？》
《温故知新：ScaleIOOracle性能测试解析》
本文我想跟大家聊聊新发布功能中的技术干货，也就是《DellTechnologiesWorld2022–,AHigh-leveloverview》这篇博客的学习笔记。（链接见文末）
从ScaleIO到PowerFlex，一直以高性能、高恢复速度（Rebuild重构快）为特点。早年我列出的性能数字，还是在40Gb/s网络和PCIeSSD的初期阶段（每节点1块SLCPCIe闪存卡+6个cMLCSATASSD），如今的硬件包括CPU计算性能早已不可同日而语。当然今天我的重点不是写性能，只想先列出6个9可用性相关的2个测试示例：
-Example:在一个14节点的存储池内失败一个750GBSSD，需要重建344GB数据，Rebuild时间75秒（4.58GB/s）；
-Example:在SSD池内失败一个节点需要重建2.1TB数据，（剩余）13节点贡献rebuild。完成rebuild时间261秒(4分21秒，8.23GB/s)
SDNAS：容器化集群NAS网关
图片点开后可放大，以下同
在今年将会到来的版本中，新的文件存储功能也被称为SDNAS（软件定义的NAS）。在PowerFlex原有的块存储服务基础上，增加了NFS/SMB文件协议的支持。
PerformanceandScale:TransactionaldatabasesandtraditionalNASworkloads（针对交易型数据库和传统NAS工作负载）
HighAvailability:30secondstarget（高可用30秒切换目标）
FaultToleranceResiliency:LACPBonds（故障切换弹性：LACP聚合绑定）
FileMaintenancemode:Newmaintenancemodeforserviceabilityoperation（文件维护模式，用于服务操作）
ManagementandMonitoring:UIandRESTAPI,CloudIQIntegration,SNMPv2/v3support（管理和监控）
NVMeoverFabric(TCP)–在当前基于agent的SDC访问模式基础上，加入NVMe/TCP前端标准块存储协议支持。
如上图，SDT指的就是运行在PowerFlexSDS数据服务节点上的NVMe/TCPTarget。
而NASServer则是指专用的SDNAS节点（2-16个），形成一个PowerFlex文件服务集群。如下图：
上面是个典型的、在分布式块存储前端添加集群NAS网关的架构。每个NAS服务器节点用SDC访问PowerFlex的SDS后端块存储，然后运行NAS容器提供文件服务。
面对前端的应用主机访问，NAS节点除了提供Pri/Sec主备访问路径之外，我想容器化的另一个好处就是易于部署、伸缩。据了解，Dell的PowerStoreT系列统一存储的文件功能应该也是基于容器实现的。（扩展阅读：《DellEMCPowerStore详解：NVMe+SAS全闪存阵列，还是一体机？》）
关于NAS具体的支持特性，我直接把英文描述粘贴过来了。
NASnodes
DedicatednodestohosttheNAScontainers
PowerFlexApplianceandRacktousePowerEdgeR650-basedNASnodes（基于R650服务器的NAS节点）
NAScluster
TherewillbeoneNASclusterperPowerFlexsystem(MDM-cluster)
AnNASclustercanhave2-16physicalNASnodes
StoragePools
EveryProtectionDomainwillhaveaStoragePooldedicatedforNAS
SPtohouseNASconfigurationvolumesfor“NASServers”
SPcanalsobeusedforuserfilesystems
‘NASServer’
Alogicalconstructthatprovidesdatasegregation
A“NASServer”hostsmultipleFileSystems
NASServerconfigurationvolumeswillbethinprovisioned
FileSystems
Boundtoit’sparent“NASServer”
Servedbyasingle,dedicatedPowerFlex(block)volumeandistransparenttotheuser
UserfilesystemsbenefitfromthefullperformanceanddataresiliencyofPowerFlexblockvolumes
Supportedprotocols（协议支持）
NFSandSMBsupport(NFSv3andv4,SMBv2andv3)
FTPandSFTP
FileSystemOperations
UserquotasandTreeQuotas
Ext/shrinkfilesystem(spacereclaim)
Filesystemread/writesnapshots（可读/写快照）
Workloads
TransactionaldatabasesandTraditionalNASworkloads
DataReduction
InlineCompression（线内压缩，PowerFlex当前就支持块存储的压缩）
ManagementandMonitoring
UIandRESTAPI
CloudIQIntegration
SNMPv2andv3support
DataProtection
3-wayNDMPsupportforbackup（NDMP备份）
Security
CAVA(CommonAntivirusAgentforSMBclients)
D@REwithCloudLink
Serviceability
SRS/ESE(CallHome)
Alerts
Datacollectionaka“nativeauditlog”
SDC专用客户端与NVMe/TCP标准协议
传统的PowerFlex块存储访问如上图，在每一台应用服务器上运行SDCagent客户端，来访问SDS存储节点，中间的网络是基于TCP的。SDC支持的操作系统包括VMwareESXi、Windows、AIX和众多Linux发行版。如果SDC和SDS部署在同一个物理服务器上，那样就是HCI超融合的形态。
引入NVMe/TCP的最大好处，就是可以使用主流Linux发行版和ESXi中已经可用的标准NVMe/TCP系统内置驱动。
扩展阅读：《NVMe-oF：基于IP的NVMeSAN自动化发现存储网络》（当初这篇涉及到的还是集中存储阵列用的）
《VMwareNVMe支持：及未来展望》
如同前面那张NAS示意图，PowerFlexNVMe/TCP主机连接性也画的很实在。在每个SDS存储节点上跑一个SDT，这样前端的ESXi等主机就可以用NVMe/TCP标准协议来访问了。Dell同时还说明了以下2点：
-SDC保持更快和更低的延时，因为NVMe/TCP部署在网络上增加了“一跳”（原文：SDCremainsfasterwithlowerlatencyasNVMe/TCPimplementationaddanothernetworkhop）。
-NVMe/TCP与SDC共存，但不能共享相同的卷（can'tsharesamevolumes）。
根据我的理解，Ceph等分布式存储在支持iSCSI等标准协议时，也要面对类似的情况。
PowerFlexNVMe/TCP部署当前支持的操作系统包括：,,SLES15SP3,。可以不用专用kerneldriver（SDC）了。
如上图，左边示例中的浅绿色箭头为SDC协议数据访问路径，它能够感知卷数据的分布并发送IO到“正确的”SDS。
中间示例的紫色箭头代表NVMe-oF协议路径，ESXi等主机上的Initiator发送IO到某一个SDT，然后SDT与不在同一服务器节点上的SDS(2)之间还要使用SDC协议（绿色箭头），所以说增加了一跳（usinganadditionalnetworkhoptofindthe“right”SDS）。
右边的Host-basedSDT应该是未来的计划。把SDT跑在ESXi主机上的一个VM里，这样NVMe-oF协议只是经过虚拟网络不出节点，一方面SDT不像以前SDC那样“侵入”ESXi内核，同时SDT到目标SDS之间还能使用ESXi的PVRDMA来进一步降低延时。
感觉在VMware环境中Host-basedSDT后续可能会替代当前的SDC，我理解SDC针对每一个ESXi版本都要做适配。
更多关于–UnifiedManagement统一管理等内容，由于时间所限我就不讨论了，有兴趣的朋友可以访问以下原文链接。
参考资料
注：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎在留言中批评指正。如果您想在这个公众号上分享自己的技术干货，也欢迎联系我：）
尊重知识，转载时请保留全文。感谢您的阅读和支持！
