日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

ワークロードのテスト

寄稿者

AFF A300 手順の略

AFF A300 HA ペアでは、存在する大規模な Epic インスタンスを快適に実行できます。非常に大規模な Epic インスタンスが 2 つ以上ある場合、 NetApp SPM ツールの結果に基づいて、 AFF A700 の使用が必要になることがあります。

データ生成

エピックの Dgen.pl スクリプトを使用して、 LUN 内のデータが生成されました。このスクリプトは、 Epic データベースと同様のデータを作成するように設計されています。

次の Dgen コマンドは、 RHEL VM 、 Epic rhel1 、 Epic rhel2 から実行しました。

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

「 -pctfull 」はオプションで、データを格納する LUN の割合を定義します。デフォルトは 95% です。サイズはパフォーマンスには影響しませんが、 LUN へのデータの書き込み時間には影響します。

dgen プロセスが完了したら、各サーバーに対して Genio テストを実行できます。

Genio を実行します

2 台のサーバをテストしました。75 、 000 IOPS から 1 、 000 、 000 IOPS への上昇が発生しましたが、これは非常に大規模な Epic 環境を表しています。両方のテストを同時に実行しました。

サーバ epic 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

46442

188929

44.68

0.115

0.66

AFF A700 手順

大規模な Epic 環境、一般に 10 百万件を超えるグローバルリファレンスの場合、お客様は AFF A700 を選択できます。

データ生成

エピックの Dgen.pl スクリプトを使用して、 LUN 内のデータが生成されました。このスクリプトは、 Epic データベースと同様のデータを作成するように設計されています。

3 つすべての RHEL VM で次の Dgen コマンドを実行します。

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

「 -pctfull 」はオプションで、データを格納する LUN の割合を定義します。デフォルトは 95% です。サイズはパフォーマンスには影響しませんが、 LUN へのデータの書き込み時間には影響します。

dgen プロセスが完了したら、各サーバーの Genio テストを実行する準備ができました。

Genio を実行します

3 台のサーバをテストしました。2 台のサーバでは、 75 、 000 IOPS から 10 、 000 IOPS への上昇が発生しました。これは非常に大規模な Epic 環境を表しています。3 台目のサーバは、 75,000 IOPS から 170,000 IOPS に増加する Bully サーバとして設定されています。3 つのテストをすべて同時に実行しました。

サーバ epic 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

AFF A700 での Genio の結果

次の表に、 AFF A700 の Genio の結果を示します。

読み取り IOPS 書き込み IOPS 合計 IOPS 最長書き込みサイクル(秒) 実効書き込みレイテンシ(ミリ秒) 読み取り / 読み取りの平均値(ミリ秒)

241,180

78,654

319,837

43.24

0.09

1.05

AQOS を使用したパフォーマンス SLA

ネットアップでは、 AQOS ポリシーを使用して、ワークロードのパフォーマンス値の下限と上限を設定できます。フロア設定により、最小のパフォーマンスが保証されます。Epic などのアプリケーションでは、ボリュームのグループに IOPS/TB を適用できます。QoS ポリシーに割り当てられた Epic ワークロードが、同じクラスタ上の他のワークロードから保護されています。最小要件が保証されると同時に、ワークロードのピーク時にコントローラ上の利用可能なリソースを使用できるようになります。

このテストでは、サーバ 1 とサーバ 2 を AQOS で保護し、 3 台目のサーバをクラスタ内の原因のパフォーマンス低下に対する Bully ワークロードとして機能させました。AQOS では、サーバ 1 とサーバ 2 が指定された SLA で実行されることが許可されましたが、 Bully ワークロードでは、書き込みサイクルが長くなるとパフォーマンスが低下している兆候が見られました。

アダプティブ QoS のデフォルト

ONTAP には、 Value 、 Performance 、 Extreme の 3 つのデフォルト AQOS ポリシーが用意されています。各ポリシーの値は 'qos' コマンドを使用して表示できますすべての AQOS 設定を表示するには、コマンドの最後に「 -instant 」を使用します。

