简体中文版经机器翻译而成,仅供参考。如与英语版出现任何冲突,应以英语版为准。

工作负载测试

提供者

AFF A300 操作步骤

AFF A300 HA 对可以轻松运行现有最大的 Epic 实例。如果您有两个或更多非常大的 Epic 实例,则可能需要根据 AFF SPM 工具的结果使用 SPM A700 。

数据生成

LUN 中的数据是使用 Epic 的 Dgen.pl 脚本生成的。该脚本用于创建类似于 Epic 数据库中的数据。

从两个 RHEL VM epo-rhel1 和 epo-rhel2 运行了以下 dgen 命令:

./dgen.pl --directory "/epic" --jobs 2 --quiet --pctfull 20

` -pctfull` 是可选的,用于定义要填充数据的 LUN 百分比。默认值为 95% 。大小不会影响性能,但会影响将数据写入 LUN 的时间。

在 dgen 过程完成后,您可以对每个服务器运行 Genio 测试。

运行 Genio

测试了两台服务器。执行的 IOPS 将从 75 , 000 次增加到 110 , 000 次,这代表了一个非常大的 Epic 环境。这两个测试都同时运行。

从服务器 epio-rhel1 运行以下 Genio 命令:

./RampRun.pl –miniops 75000 --maxiops 110000 --background --disable-warmup --runtime 30 --wijfile /epic/epicjrn/GENIO.WIJ --numruns 10 --system epic-rhel1 --comment Ramp 75-110k

AFF A300 上的 Genio 结果

下表列出了 AFF A300 上的 Genio 结果

读取 IOPS 写入 IOPS IOPS 总数 最长写入周期(秒) 有效写入延迟(毫秒) 随机读取平均值(毫秒)

142505

46443.

188929

44.68

0.115

0.66

AFF A700 操作步骤

对于大型 Epic 环境(通常全球引用量超过 1000 万次),客户可以选择 AFF A700 。

数据生成

LUN 中的数据是使用 Epic 的 Dgen.pl 脚本生成的。该脚本用于创建类似于 Epic 数据库中的数据。

在所有三个 RHEL VM 上运行以下 dgen 命令。

./dgen.pl --directory "/epic" --jobs 2 --quiet --pctfull 20

` -pctfull` 是可选的,用于定义要填充数据的 LUN 百分比。默认值为 95% 。大小不会影响性能,但会影响将数据写入 LUN 的时间。

在 dgen 过程完成后,您可以为每个服务器运行 Genio 测试。

运行 Genio

测试了三台服务器。在两台服务器上,执行了从 75 , 000 次到 100 , 000 次的 IOPS 增长,这代表了一个非常大的 Epic 环境。第三台服务器设置为抢占资源的服务器,将 IOPS 从 75 , 000 次增加到 170 , 000 次。所有这三项测试都同时运行。

从服务器 epio-rhel1 运行以下 Genio 命令:

./RampRun.pl –miniops 75000 --maxiops 100000 --background --disable-warmup --runtime 30 --wijfile /epic/epicjrn/GENIO.WIJ --numruns 10 --system epic-rhel1 --comment Ramp 75-100k

Genio 会对 AFF A700 进行测试

下表显示了 AFF A700 的 Genio 测试结果。

读取 IOPS 写入 IOPS IOPS 总数 最长写入周期(秒) 有效写入延迟(毫秒) 随机读取平均值(毫秒)

241 , 180

78,654

319837

43.24

0.09

1.05

采用 AQO 的性能 SLA

NetApp 可以使用 AQO 策略为工作负载设置性能下限和上限值。下限设置可确保最低性能。IOPS/TB 可以应用于 Epic 等应用程序的一组卷。分配给 QoS 策略的 Epic 工作负载会受到保护,不会受到同一集群上其他工作负载的影响。最低要求得到保证,同时允许工作负载达到高峰并使用控制器上的可用资源。

在此测试中,服务器 1 和服务器 2 受到 AQO 的保护,而第三台服务器则充当集群中发生原因性能下降的抢占资源的工作负载。AQO 允许服务器 1 和 2 按指定的 SLA 执行,而抢占资源的工作负载则表现为写入周期较长而出现降级的迹象。

自适应服务质量默认值

ONTAP 配置有三种默认的 AQO 策略:价值,性能和极高。可以使用 qos 命令查看每个策略的值。使用命令末尾的 ` -instant` 可查看所有 AQO 设置。

::> qos adaptive-policy-group show
Name         Vserver Wklds  Expected IOPS        Peak IOPS
extreme      fp-g9a  0      6144IOPS/TB 12288IOPS/TB
performance  fp-g9a  0      2048IOPS/TB 4096IOPS/TB
value        fp-g9a  0      128IOPS/TB  512IOPS/TB

以下是创建 AQO 策略的语法:

::> qos adaptive-policy-group modify -policy-group aqos- epic-prod1 -expected-iops 5000 -peak-iops 10000 -absolute-min-iops 4000 -peak-iops-allocation used-space

