你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

在 Azure NetApp 文件上部署 SAS Grid 9.4

Azure NetApp 文件
Azure 虚拟机

SAS 分析软件提供一套服务和工具,用于从数据中提取见解并做出智能决策。 SAS 解决方案提供分析、人工智能、商业智能、客户智能、数据管理以及欺诈和安全智能。

如果要部署 Azure 上的 SAS GridAzure NetApp 文件可行的主要存储选项。 使用 Azure NetApp 文件的可缩放服务时,可以在不中断服务的情况下随时增加或减少存储分配。 还可以根据性能要求动态调整存储服务级别。

SAS 提供以下主要平台,这些平台已经过 Microsoft 验证:

  • SAS Grid 9.4
  • SAS Viya

SAS Grid 9.4 已在 Linux 上经过验证。

本文提供有关如何运行 Azure 上的 SAS Grid 9.4 以及如何使用 Azure NetApp 文件进行 SASDATA 存储的一般信息。 其中还提供有关 SASWORK 的存储选项的指南。 这些指南假定你在自己的租户中托管自己的 Azure 上的 SAS 解决方案。 SAS 不提供针对 Azure 上的 SAS Grid 的托管服务。

体系结构

此图显示用于运行 Azure 上的 SAS Grid 的体系结构。

下载包含本文中所有示意图的 PowerPoint 文件

数据流

计算层使用 SASDATA(和可选的 SASWORK)卷跨网格共享数据。 SASDATA 是 Azure NetApp 文件上连接 NFS 的卷。

  • 计算节点从 SASDATA 读取输入数据,并将结果写回到 SASDATA。
  • 分析作业的后续部分可由计算层中的另一个节点运行。 它使用相同的过程来获取和存储需要处理的信息。

可能的用例

使用 Azure NetApp 文件的可缩放 SAS Grid 部署适用于以下用例:

  • 金融分析
  • 欺诈检测
  • 濒危物种的跟踪和保护
  • 科学和医学
  • 分析和 AI

存储性能要求

对于 Azure 上的 SAS 9.4(SAS Grid 或 SAS Analytics Pro)部署,Azure NetApp 文件对于大小有限的 SAS Grid 群集来说是一个可行的主要存储选项。 SAS 建议每个物理核心的吞吐量为 100 MiB/秒。 根据这一建议,将 Azure NetApp 文件卷用于存储 SASDATA(永久性 SAS 数据文件)的 SAS Grid 群集可跨两个或更多 Azure 虚拟机扩展到 32 至 48 个物理核心。 SAS 群集大小基于每个 SAS 群集的单个 SASDATA 命名空间的体系结构约束以及可用的单个 Azure NetApp 文件卷带宽。 当 Azure 基础结构(计算、网络和每个文件系统存储带宽)随时间的推移而增加时,将重新访问核心计数指南。

Azure NetApp 文件卷性能预期

单个 Azure NetApp 文件卷可处理高达 4,500 MiB/秒的读取吞吐量和 1,500 MiB/秒的写入吞吐量。 如果某个 Azure 实例类型具有足够的出口带宽,单个虚拟机可以占用单个 Azure NetApp 文件卷的所有写入带宽。 但是,只有最大的单个虚拟机才能占用单个卷的所有读取带宽。

SASDATA 是 SAS 9.4 的主要共享工作负载,其读/写比率为 80:20。 对于读/写量为 64KiB 的工作负载(读/写比率为 80:20),每个卷的重要数据如下:

  • 并发运行的 2,400 MiB/秒的读取吞吐量和 600 MiB/秒的写入吞吐量(合计约 3,000 MiB/秒)。

有关详细信息,请参阅适用于 Linux 的 Azure NetApp 文件性能基准

注意

现已推出 Azure NetApp 文件大型卷功能。 此功能可提供高于常规 Azure NetApp 文件卷的的每卷吞吐量。 如果 SASDATA(或 SASWORK)卷需要更高的性能,则可以考虑使用此功能。 有关详细信息,请参阅此文档

容量建议

Azure NetApp 文件性能计算器可以提供有关如何调整 SASDATA 卷大小的指南。

