Trident: ontapドライバーは、よりインテリジェントなボリューム配置が必要です

作成日 2017年10月17日  ·  6コメント  ·  ソース: NetApp/trident

ontap-nas-economyドライバーによるflexvolの配置は、よりインテリジェントである必要があります。 次の提案は、大規模な環境に対するお客様のフィードバックに基づいて、出発点として作成されています。

  1. 基になる集計がXパーセントフルまたはYパーセントオーバーサブスクライブになるまで、flexvolでqtreeのみをプロビジョニングし続けるようにTridentを構成できるようにします。

  2. 複数のアグリゲートが定義されている場合は、空き領域が最も多く、オーバーサブスクライブが最も少ないアグリゲートを使用することをお勧めします。

  3. 短期的には#1と#2の方が重要ですが、ある時点で、ノードのヘッドルームを考慮してプロビジョニングを行うことも望ましいでしょう。

enhancement tracked

全てのコメント6件

明確にするために、これらのほとんどはすべてのONTAPドライバに適用されます。 トライデントスケジューラーは間違いなく豊富なターゲット環境です。

これまでに行った多くのやり取りに代わってこのリクエストを+1し、いくつかのアイテムを追加します。 ストレージプール選択ロジックに関するいくつかの機能をよく求められます。

  1. ストレージクラス定義を使用してストレージプールを除外できること。 例:「AFFaggr1とSF QoSポリシーブロンズを除くすべてのフラッシュ(media = ssd)が必要です。」 現在、これを実現する唯一のメカニズムは、逆を実行することです。この場合、除外するストレージプールを除くすべてのストレージプールがストレージクラスで指定されます。

  2. 基盤となるストレージデバイス(ONTAPアグリゲートなど)が任意のレベルの「フル」に達したときに、ストレージプールに対する新しいPVC要求のプロビジョニングを停止するメカニズム。 これは、残りの実際の容量と実際の容量、およびオーバーサブスクリプションの比率/パーセンテージの両方に基づくことができます。

  3. 特定のバックエンドに任意の容量制限を指定できるようにします。 たとえば、ONTAPでは、アグリゲートの実際のサイズに関係なく、Tridentはその容量のXGiBのみを消費できます。 同じ原則がSolidFireにも当てはまりますが、パラダイムはGiBだけでなく、IOPS(具体的にはQoSの最小値)にも拡張できます。

  4. AppDMをバックエンドとして活用します。

  5. サービスレベルマネージャーをバックエンドとして活用します。

  6. ONTAPのパフォーマンス容量をストレージプールの選択メトリックとして組み込みます。

配置ロジックについて説明する場合は、(実際の顧客の要件に基づいて)考慮すべき項目をさらにいくつか追加します。

  • ノード上のボリュームの数(Ontapには超えたくない論理制限があるため)
  • SVMのLIFを保持するノード(最高のパフォーマンスを得るために間接的なデータアクセスを回避するため)
  • ノード/アグリゲートに(アダプティブQoSコンセプトを介して)プロビジョニングされたIOPS

他の人がすでに述べたポイントと組み合わせて、顧客の特定の要件に従って重み付けおよびソートします。

結局、トライデントのカスタマイズ可能なルールエンジンか、他のツールを接続するための柔軟なメカニズムが必要になります。 後で使用することにした場合は、すでに述べたAppDMとNSLMに加えてWFAに投票します。これは、(今日)上記のすべてを採用するカスタムソリューションを構築するのに十分な柔軟性を備えた唯一のツールだからです。考慮すべき項目。

Trident +クラウドマネージャーを一緒に使用すると問題が発生するため、これを+1します。これは、自動的に生成される正しいプールをまだ選択していないためです。

+1同じリクエスト:ポイント用に12ノードのクラスターがあります:SVMのLIFを保持するノード(最高のパフォーマンスのために間接的なデータアクセスを回避するため)

前述のようにフルボリュームプロビジョニングを活用します。

配置ロジックについて説明する場合は、(実際の顧客の要件に基づいて)考慮すべき項目をさらにいくつか追加します。

  • ノード上のボリュームの数(Ontapには超えたくない論理制限があるため)
  • SVMのLIFを保持するノード(最高のパフォーマンスを得るために間接的なデータアクセスを回避するため)
  • ノード/アグリゲートに(アダプティブQoSコンセプトを介して)プロビジョニングされたIOPS

他の人がすでに述べたポイントと組み合わせて、顧客の特定の要件に従って重み付けおよびソートします。

結局、トライデントのカスタマイズ可能なルールエンジンか、他のツールを接続するための柔軟なメカニズムが必要になります。 後で使用することにした場合は、すでに述べたAppDMとNSLMに加えてWFAに投票します。これは、(今日)上記のすべてを採用するカスタムソリューションを構築するのに十分な柔軟性を備えた唯一のツールだからです。考慮すべき項目。

また+1

別のアイデア。 limitAggregateUsageパラメーターは、Tridentによって管理される容量だけでなく、アグリゲートのグローバルな使用状況を調べます。

集約が異なるワークロード間で共有される場合(多くの場合)、このパラメーターはもう少し正確である必要があります。

例:

  • 制限は20%に設定されています
  • aggrはすでに他のワークロードから50%満たされています
    この場合、Tridentはボリュームを作成できません。
    パラメータがトライデントだけが占めるスペースを見ていたら、作成は成功したでしょう。
このページは役に立ちましたか?
0 / 5 - 0 評価