パスが多すぎると FC パフォーマンスに影響します

パスが多すぎると FC パフォーマンスに影響します

パスが多すぎると、ストレージ インフラストラクチャのパフォーマンスに影響が出る可能性があると聞きました。その理由を誰か教えていただけますか?

これは、単一のサーバーのパスの数に関するものではなく、インフラストラクチャ全体、つまり FC スイッチやストレージ アレイなどにどのような影響があるかを検討したものです。

以前勤めていた会社では、SAN/スイッチ/バックエンド ストレージ アレイのパフォーマンスが低下したため、パスの数を減らすプロジェクトがあったことを覚えています (詳細は覚えていませんが、Brocade スイッチを使用していて、EMC ストレージ アレイから NetApp に移行していました)。

グーグルでちょっと検索しても、あまり結果は得られませんでした。私たちの DBA チームは、Oracle バックエンド用に 5Gb の投票ディスクを 20 個要求しており、管理オーバーヘッドは別として、パフォーマンスにも影響が出る可能性があると考えました。

答え1

残念ながら、この記事をお勧めすることはできませんが、すでに良い情報源を見つけられていることを願っています。そうでない場合は、この件に関して私が覚えていることをここに記します。

  • 私の記憶では、非常に多数のスイッチがあり、それらがフルメッシュ トポロジを使用して接続されている場合、Brocade SAN で ISL の数が多すぎるという非常にまれな問題が発生することがあります。間違っているかもしれませんが、これは FSPF がすべてのパスを列挙できない場合に関連していました。現在では実際に起こっているかどうかはわかりません。

  • スイッチで制限的な In-Order Delivery (IOD) ポリシーが有効になっている場合、パス番号の制限は歓迎されると思います。ただし、IOD が有効になっている場合、順序が乱れたフレーム (ISL フラッピングなどによる) や、それを許容できないデバイスの問題に既に直面しているものの、現状のままでいる必要があります (たとえば、リモート サイトへのパスが長いため)。

  • 通常、ストレージ システムでは、シーケンシャル操作の方が高速に処理されます。そのため、アレイはシーケンシャルな読み取り/書き込み操作を検出して適切なアルゴリズムを有効にし、パフォーマンスを向上させようとします。同じ LUN へのパスが多すぎると、ストレージ システムが混乱し、シーケンシャル最適化を適用せずにランダム IO のように処理し始めることがあります。

関連情報