选择适当的服务级别非常重要,原因如下:

  • 卷带宽取决于卷容量。
  • 容量成本取决于服务级别。
  • 你选择哪个服务级别取决于容量与带宽需求。

在计算器中,选择“高级”,并选择一个区域,然后输入以下值。

  • 卷大小:所需容量
  • 吞吐量:所需吞吐量,考虑每个核心 100 MiB/秒
  • 读取百分比:80%
  • IOPS:0
  • I/O 大小:64KiB,顺序

屏幕底部的输出根据所选区域的价格提供每个服务级别的建议容量需求和每月成本:

  • 吞吐量。 卷的带宽(基于工作负载组合)。 对于 80% 64 KiB 的顺序读取工作负载,预期最大值为 3,096 MiB/秒。
  • IOPS。 卷在指定吞吐量下提供的 IOPS 数。
  • 卷大小。 卷在给定服务级别上实现目标吞吐量所需的容量。 卷容量(以 GiB 为单位进行报告)可以等于或小于容量池大小。 此建议假定使用的是自动 QoS 容量池类型。 若要进一步优化容量池中不同卷之间的容量与吞吐量分布,请考虑使用手动 QoS 容量池类型。
  • 容量池大小。 池大小。 卷的容量是从容量池中划分出来的。 以 1 TiB 为增量增加容量池的大小。
  • 容量池成本(美元/月)。 在给定大小和服务级别下,容量池的每月成本。
  • 卷用量成本(美元/月)。 在指定容量下,卷的容量的每月成本。 费用根据分配的容量池大小进行计算。 卷用量成本可表明卷数量。

注意

只要预配了足够的带宽,无论使用哪个服务级别,用户体验都是相同的。

根据需要通过在 Azure NetApp 文件中使用卷调整功能来控制成本。 有两个动态选项可影响性能和成本:

详细了解 Azure NetApp 文件成本模型

数据保护

Azure NetApp 文件使用快照来帮助保护数据。 快照提供 Azure NetApp 文件卷的节省空间、崩溃一致且近乎即时的图像。 可以随时手动创建快照,也可以在卷上使用快照策略来计划快照。

使用快照策略向卷添加自动数据保护。 可使用快照还原来快速就地还原快照。 或者,可以将快照还原到新卷,以便快速恢复数据。 还可以使用还原到新卷功能在测试/开发环境中提供当前数据。

若要执行其他级别的数据保护,可以利用使用 Azure NetApp 文件备份或合作伙伴备份软件的数据保护解决方案。

组件

  • Azure 虚拟机:SAS Grid 需要与核心数保持适当比率的高内存、存储和 I/O 带宽。 Azure 提供具有较低 vCPU 计数的预定义虚拟机 (VM) 大小,有助于平衡所需的核心数与内存量、存储和 I/O 带宽。

    有关详细信息,请参阅支持受约束 vCPU 的 VM 大小。 请务必全面了解每个实例可用的计算资源。 若要使用 Azure NetApp 文件运行 Azure 上的 SAS Grid,建议使用以下实例类型:

    • Standard_E64-16ds_v4 或 Standard_E64-16ds_v5
    • Standard_E64-32ds_v4 或 Standard_E64-32ds_v5

    请务必查看使用 Azure 上的 SAS 的最佳做法,包括注释中的更新。

  • Azure NetApp 文件:可以将 SASDATA 存储在跨计算群集共享的 Azure NetApp 文件卷上。

    还可以选择将 Azure NetApp 文件 NFS 卷用于存储 SASWORK。

    Azure NetApp 文件有三种性能服务级别

    • 标准
    • 高级
    • 超高性能

    卷性能主要由服务级别定义。 卷大小也是一个因素,因为可获得的吞吐量取决于服务级别和卷大小

有关 SASDATA 的存储选项

由于 Azure NetApp 文件可以提供高吞吐量和对存储的低延迟访问,因此它是高级磁盘的可行且速度更快的替代方法。 与托管磁盘不同,网络连接的存储在 VM 级别不受限制,因此你可以获得更高的存储吞吐量。