::> 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

AQOS ポリシーを作成する構文は次のとおりです。

::> 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

AQOS ポリシーには、いくつかの重要な設定があります。

  • * 想定 IOPS 。 * このアダプティブ設定は、ポリシーの最小 IOPS/TB 値です。ワークロードは、少なくともこのレベルの IOPS/TB が保証されます。これは、このテストで最も重要な設定です。この例のテストでは、パフォーマンス AQOS ポリシーは 20TB あたり 2048IOPS/TB に設定しました。

  • * ピーク IOPS 。 * このアダプティブ設定は、ポリシーの最大 IOPS/TB 値です。この例のテストでは、パフォーマンス AQOS ポリシーを TB あたり 4096IOPS/TB に設定しました。

  • * ピーク IOPS の割り当て。 * オプションは割り当てスペースまたは使用済みスペースです。このパラメータは、データベースが LUN のサイズを大きくするにつれて変化するため、使用済みスペースに設定します。

  • * 絶対最小 IOPS 。 * この設定は静的で、アダプティブではありません。このパラメータは、サイズに関係なく最小 IOPS を設定します。この値は、サイズが 1TB 未満で、このテストには影響しない場合にのみ使用されます。

一般に、本番環境の Epic ワークロードは約 1 、 000IOPS/TB のストレージと容量で実行され、 IOPS は直線的に増加します。デフォルトの AQOS パフォーマンスプロファイルは、 Epic ワークロードには十分ではありません。

このテストでは、 5TB 未満の本番サイズのデータベースは反映しませんでした。目標は、各テストを 75 、 000 IOPS で実行することです。EpicProd AQOS ポリシーの設定は次のとおりです。

  • 想定 IOPS/TB = 合計 IOPS / 使用済みスペース

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

次の表に、 EpicProd AQOS ポリシーで使用された設定を示します。

設定 価値

ボリュームサイズ

5TB

必要な IOPS

75,000

peak-iops-allocation のようになります

使用済みスペース

絶対最小 IOPS

7,500

想定 IOPS/TB

15,000

最大 IOPS/TB

30,000

次の図に、使用済みスペースが時間の経過とともに増加するにつれて、下限の IOPS と上限の IOPS がどのように計算されるかを示します。

エラー:グラフィックイメージがありません

本番サイズのデータベースでは、最後の例のようなカスタム AQOS プロファイルを作成するか、デフォルトのパフォーマンス AQOS ポリシーを使用できます。パフォーマンス AQOS ポリシーの設定を次の表に示します。

設定 価値

ボリュームサイズ

75TB

必要な IOPS

75,000

peak-iops-allocation のようになります

使用済みスペース

絶対最小 IOPS

500

想定 IOPS/TB

1,000

最大 IOPS/TB

2,000

次の図に、デフォルトのパフォーマンス AQOS ポリシーで使用されるスペースが時間の経過とともに増加するにつれて、下限と上限の IOPS がどのように計算されるかを示します。

エラー:グラフィックイメージがありません

パラメータ

  • 次のパラメータは、アダプティブポリシーグループの名前を指定します。

         -policy-group <text> - Name

    アダプティブポリシーグループの名前は、英数字、およびアンダースコアとハイフンを使用し、 127 文字以内の一意な名前にする必要があります。アダプティブポリシーグループ名の 1 文字目は英数字でなければなりません。アダプティブ・ポリシー・グループ名を変更するには 'qos adaptive-policy-group rename コマンドを使用します

  • 次のパラメータは、このアダプティブポリシーグループが属するデータ SVM (コマンドラインでは vserver と呼ばれます)を指定します。

         -vserver <vserver name> - Vserver

    このアダプティブポリシーグループは、指定した SVM に含まれるストレージオブジェクトにのみ適用できます。システムに SVM が 1 つしかない場合は、その SVM がデフォルトで使用されます。

  • 次のパラメータは、ストレージオブジェクトの割り当てサイズに基づいて、割り当てられる最小想定 IOPS/TB または IOPS/GB を指定します。

         -expected-iops {<integer>[IOPS[/{GB|TB}]] (default: TB)} - Expected IOPS
  • 次のパラメータは、ストレージオブジェクトの割り当てサイズまたは使用済みサイズに基づいて、割り当て可能な最大 IOPS/TB または割り当て済み IOPS を指定します。

         -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