AQO 策略中有一些重要设置:

  • * 预期 IOPS* 。此自适应设置是策略的最小 IOPS/TB 值。保证工作负载至少获得此 IOPS/TB 级别。这是此测试中最重要的设置。在我们的示例测试中,性能 AQO 策略设置为 2048IOPS/TB 。

  • * 峰值 IOPS* 。此自适应设置是策略的最大 IOPS/TB 值。在我们的示例测试中,性能 AQO 策略设置为 4096 IOPS/TB 。

  • * 峰值 IOPS 分配。 * 选项为已分配空间或已用空间。将此参数设置为已用空间,因为此值会随着 LUN 中数据库的增长而发生变化。

  • * 绝对最小 IOPS 。 * 此设置为静态设置,不自适应。此参数可设置最小 IOPS ,而不考虑大小。此值仅在大小小于 1 TB 时使用,并且不会影响此测试。

通常,生产环境中的 Epic 工作负载以大约 ~1000 IOPS/TB 的存储和容量运行,并且 IOPS 呈线性增长。默认 AQO 性能配置文件对于 Epic 工作负载来说已足够。

在此测试中,实验室不会反映出一个生产规模较小且大小为 5 TB 的数据库。目标是以 75 , 000 次 IOPS 运行每个测试。EpicProd AQO 策略的设置如下所示。

  • 预期 IOPS/TB = 总 IOPS/ 已用空间

  • 15 , 000 IOPS/TB = 75 , 000 IOPS/5 TB

下表显示了用于 EpicProd AQO 策略的设置。

正在设置 …​ 价值

卷大小

5 TB

所需的 IOPS

75,000

峰值 IOPS 分配

已用空间

绝对最小 IOPS

7,500

预期 IOPS/TB

15,000

峰值 IOPS/TB

30,000

下图显示了如何在已用空间随时间增长时计算下限 IOPS 和上限 IOPS 。

错误:缺少图形映像

对于生产规模的数据库,您可以像上一个示例中使用的配置文件一样创建自定义 AQO 配置文件,也可以使用默认性能 AQO 策略。下表显示了性能 AQO 策略的设置。

正在设置 …​ 价值

卷大小

75 TB

所需的 IOPS

75,000

峰值 IOPS 分配

已用空间

绝对最小 IOPS

500

预期 IOPS/TB

1,000

峰值 IOPS/TB

2,000

下图显示了默认性能 AQO 策略中的已用空间随时间增长而增长时如何计算下限和上限 IOPS 。

错误:缺少图形映像

Parameters

  • 以下参数指定自适应策略组的名称:

         -policy-group <text> - Name

    自适应策略组名称必须唯一,并且限制为 127 个字母数字字符,包括下划线 "_" 和连字符 "-" 。自适应策略组名称必须以字母数字字符开头。使用 qos adaptive-policy-group rename 命令更改自适应策略组名称。

  • 以下参数指定此自适应策略组所属的数据 SVM (在命令行中称为 Vserver )。

         -vserver <vserver name> - Vserver

    您只能将此自适应策略组应用于指定 SVM 中包含的存储对象。如果系统只有一个 SVM ,则该命令默认使用该 SVM 。

  • 以下参数指定根据存储对象分配的大小分配的最小预期 IOPS/TB 或 IOPS/GB 。

         -expected-iops {<integer>[IOPS[/{GB|TB}]] (default: TB)} - Expected IOPS
  • 以下参数根据存储对象的已分配大小或存储对象的已用大小指定可能分配的最大 IOPS/TB 或 IOPS/GB 。

         -peak-iops {<integer>[IOPS[/{GB|TB}]] (default: TB)} - Peak IOPS
  • 以下参数指定在预期 IOPS 小于此值时用作覆盖的绝对最小 IOPS 。

         [-absolute-min-iops <qos_tput>] - Absolute Minimum IOPS

    默认值计算如下:

    qos adaptive-policy-group modify -policy-group aqos- epic-prod1 -expected-iops 5000 -peak-iops 10000 -absolute-min-iops 4000 -peak-iops-allocation used-space
    qos adaptive-policy-group modify -policy-group aqos- epic-prod2 -expected-iops 6000 -peak-iops 20000 -absolute-min-iops 5000 -peak-iops-allocation used-space
    qos adaptive-policy-group modify -policy-group aqos- epic-bully -expected-iops 3000 -peak-iops 2000 -absolute-min-iops 2000 -peak-iops-allocation used-space

数据生成

LUN 中的数据是使用 Epic Dgen.pl 脚本生成的。该脚本用于创建类似于 Epic 数据库中的数据。

在所有三个 RHEL VM 上运行了以下 dgen 命令:

./dgen.pl --directory "/epic" --jobs 2 --quiet --pctfull 20

运行 Genio

测试了三台服务器。两个以 75 , 000 次恒定 IOPS 运行,代表一个非常大的 Epic 环境。第三台服务器被设置为抢占资源的服务器,将 IOPS 从 75 , 000 次增加到 150 , 000 次。所有这三项测试都同时运行。

服务器 epio_rhel1 Genio 测试

运行以下命令为每个卷分配 EpicProd AQO 设置:

::> vol modify -vserver epic -volume epic_rhel1_* -qos-adaptive-policy-group AqosEpicProd