若要估算 SASDATA 容量所需的层,请使用 Azure NetApp 文件性能计算器。 (请务必选择“高级”。)

由于 Azure NetApp 文件 NFS 卷是共享的,因此,当与具有适当大小的 VM 实例类型和 Red Hat Enterprise Linux (RHEL) 分发版一起使用时,它们是用于托管 SASDATA 的不错候选项,本文稍后将对此进行讨论。

有关 SASWORK 的存储选项

下表显示了用于在 Azure 上部署 SASWORK 的最常用存储选项。 根据大小(容量)和速度(带宽)需求,系统提供了三个选项:临时存储、托管磁盘和 Azure NetApp 文件。

临时存储 托管磁盘 Azure NetApp 文件
大小 大型 特大型
Speed 特大型 小型 中型

进行选择时,请考虑以下注意事项:

  • 临时存储(或短暂存储)提供最高带宽,但仅在容量较小时可用。 (大小取决于 VM SKU。)根据可用容量和所需容量,此选项可能是最佳选择。
  • 如果所需的 SASWORK 容量超过所选 VM SKU 的临时存储大小,请考虑使用 Azure 托管磁盘来托管 SASWORK。 但请记住,根据设计,托管磁盘的吞吐量受 VM 体系结构的限制,并且具体取决于 VM SKU。 因此,此存储选项仅适用于 SASWORK 性能要求较低的环境。
  • 对于最高 SASWORK 容量要求和超出 Azure 托管磁盘所能提供的平均性能要求,请考虑使用 Azure NetApp 文件存储 SASWORK。 它提供较大的大小和快速吞吐量。

重要

请记住,在任何情况下都无法在 VM 计算节点之间共享 SASWORK,因此需要为每个计算节点创建单独的 SASWORK 卷。 只需在一个计算节点上对卷进行 NFS 装载。

使用上表时,若要确定所需的大小是小、大、中还是特大,请考虑部署规模、VM 和核心的数量以及相关的容量和性能要求。 需要针对每个部署进行这些评估。

表中的选项对应于以下体系结构中描述的部署。 在所有情况下,SASDATA 都托管在 Azure NetApp 文件 NFS 卷上,并在计算节点之间共享。 对于某些 RHEL 分发版,建议使用 NFS nconnect 选项创建到卷的多个网络流。 有关详细信息,请参阅本文的 NFS 装载选项部分。

临时存储体系结构

此图显示临时存储体系结构。

对于较小 SASWORK 容量要求,Azure VM 临时存储是一种快速且实惠的解决方案。 在此体系结构中,计算层中的每个 VM 都配有一些临时存储。 若要确定所使用的 VM 的临时存储大小,请参阅 Azure VM 文档

数据流

  • 计算节点从 SASDATA 读取输入数据,并将结果写回到 SASDATA。
  • 分析作业的后续部分可由计算层中的另一个节点运行。 它使用相同的过程来获取和存储需要处理的信息。
  • 未共享临时工作目录 SASWORK。 它存储在每个计算节点上的临时存储中。

托管磁盘体系结构

此图显示托管磁盘体系结构。

如果针对 SASWORK 的容量要求超过临时存储中可用的容量,Azure 托管磁盘是一个不错的替代方法。 托管磁盘有各种大小和性能级别。 有关详细信息,请参阅 VM 磁盘的可伸缩性和性能目标

数据流

  • 计算节点从 SASDATA 读取输入数据,并将结果写回到 SASDATA。
  • 分析作业的后续部分可由计算层中的另一个节点运行。 它使用相同的过程来获取和存储需要处理的信息。
  • 未共享临时工作目录 SASWORK。 它存储在附加到每个计算节点的托管磁盘上。

Azure NetApp 文件体系结构

此图显示 Azure NetApp 文件体系结构。

对于较高 SASWORK 容量和/或中等性能要求,请考虑使用 Azure NetApp 文件。 Azure NetApp 文件提供高达 100 TiB 的卷容量。 计算层中的每个节点都应具有其自己的 SASWORK 卷。 不应共享这些卷。

