Q：PowerFlex文件功能是"原生内嵌"还是NAS网关，其规模有多大？
Q：NVMe/TCP的好处是什么、它又有哪些限制？
关注存储和数据中心基础架构的朋友，这几天可能也看到Dell Technologies World 2022大会的新闻了。分布式软件定义存储产品PowerFlex预告了新版本4.0，其中比较吸引我的是加入文件存储（NAS），以及NVMe/TCP支持。
注：我不是PowerFlex__、分布式存储方面的专家，下文中如有错误，恳请大家批评指正。
分布式存储性能已过剩？
提到PowerFlex我自然想到其前身，也就是EMC在2013年收购的ScaleIO。5年前我还写过下面这两篇：
本文我想跟大家聊聊新发布功能中的技术干货，也就是《Dell Technologies World 2022 – PowerFlex 4.0, A High-level overview》这篇博客的学习笔记。
从ScaleIO到PowerFlex，一直以高性能、高恢复速度（Rebuild重构快）为特点。早年我列出的性能数字，还是在40Gb/s网络和PCIe SSD的初期阶段（每节点1块SLC PCIe闪存卡+6个cMLC SATA SSD），如今的硬件包括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网关
图片点开后可放大，以下同
在今年将会到来的PowerFlex 4.0版本中，新的文件存储功能也被称为SDNAS（软件定义的NAS）。在PowerFlex原有的块存储服务基础上，增加了NFS/SMB文件协议的支持。
- Performance and Scale: Transactional databases and traditional NAS workloads（针对交易型数据库和传统NAS工作负载）
- High Availability: 30 seconds target（高可用30秒切换目标）
- Fault Tolerance & Resiliency: LACP Bonds（故障切换&弹性：LACP聚合绑定）
- File Maintenance mode: New maintenance mode for serviceability operation（文件维护模式，用于服务操作）
- Management and Monitoring: UI and REST API, CloudIQ Integration, SNMP v2/v3 support（管理和监控）
NVMe over Fabric (TCP)–在当前基于agent的SDC访问模式基础上，加入NVMe/TCP前端标准块存储协议支持。
如上图，SDT指的就是运行在PowerFlex SDS数据服务节点上的NVMe/TCP Target。
而NAS Server则是指专用的SDNAS节点（2-16个），形成一个PowerFlex文件服务集群。如下图：
上面是个典型的、在分布式块存储前端添加集群NAS网关的架构。每个NAS服务器节点用SDC访问PowerFlex的SDS后端块存储，然后运行NAS容器提供文件服务。
面对前端的应用主机访问，NAS节点除了提供Pri/Sec主备访问路径之外，我想容器化的另一个好处就是易于部署、伸缩。据了解，Dell的PowerStore T系列统一存储的文件功能应该也是基于容器实现的。（扩展阅读：《Dell EMC PowerStore__详解：NVMe+SAS__全闪存阵列，还是一体机？》）
关于NAS具体的支持特性，我直接把英文描述粘贴过来了。
NAS nodes
- Dedicated nodes to host the NAS containers
- PowerFlex Appliance and Rack to use PowerEdge R650-based NAS nodes（基于R650服务器的NAS节点）
NAS cluster
- There will be one NAS cluster per PowerFlex system (MDM-cluster)
- An NAS cluster can have 2-16 physical NAS nodes
Storage Pools
- Every Protection Domain will have a Storage Pool dedicated for NAS
SP to house NAS configuration volumes for “NAS Servers”
- SP can also be used for user filesystems
- ‘NAS Server’
A logical construct that provides data segregation
- A “NAS Server” hosts multiple File Systems
- NAS Server configuration volumes will be thin provisioned
File Systems
- Bound to it’s parent “NAS Server”
- Served by a single, dedicated PowerFlex (block) volume and is transparent to the user
- User file systems benefit from the full performance and data resiliency of PowerFlex block volumes
Supported protocols（协议支持）
- NFS and SMB support (NFSv3 and v4, SMBv2 and v3)
- FTP and SFTP
File System Operations
- User quotas and Tree Quotas
- Extend/shrink file system (space reclaim)
- File system read/write snapshots（可读/写快照）
Workloads
- Transactional databases and Traditional NAS workloads
Data Reduction
- Inline Compression（线内压缩，PowerFlex当前就支持块存储的压缩）
Management and Monitoring
- UI and REST API
- CloudIQ Integration
- SNMP v2 and v3 support
Data Protection
- 3-way NDMP support for backup（NDMP备份）
Security
- CAVA (Common Antivirus Agent for SMB clients)
- D@RE with CloudLink
Serviceability
- SRS/ESE (Call Home)
- Alerts
- Data collection aka “native audit log”
SDC专用客户端与NVMe/TCP标准协议
传统的PowerFlex块存储访问如上图，在每一台应用服务器上运行SDC agent客户端，来访问SDS存储节点，中间的网络是基于TCP的。SDC支持的操作系统包括VMware ESXi、Windows、AIX和众多Linux发行版。如果SDC和SDS部署在同一个物理服务器上，那样就是HCI超融合的形态。
PowerFlex 4.0引入NVMe/TCP的最大好处，就是可以使用主流Linux发行版和ESXi中已经可用的标准NVMe/TCP系统内置驱动。
扩展阅读：《NVMe-oF__：基于IP__的NVMe SAN__自动化发现存储网络》（当初这篇涉及到的还是集中存储阵列用的PowerStore OS 2.1）
《VMware NVMe支持：vSphere7.0 U3及未来展望》
如同前面那张NAS示意图，PowerFlex NVMe/TCP主机连接性也画的很实在。在每个SDS存储节点上跑一个SDT，这样前端的ESXi等主机就可以用NVMe/TCP标准协议来访问了。Dell同时还说明了以下2点：
-SDC保持更快和更低的延时，因为NVMe/TCP部署在网络上增加了“一跳”（_原文：__SDC remains faster with lower latency as NVMe/TCP implementation add another network hop）。
-NVMe/TCP与SDC共存，但不能共享相同的卷（can't share samevolumes）。
根据我的理解，Ceph等分布式存储在支持iSCSI等标准协议时，也要面对类似的情况。
PowerFlex NVMe/TCP部署当前支持的操作系统包括：ESXi 7.0U3, RHEL 8.6 and later, SLES 15SP3, Ubuntu 20.04。可以不用专用kerneldriver（SDC）了。
如上图，左边示例中的浅绿色箭头为SDC协议数据访问路径，它能够感知卷数据的分布并发送IO到“正确的”SDS。
中间示例的紫色箭头代表NVMe-oF协议路径，ESXi等主机上的Initiator发送IO到某一个SDT，然后SDT与不在同一服务器节点上的SDS(2)之间还要使用SDC协议（绿色箭头），所以说增加了一跳（using an additional network hop to find the“right”SDS）。
右边的Host-based SDT应该是未来的计划。把SDT跑在ESXi主机上的一个VM里，这样NVMe-oF协议只是经过虚拟网络不出节点，一方面SDT不像以前SDC那样“侵入”ESXi内核，同时SDT到目标SDS之间还能使用ESXi的PVRDMA来进一步降低延时。
感觉在VMware环境中Host-based SDT后续可能会替代当前的SDC，我理解SDC针对每一个ESXi版本都要做适配。
更多关于PowerFlex4.0 – Unified Management统一管理等内容，由于时间所限我就不讨论了，有兴趣的朋友可以访问以下原文链接。
作者：唐僧 huangliang
原文：企业存储技术
推荐阅读
欢迎关注企业存储技术极术专栏， 欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
