你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure NetApp 文件的 SMB 性能最佳做法
本文将帮助你了解 Azure NetApp 文件的 SMB 性能和最佳做法。
SMB 多通道
SMB 共享中默认启用 SMB 多通道。 所有 SMB 共享预先可追溯的现有 SMB 卷已启用了这一功能，并且在创建新卷时，所有新创建的卷也将启用该功能。
在启用该功能之前建立的任何 SMB 连接需要重置才能利用 SMB 多通道功能。 要重置，你可以先断开与 SMB 共享的连接，然后重新连接。
从 Windows 2012 开始，Windows 支持 SMB 多通道，以实现最佳性能。 有关详细信息，请参阅部署 SMB 多通道和 SMB 多通道基础知识。
SMB 多通道的优点
使用 SMB 多通道功能，SMB3 客户端可以通过单个网卡 (NIC) 或多个 NIC 建立连接池，并使用这些连接来发送单个 SMB 会话的请求。 相反，根据设计，SMB1 和 SMB2 要求客户端建立一个连接，并通过该连接发送给定会话的所有 SMB 流量。 这一单个连接可限制单个客户端可以实现的总体协议性能。
SMB 多通道的性能
以下测试和图形演示了单实例工作负载上 SMB 多通道的强大功能。
随机 I/O
如果在客户端上禁用 SMB 多通道，则使用 FIO 和 40 GiB 工作集执行纯 4 KiB 读写测试。 SMB 共享已在每个测试之间分离，SMB 客户端连接计数递增，每个 RSS 网络接口设置为 1、4、8、16 和 set-SmbClientConfiguration -ConnectionCountPerRSSNetworkInterface <count>。 这些测试表明默认设置 4 足以满足 I/O 密集型工作负载的需求；递增到 8 和 16 产生的影响可以忽略。
netstat -na | findstr 445 命令证明已建立了其他连接，并且按从 1 到 4，从 4 到 8 和从 8 到 16 依次递增。 在每个测试过程中，SMB 已充分利用了四个 CPU 内核，这是由 perfmon Per Processor Network Activity Cycles 统计信息确认（不在本文讨论范围内）。
Azure 虚拟机 (VM) 不会影响 SMB（和 NFS）的存储 I/O 限制。 如下图所示，对于缓存的存储 IOPS，D32ds 实例类型的速率上限为 308000，对于非缓存存储 IOPS，则为 51200。 但是，上图显示出 I/O 明显高于 SMB。
顺序 I/O
类似于前面所述的随机 I/0 测试的测试是通过 64 KiB 顺序 I/O 执行的。 尽管每个 RSS 网络接口的客户端连接数增加到超过 4，但对随机 I/0 没有明显影响，但这一点不适用于顺序 I/O。 如下图所示，每次增加都与读取吞吐量的相应增加有关。 由于 Azure 针对每个实例类型和大小实施了网络带宽限制，因此写入吞吐量仍保持平缓趋势。
Azure 会对每个虚拟机类型和大小施加网络速率限制。 仅对出站流量施加速率限制。 虚拟机上存在的 NIC 数量与计算机的可用带宽总量无关。 例如，D32ds 实例类型施加的网络限制为 16000 Mbps (2000 MiB/秒)。 如上的顺序关系图所示，该限制会影响出站流量（写入），但不影响多多通道读取。
SMB 签名
SMB 协议为文件和打印共享以及其他网络操作（例如远程 Windows 管理）提供基础。 为了防止中间人攻击修改传输中的 SMB 数据包，SMB 协议支持 SMB 数据包的数字签名。
Azure NetApp 文件支持的所有 SMB 协议版本都支持 SMB 签名。
SMB 签名的性能影响
SMB 签名对 SMB 性能有负面影响。 在性能下降的各种可能原因中，每个数据包的数字签名将耗用额外的客户端 CPU 处理能力，如下面的 perfmon 输出所示。 在这种情况下，核心 0 在负责处理 SMB，包括 SMB 签名。 与上一节中的非多通道顺序读取吞吐量数字相比，结果表明，SMB 签名导致总体吞吐量从 875MiB/s 降低到大约 250MiB/s。
具有 1 TB 数据集的单个实例的性能
为了让您更详细地了解读/写混合型工作负荷，以下两个图表显示了具有 1 TB 数据集且 SMB 多通道为 4 的单个超级服务级别云卷（50 TB）的性能。 使用的最佳 IODepth 为 16，而灵活的 IO (FIO) 参数用于确保充分利用网络带宽 (numjobs=16)。
下图显示了4k 随机 I/O 的结果，其中包含单个 VM 实例，读/写混合的时间间隔为 10%：
以下图表显示了顺序 I/O 的结果：
使用具有 1 TB 数据集的 5 个 VM 进行横向扩展时的性能
这些测试包含 5 个 VM，使用与单个 VM 相同的测试环境，每个进程将写入到自己的文件中。
以下图表显示了顺序 I/O 的结果：
以下图表显示了顺序 I/O 的结果：
如何监视 Hyper-V 以太网适配器
使用 FIO 进行测试时，使用的一种策略是设置 numjobs=16。 这样做会将每个作业分叉为 16 个特定实例，以将 Microsoft Hyper-V 的网络适配器最大化。
可以在 Windows 性能监视器中检查每个适配器的活动，方法是选择“性能监视器”>“添加计数器”>“网络接口”>“Microsoft Hyper-V 网络适配器”。
在卷中运行数据流量后，可以在 Windows 性能监视器中监视适配器。 如果没有使用全部 16 个虚拟适配器，则可能无法最大程度地利用网络带宽容量。
SMB 加密
本部分帮助你理解 SMB 加密（SMB 3.0 和 SMB 3.1.1）
SMB 加密提供 SMB 数据的端对端加密，并防止数据在不受信任网络中遭到窃听。 SMB 3.0 及更高版本支持 SMB 加密。
向存储发送请求时，客户端会对该请求进行加密，随后存储会进行解密。 同样，响应由服务器加密并由客户端解密。
Windows 10、Windows 2012 及更高版本支持 SMB 加密。
SMB 加密和 Azure NetApp 文件
SMB 加密在 Azure NetApp 文件的共享级别启用。 SMB 3.0 采用 AES-CCM 算法，而 SMB 3.1.1 采用 AES-GCM 算法。
SMB 加密不是必需的。 因此，只有当用户要求 Azure NetApp 文件对特定共享启用加密时，才会启用它。 Azure NetApp 文件共享从不在 Internet 中公开。 只能从特定 VNet 中通过 VPN 或快速路由访问它们，因此，Azure NetApp 文件共享本质上是安全的。 启用 SMB 加密的选择完全由用户决定。 在启用此功能之前，请注意预期的性能损失。
SMB 加密对客户端工作负载的影响
尽管 SMB 加密会对客户端（加密和解密消息的 CPU 开销）和存储（降低吞吐量）产生影响，但下表只重点介绍了存储影响。 在将工作负载部署到生产环境之前，应测试加密性能对应用程序的影响。
| I/O 配置文件 | 影响 |
|---|---|
| 读取和写入工作负载 | 10% 到 15% |
| 元数据密集型 | %5 |
加速网络
为了获得最佳性能，建议尽可能在虚拟机上配置加速网络。 请谨记下列注意事项：
- 默认情况下，Azure 门户将为支持此功能的虚拟机启用加速网络。 但其他部署方法（如 Ansible 和类似的配置工具）可能不会执行这一操作。 未启用加速网络可能会降低计算机的性能。
- 如果虚拟机的网络接口由于不支持某一实例类型或大小而未启用加速网络，则对于更大的实例类型，仍会禁用加速网络。 在这些情况下，你需要手动干预。
- 无需在 Azure NetApp 文件的专用子网中为 NIC 设置加速网络。 加速网络是仅适用于 Azure 虚拟机的功能。 Azure NetApp 文件 NIC 已按设计进行优化。
接收端缩放
Azure NetApp 文件支持接收方缩放 (RSS)。
启用 SMB 多通道后，SMB3 客户端通过支持单一 RSS 功能的网卡 (NIC) 来建立与 Azure NetApp 文件 SMB 服务器的多个 TCP 连接。
要查看你的 Azure 虚拟机 NIC 是否支持 RSS，请按如下所示运行 Get-SmbClientNetworkInterface 命令并检查字段 RSS Capable：
SMB 客户端上的多个 NIC
不应在客户端上为 SMB 配置多个 NIC。 SMB 客户端与 SMB 服务器返回的 NIC 计数不匹配。 每个存储卷都只可从一个存储终结点访问，这意味着对于任何给定的 SMB 关系，只使用一个 NIC。
如下面的 Get-SmbClientNetworkInterface 输出所示，虚拟机具有 2 个网络接口：15 和12。 如下面的命令 Get-SmbMultichannelConnection 中所示，尽管有两个支持 RSS 的 NIC，但与 SMB 共享的连接仅使用了接口 12；未使用接口 15。