数据流

  • 计算节点从 SASDATA 读取输入数据,并将结果写回到 SASDATA。
  • 分析作业的后续部分可由计算层中的另一个节点运行。 它使用相同的过程来获取和存储需要处理的信息。
  • 未共享临时工作目录 SASWORK。 它存储在附加到每个计算节点的各个 Azure NetApp 文件卷上。

规模和配置建议

RHEL 分发版和 NFS 设置

RHEL 分发版

RHEL 是用于运行 SAS 9 Linux 版的推荐分发版。 Red Hat 支持的每个内核都有自己的 NFS 带宽约束。

有关运行 Azure 上的 SAS 的详细信息,请参阅使用 Azure 上的 SAS 的最佳做法

对于 SAS,建议使用 Standard_E64-16ds_v4 和 Standard_E64-32ds_v4 VM 或其 v5 等效项。 根据这些建议,本部分提供了一些关于将 SAS 与 Azure NetApp 文件配合使用的准则。

  • 如果使用 RHEL 7,则根据 SASDATA 的每个物理核心目标 100 MiB/秒,Standard_E64-16ds_v4 或 Standard_E64-16ds_v5 是最佳选择。

    • Standard_E64-16ds_v4:每个核心 90-100 MiB/秒
    • Standard_E64-32ds_v4:每个核心 45-50 MiB/秒
  • 如果使用 RHEL 8.2,则 Standard_E64-16ds_v4 或 Standard_E64-32ds_v4 或其 v5 等效项都是可行选项。 如果 SASDATA 的每个核心目标为 100 MiB/秒,则最好选择 Standard_E64-16ds_v4。

    • Standard_E64-16ds_v4:每个核心 150-160 MiB/秒
    • Standard_E64-32ds_v4:每个核心 75-80 MiB/秒
  • 如果使用 RHEL 8.3,则当每个核心吞吐量目标如下所示时,Standard_E64-16ds_v4 和 Standard_E64-32ds_v4 或其 v5 等效项均是完全可接受选项:

    • 验证指示读取吞吐量为 3,200 MiB/秒。
    • 这些结果是通过 NFS nconnect 装载选项实现的。

测试表明,单个 RHEL 7 实例针对单个 Azure NetApp 文件存储终结点(即针对网络套接字)实现的读取吞吐量不超过大约 750-800 MiB/秒。 如果使用 64 KiB 的 rsizewsize NFS 装载选项,则可以针对同一终结点实现 1,500 MiB/秒的写入吞吐量。 一些证据表明,前面提到的读取吞吐量上限是 3.10 内核的限制。 有关详细信息,请参阅 RHEL CVE-2019-11477

测试表明,具有 4.18 内核的单个 RHEL 8.2 实例不受 3.10 内核中所述的限制。 因此,如果使用 64 KiB 的 rsizewsize NFS 装载选项,则可实现 1,200-1,300 MiB/秒的读取流量。 对于大型顺序写入,预计可获得与 RHEL 7 相同的 1500 MiB/秒的可实现吞吐量。

对于单个 RHEL 8.3 实例,使用 nconnect 装载选项(RHEL 8.3 分发版中的新增选项),可以从单个 Azure NetApp 文件卷实现大约 3,200 MiB/秒的读取吞吐量。 单个 Azure NetApp 文件卷的写入吞吐量预计不会超过 1,500 MiB/秒,即使应用 nconnect 也是如此。

内核可调参数

槽表条目

NFSv3 没有用于在客户端和服务器之间协商并发的机制。 客户端和服务器各自定义其限制,彼此不知道对方的限制。 为获得最佳性能,应将客户端 sunrpc 槽表条目的最大数目与在服务器上支持的最大数目(不需要回推)对齐。 当客户端使服务器网络堆栈负担过重而无法处理工作负载时,服务器会通过减小连接的窗口大小进行响应,这对于性能来说不是理想情况。

默认情况下,新式 Linux 内核将每连接 sunrpc 槽表条目大小 sunrpc.max_tcp_slot_table_entries 定义为支持 65,536 个未完成操作。 这些槽表条目定义并发限制。 由于 Azure NetApp 文件的默认值为 128 个未完成的操作,因此不需要设置如此高的值。