データ生成

エピック「 gen.pl 」スクリプトを使用して、 LUN 内のデータが生成されました。このスクリプトは、 Epic データベースと同様のデータを作成するように設計されています。

次の Dgen コマンドが、 3 台すべての RHEL VM で実行されました。

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

Genio を実行します

3 台のサーバをテストしました。2 つの IOPS は一定で 75 、 000 IOPS を達成しましたが、これは非常に大きな Epic 環境であるためです。3 台目のサーバは、 75,000 IOPS から 150,000 IOPS に増加する Bully として設定されています。3 つのテストをすべて同時に実行しました。

Server epal_rhel1 Genio テスト

次のコマンドが実行され、各ボリュームに EpicProd AQOS 設定が割り当てられました。

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

サーバ epic 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

Server epal_rhel2 Genio テスト

次のコマンドが実行され、各ボリュームに EpicProd AQOS 設定が割り当てられました。

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

次の Genio コマンドが、サーバ ep-rhel2 から実行されました。

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

サーバ ep_RHEL3 Genio テスト( Bully )

次のコマンドでは、各ボリュームに AQOS ポリシーは割り当てられません。

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

サーバ epic 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

AQOS のテスト結果

以降のセクションの表には、各コンカレント Genio テストの summary.csv ファイルからの出力が含まれています。テストに合格するには、最長の書き込みサイクルが 45 秒未満である必要があります。有効な書き込みレイテンシは 1 ミリ秒未満である必要があります。

Server epal_rhel1 の Genio の結果

次の表に、 AQOS サーバ ep_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

Server epal_rhel2 の Genio の結果

次の表に、 AQOS サーバ ep_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

サーバーの ep_RHEL3 Genio の結果( Bully )

次の表は、 AQOS サーバ ep_RHEL3 の Genio 結果を示しています。

を実行します 書き込み IOPS 合計 IOPS 最長ワイヤ時間(秒) 最長書き込みサイクル(秒) 有効な書き込みレイテンシ(ミリ秒)

10.

19980

81207.

21.48

40.05

0.1

11.

21835 年

88610

17.57

46.32

0.12

12.

23657.

95959555

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

36361

147633

22.78

73.66

0.13

AQOS のテスト結果の分析

前のセクションの結果は、サーバーの epal_rhel1 および epm_rhel2 のパフォーマンスが、 epic _RHEL3 の Bully ワークロードの影響を受けていないことを示しています。Epic RHEL3 は最大 150,000 IOPS を上昇させ、コントローラの制限に達して Genio テストに失敗し始めます。Epic rhel1 と Epic rhel2 での書き込みサイクルとレイテンシーは一定で、 Bully サーバのスパイラルは制御不能です。

これは、 AQOS の最小ポリシーが、ワークロードを Bully から効果的に分離し、最小レベルのパフォーマンスを保証する仕組みを示しています。

AQOS には次のようなメリットがあります。

  • これにより、より柔軟でシンプルなアーキテクチャが実現します。クリティカルなワークロードをサイロ化する必要がなくなり、重要でないワークロードと共存させることができるようになりました。すべての容量とパフォーマンスは、物理的な分離ではなくソフトウェアで管理および割り当てできます。

  • ONTAP クラスタで Epic を実行する際に必要なディスクやコントローラの容量を節約できます。

  • 一貫したパフォーマンスを保証するパフォーマンスポリシーにワークロードを簡単にプロビジョニングできます。

  • 必要に応じて、 NetApp Service Level Manager のを実装し、次のタスクを実行することもできます。

    • ストレージのプロビジョニングを簡易化するサービスカタログを作成

    • 予測可能なサービスレベルを提供することで、利用率の目標を常に達成できます。

    • サービスレベル目標を定義する。