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

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

共同作成者 netapp-dbagwell netapp-lenida

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

ボトルネックを理解する

次の画像は、典型的な単一ファイルのホットスポット シナリオを示しています。ボリュームは、ノードごとに1つのコンスティチュエントを持つFlexGroupであり、ファイルはノード1に存在します。

NASクライアントのネットワーク接続をすべてクラスター内の異なるノードに分散させた場合でも、ホットファイルが存在するボリュームアフィニティを処理するCPUでボトルネックが発生します。また、ファイルが存在するノード以外のノードに接続しているクライアントからの呼び出しによって、クラスター ネットワーク トラフィック(East-Westトラフィック)が発生します。East-Westトラフィックのオーバーヘッドは通常は小さいですが、ハイパフォーマンス コンピューティングのワークロードでは、わずかな影響も無視できません。

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

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

自動プロビジョニングされたFlexCacheが解決策ではない理由

ホットスポットを解決するには、CPUボトルネックを排除し、可能であれば東西トラフィックも排除します。FlexCacheは、適切に設定すれば役立ちます。

以下の例では、FlexCacheはSystem Manager、NetApp Console、またはデフォルトのCLI引数を使用して自動プロビジョニングされています。図1図2は一見同じように見えます。どちらも4ノードの単一構成NASコンテナです。唯一の違いは、図1のNASコンテナがFlexGroupであり、図2のNASコンテナがFlexCacheであることです。どちらの図も同じボトルネックを示しています:ホット ファイルへのアクセスを提供するボリューム アフィニティに使用されるノード1のCPU、およびレイテンシに影響を与えるEast-Westトラフィックです。自動プロビジョニングされたFlexCacheでは、このボトルネックは解消されていません。

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

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

FlexCacheの構造

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

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

FlexGroupに関するこの理解をFlexCacheに適用してみましょう。FlexCacheはFlexGroup上に構築されているため、デフォルトでは図1に示すように、クラスタ内のすべてのノードに構成要素を持つ単一のFlexCacheが存在します。ほとんどの場合、これは素晴らしいことです。クラスタ内のすべてのリソースを活用していることになります。

しかし、ホットファイルの修復には、2つのボトルネック(単一ファイルのCPUと東西トラフィック)があるため、この方法は理想的ではありません。ホットファイル用に各ノードに構成要素を持つFlexCacheを作成した場合、そのファイルは構成要素の1つにのみ保存されます。つまり、ホットファイルへのすべてのアクセスを処理するCPUは1つということになります。また、ホットファイルに到達するために必要な東西トラフィック量を制限することも重要です。

このソリューションは、高密度のFlexCachesのアレイです。

高密度FlexCacheの構造

高密度FlexCache(HDF)では、キャッシュされたデータの容量要件で許容される限り、できるだけ少ないノードに構成要素を配置します。目標は、キャッシュを単一のノードに配置することです。容量要件によってそれが不可能な場合は、代わりに少数のノードにのみ構成要素を配置できます。

例えば、24ノードクラスタには、3つの高密度FlexCachesを持つことができます:

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

  • ノード9~16にまたがる2つ目

  • 3番目はノード17~24にまたがる

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

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