建议将客户端调整为相同的数量:

  • 内核可调参数(通过 /etc/sysctl.conf)
    • sunrpc.tcp_max_slot_table_entries=128

文件系统缓存可调参数

还需要了解有关文件系统缓存可调参数的以下因素

  • 刷新脏缓冲区会使数据处于干净状态,可供将来读取,直到内存压力导致逐出。
  • 异步刷新操作有三个触发器:

这些因素由四个可调参数控制。 可以通过使用 /etc/sysctl.conf 文件中的 tunedsysctl 来以动态方式持久优化每个可调参数。 优化这些参数可以改进 SAS Grid 的性能:

  • 内核可调参数(通过自定义优化的配置文件)
    • include = throughput-performance
    • vm.dirty_bytes = 31457280
    • vm.dirty_expire_centisecs = 100
    • vm.dirty_writeback_centisecs = 300

NFS 装载选项

对于用于存储永久性 SASDATA 文件的 NFS 共享文件系统,建议使用以下 NFS 装载选项:

RHEL 7 和 8.2

bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev

RHEL 8.3

bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev,nconnect=8

对于 SASWORK 卷,建议使用以下装载选项,其中相应的卷专用于存储 SASWORK,且不在节点之间共享:

RHEL 7 和 8.2

bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev,nocto

RHEL 8.3

bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev,nocto,nconnect=8

若要详细了解 nocto 装载选项的优点和成本,请参阅 Close-to-open 一致性和缓存属性计时器

还应查看 Azure NetApp 文件:要与 MS Azure 上的 SAS Grid 配合使用的共享文件系统,其中包括注释中的所有更新。

NFS 预读设置

建议将所有 RHEL 分发版的 NFS 预读可调参数设置为 15,360 KiB。 有关详细信息,请参阅如何为 NFS 装载永久设置预读

备选方法

根据 Azure NetApp 文件服务级别协议的规定,上述体系结构中的存储解决方案具有高可用性。 为了进行进一步保护和提高可用性,可以使用 Azure NetApp 文件跨区域复制来将存储卷复制到另一个 Azure 区域。

通过存储解决方案复制卷有两个关键优势:

  • 应用程序 VM 上没有额外的负载。
  • 借助此解决方案,在正常操作期间无需在目标区域中运行 VM。

无需使用任何计算基础结构资源即可复制存储内容,并且目标区域无需运行 SAS 软件。 无需运行目标 VM 即可支持此方案。

下面的体系结构展示了如何将 Azure NetApp 文件上的存储内容复制到第二个区域,其中存储是使用生产数据的副本填充的。 如果发生故障转移,次要区域将处于联机状态,并且 VM 会启动,以便在第二个区域中恢复生产。 需要通过重新配置图中未显示的负载均衡器来将流量重新路由到第二个区域。

此图显示跨区域复制的体系结构。

当跨区域复制更新间隔设置为 10 分钟时,此解决方案的典型 RPO 小于 20 分钟。

数据流

  • 计算节点从 SASDATA 读取输入数据,并将结果写回到 SASDATA。
  • 分析作业的后续部分可由计算层中的另一个节点运行。 它使用相同的过程来获取和存储需要处理的信息。
  • 未共享临时工作目录 SASWORK。 它存储在附加到每个计算节点的各个 Azure NetApp 文件卷上。
  • Azure NetApp 文件跨区域复制会将 SASDATA 卷(包括所有快照)异步复制到 DR 区域,以便在发生区域性灾难时进行故障转移。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则,即一套可用于改进工作负载质量的指导原则。 有关详细信息,请参阅 Microsoft Azure 架构良好的框架

可靠性

可靠性可确保应用程序符合你对客户的承诺。 有关详细信息,请参阅可靠性支柱概述

Azure NetApp 文件提供针对所有层和所有受支持的区域的标准 99.99% 可用性 SLA。 Azure NetApp 文件还支持在所选的可用性区域中预配卷,以及跨区域进行 HA 部署。