从服务器 epio-rhel1 运行了以下 Genio 命令:

./RampRun.pl –miniops 75000 --maxiops 75000 --background --disable-warmup --runtime 30 --wijfile /epic/GENIO.WIJ --numruns 10 --system epic-rhel1 --comment Ramp constant 75k

服务器 epio_rhel2 Genio 测试

运行以下命令为每个卷分配 EpicProd AQO 设置:

::> vol modify -vserver epic -volume epic_rhel2_* -qos-adaptive-policy-group AqosEpicProd

从服务器 epio-rhel2 运行了以下 Genio 命令:

./RampRun.pl --miniops 75000 --maxiops 75000 --background --disable-warmup --runtime 30 --wijfile /epic/GENIO.WIJ --numruns 10 --system epic-rhel2 --comment Ramp constant 75k

服务器 epio_rhel3 Genio 测试(抢占资源)

以下命令不会为每个卷分配任何 AQO 策略:

::> vol modify -vserver epic -volume epic_rhel3_* -qos-adaptive-policy-group non

从服务器 epio-rhel3 运行了以下 Genio 命令:

./RampRun.pl --miniops 75000 --maxiops 150000 --background --disable-warmup --runtime 30 --wijfile /epic/GENIO.WIJ --numruns 10 --system epic-rhel3 --comment Ramp 75-150k

AQO 测试结果

以下各节中的表包含每个并发 Genio 测试中 summary.csv 文件的输出。要通过测试,最长写入周期必须低于 45 秒。有效写入延迟必须低于 1 毫秒。

服务器 epio_rhel1 Genio 结果

下表显示了 AQO 服务器 epio_rhel1 的 Genio 结果。

运行 读取 IOPS 写入 IOPS 总 IOPS 最长写入周期(秒) 有效写入延迟(毫秒)

10

55655

18176.

73832

32.66

0.12

11.

55653

18114

73768

34.66

0.1

12

55623

18099

73722

35.17

0.1

13

55646

18093

73740

35.16

0.1

14

55643

18082

73726

35.66

0.1

15

55634

18156.

73791

32.54

0.1

16.

55629

18138.

73767

34.74

0.11

17

55646

18131.

73777

35.81

0.11

18

55639

18136.

73775

35.48

0.11

19

55597

18141.

73739

35.42

0.11

服务器 epio_rhel2 Genio 结果

下表显示了 AQO 服务器 epio_rhel2 的 Genio 结果。

运行 读取 IOPS 写入 IOPS 总 IOPS 最长写入周期(秒) 有效写入延迟(毫秒)

10

55629

18081.

73711

33.96

0.1

11.

55635

18152.

73788

28.59

0.09

12

55606

18154.

73761

30.44

0.09

13

55639

18148

73787

30.37

0.09

14

55629

18145.

73774

30.13

0.09

15

55619

18125 年

73745

30.03 个

0.09

16.

55640

18156.

73796

33.48

0.09

17

55613

18177 年

73790

33.32

0.09

18

55605

18173.

73779

32.11

0.09

19

55606

18178

73785

33.19

0.09

服务器 epio_rhel3 Genio 结果(抢占资源)

下表显示了 AQO 服务器 epio_rhel3 的 Genio 结果。

运行 写入 IOPS 总 IOPS 最长 WIJ 时间(秒) 最长写入周期(秒) 有效写入延迟(毫秒)

10

19980

81207.

21.48

40.05

0.1

11.

21835

88610

17.57

46.32

0.12

12

23657

95955

19.77

53.03

0.12

13

25493

103387

21.93

57.53

0.12

14

27331

110766

23.17

60.57

0.12

15

28893

117906

26.93

56.56

0.1

16.

30704

125233

28.05

60.5

0.12

17

32521

132585

28.43

64.38

0.12

18

34335

139881

30 个

70.38

0.12

19

3636361.

147633

22.78

73.66

0.13

AQO 测试结果分析

上一节的结果表明,服务器 epo_rhel1 和 epo_rhel2 的性能不受 epo_rhel3 上抢占资源的工作负载的影响。epio_rhel3 可将 IOPS 提高到 150 , 000 次,并因其达到控制器的限制而开始使 Genio 测试失败。epo_rhel1 和 epo_rhel2 上的写入周期和延迟保持不变,而抢占资源的服务器则失控。

这说明了 AQO 最低策略如何有效地将工作负载与抢占资源的工作负载隔离并保证最低性能级别。

AQO 具有多种优势:

  • 它支持更加灵活和简化的架构。关键工作负载不再需要孤立,可以与非关键工作负载共存。所有容量和性能均可通过软件进行管理和分配,而不是通过物理隔离来实现。

  • 它可以节省在 ONTAP 集群上运行 Epic 所需的磁盘和控制器数量。

  • 它可以根据性能策略简化工作负载的配置,从而确保性能稳定一致。

  • 您也可以选择实施 NetApp Service Level Manager 来执行以下任务:

    • 创建服务目录以简化存储配置。

    • 提供可预测的服务级别,使您能够始终如一地实现利用率目标。

    • 定义服务级别目标。