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

ONTAP FlexCacheホットスポット修復ソリューションの設計

共同作成者 netapp-dbagwell

ホットスポットの問題を修正するには、ボトルネックの根本的な原因、自動プロビジョニングされたFlexCacheでは不十分な理由、FlexCacheソリューションを効果的に設計するために必要な技術的な詳細を確認します。高密度FlexCacheアレイ(HDFA)を理解して実装することで、パフォーマンスを最適化し、負荷の高いワークロードのボトルネックを解消できます。

ボトルネックの把握

次に、イメージ( Image )一般的なシングルファイルホットスポットのシナリオを示します。このボリュームは、各ノードにコンスティチュエントが1つだけ含まれるFlexGroupであり、ファイルはノード1に格納されます。

すべてのNASクライアントのネットワーク接続をクラスタ内の異なるノードに分散しても、ホットファイルが存在するボリュームアフィニティを提供するCPUのボトルネックは解消されません。また、ファイルが存在する以外のノードに接続されているクライアントからのコールに、クラスタネットワークトラフィック(イースト/ウェストトラフィック)を導入します。イースト/ウェストトラフィックのオーバーヘッドは通常は小さいですが、ハイパフォーマンスコンピューティングワークロードの場合は少しずつ考慮されます。

図1:FlexGroupの単一ファイルホットスポットのシナリオ

図1:FlexGroupの単一ファイルホットスポットのシナリオ

自動プロビジョニングされたFlexCacheが答えにならない理由

ホットスポットの問題を解決するには、CPUのボトルネックを解消し、できれば東西のトラフィックも解消します。適切に設定されていれば、FlexCacheが役立ちます。

次の例では、FlexCacheがSystem Manager、BlueXP 、またはデフォルトのCLI引数を使用して自動プロビジョニングされます。図1図2最初は同じように見えます。どちらも4ノードの単一コンスティチュエントのNASコンテナです。唯一の違いは、図1のNASコンテナがFlexGroupで、図2のNASコンテナがFlexCacheであることです。各図は同じボトルネックを示しています。つまり、ホットファイルへのアクセスを提供するボリュームアフィニティ用のノード1のCPUと、レイテンシの原因となるイースト/ウェストトラフィックです。自動プロビジョニングされたFlexCacheでは、ボトルネックは解消されません。

図2:自動プロビジョニングFlexCacheのシナリオ

図2:自動プロビジョニングFlexCacheのシナリオ

FlexCacheの構造

ホットスポットの修復のためにFlexCacheを効果的に設計するには、FlexCacheに関する技術的な詳細を理解する必要があります。

FlexCacheは常にスパースFlexGroupです。FlexGroupは複数のFlexVolで構成されます。このFlexVolのことをFlexGroupコンスティチュエントと呼びます。デフォルトのFlexGroupレイアウトでは、クラスタ内のノードごとに1つ以上のコンスティチュエントがあります。コンスティチュエントは抽象化レイヤの下で「縫い合わせ」され、単一の大規模なNASコンテナとしてクライアントに提供されます。ファイルがFlexGroupに書き込まれると、取り込みのヒューリスティックによって、ファイルを格納するコンスティチュエントが決定されます。クライアントのNAS接続を含むコンスティチュエントでも別のノードでもかまいません。すべてが抽象化レイヤの下で動作し、クライアントからは見えないため、この場所は無関係です。

このFlexGroupの理解をFlexCacheに適用してみましょう。FlexCacheはFlexGroup上に構築されているため、に示すように、デフォルトでは、クラスタ内のすべてのノードにコンスティチュエントを含むFlexCacheが1つだけ存在し図1ます。ほとんどの場合、これは素晴らしいことです。クラスタ内のすべてのリソースを利用している。

ただし、ホットファイルの修正には、単一ファイルのCPUとイースト/ウェストトラフィックの2つのボトルネックがあるため、これは理想的ではありません。ホットファイルの各ノードのコンスティチュエントで構成されるFlexCacheを作成した場合、そのファイルはそのうちの1つのコンスティチュエントにのみ配置されます。これは、ホットファイルへのすべてのアクセスを処理するCPUが1つあることを意味します。また、ホットファイルに到達するために必要なイースト/ウェストトラフィックの量も制限する必要があります。

このソリューションは、多数の高密度FlexCachesで構成されています。

高密度FlexCacheの構造

高密度FlexCache(HDF)では、キャッシュされたデータの容量要件が許容される数のノードにコンスティチュエントが配置されます。目的は、キャッシュを単一のノードに配置することです。容量の要件によってそれが不可能になった場合は、コンスティチュエントを少数のノードにしか配置できません。

たとえば、24ノードクラスタでは、次の3つの高密度FlexCachesを使用できます。

  • ノード1~8にまたがるノード

  • ノード9~16にまたがる秒

  • 3分の1はノード17~24にまたがっています。

これら3つのHDFSは、1つの高密度FlexCacheアレイ(HDFA)を構成します。ファイルが各HDF内に均等に分散されている場合、クライアントから要求されたファイルがフロントエンドNAS接続に対してローカルに存在する可能性が8分の1になります。それぞれ2つのノードにまたがる12個のHDFSを使用する場合、ファイルがローカルである可能性は50%です。HDFを1つのノードに縮小して24個のノードを作成できれば、ファイルがローカルであることが保証されます。

この構成により、すべてのEast-Westトラフィックが排除され、最も重要なことは、ホットファイルにアクセスするために24個のCPU/ボリュームアフィニティが提供されることです。