为了改进 RPO/RTO SLA,该服务包含通过快照和备份保护集成数据的功能。 跨区域复制在 Azure 区域之间具有相同的优势。

安全性

安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息,请参阅安全性支柱概述

Azure NetApp 文件提供了一定级别的安全性,因为卷在虚拟网络中预配,并且数据流量也位于虚拟网络内。 没有可公开寻址的终结点。 所有数据均始终采用静态加密。 可以选择对传输中的数据进行加密。

Azure Policy 可帮助你执行组织标准并大规模评估合规性。 Azure NetApp 文件通过自定义内置策略定义支持 Azure Policy。

性能效率

性能效率是指工作负载能够以高效的方式扩展以满足用户对它的需求。 有关详细信息,请参阅性能效率要素概述

性能

根据吞吐量和容量的要求,请谨记以下注意事项:

注意

现已推出 Azure NetApp 文件大型卷功能。 此功能可提供高于常规 Azure NetApp 文件卷的的每卷吞吐量。 如果 SASDATA(或 SASWORK)卷需要更高的性能,则可以考虑使用此功能。 有关详细信息,请参阅此文档

可伸缩性

通过将 VM 添加到运行 SAS 解决方案的三个层的规模集,可以轻松缩放计算性能。

可以动态缩放 Azure NetApp 文件卷的存储。 如果使用自动 QoS,则会同时提升性能。 若要更精细地控制每个卷,还可以对容量池使用手动 QoS 来分别控制每个卷的性能。

Azure NetApp 文件卷有三个性能层:超高性能、高级和标准。 选择最适合性能要求的层,同时考虑到可用性能带宽会根据卷大小进行缩放。 可以随时更改卷的服务级别。 有关 Azure NetApp 文件成本模型的详细信息,请参阅这些定价示例

可以使用入门指南 Azure NetApp 文件性能计算器

成本优化

成本优化就是减少不必要的费用和提高运营效率。 有关详细信息,请参阅成本优化支柱概述

成本模型

了解 Azure NetApp 文件的成本模型可有助于管理开支。

Azure NetApp 文件按预配的存储容量计费,该容量通过创建容量池进行分配。 容量池根据每小时分配的每个 GiB 的设定成本按月计费。

如果容量池大小要求波动(例如,由于容量或性能需求的变化),请考虑动态调整卷和容量池的大小以平衡成本与容量和性能需求。

如果容量池大小要求保持不变,但性能要求波动,请考虑动态更改卷的服务级别。 你可以在整个月内预配和取消预配不同类型的容量池,提供即时性能,并在不需要高性能的时段降低成本。

定价

根据容量和性能要求,确定所需的 Azure NetApp 文件服务级别(标准、高级或超级)。 然后使用 Azure 定价计算器估算这些组件的成本:

  • Azure 上的 SAS 组件
  • Azure NetApp 文件
  • 托管磁盘(可选)
  • 虚拟网络

卓越运营

卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息,请参阅卓越运营支柱概述

Azure 上的 SAS Grid 提供灵活性和快速部署。 部分优势如下:

  • 通过动态工作负载均衡满足不断变化的业务需求
  • 创建高度可用的 SAS 计算环境
  • 通过现有 IT 基础结构更快地获得结果
  • 以经济高效的增量方式增加计算资源
  • 管理所有分析工作负载
  • 轻松地从孤立的服务器或具有多台电脑的环境转换到 SAS 网格环境

部署此方案

最好使用基础结构即代码 (IaC) 过程来部署工作负载。 SAS 工作负载可能对手动部署中经常发生的错误配置敏感,并会降低工作效率。

若要开始设计 Azure 上的 SAS Grid 解决方案,请查看 Azure 上的 SAS 体系结构使用 GitHub Actions 在 Azure 上自动执行 SAS 部署

作者

本文由 Microsoft 维护, 它最初是由以下贡献者撰写的。

主要作者:

其他参与者:

若要查看非公开的 LinkedIn 个人资料,请登录到 LinkedIn。

后续步骤