SANアーキテクチャはどのように機能し、さらに重要なことに拡張性がありますか？
いくつかのSANインフラストラクチャを理解しようとしています。私よりも経験豊富な方が、SANを使用したスケーリングを理解するのに役立つことを期待していました。
HBAを備えたコンピューターサーバーがあると想像してください。これらは、直接またはスイッチを介してSANコントローラーに接続します。SANコントローラーは、1つ以上のLUNを提供します。これらのLUNは、おそらく上のRAIDアレイにマップされます。ストレージデバイス。
したがって、私が正しく理解していれば、「コントローラー」はパフォーマンスのボトルネックを表しています。多くのパフォーマンスが必要な場合は、独自のストレージに接続するコントローラーをさらに追加し、それらを必要とするサーバーにマップします。
巨大なストレージ容量を備えた非常に高性能なコントローラーと、最大パフォーマンスが低い低パフォーマンスのコントローラーを入手できると思いますか？しかし、スイッチがある場合は、必要に応じて、パフォーマンスの低いコントローラーをネットワークに追加できますか？
間違っている場合は理解を深めてください。ただし、ファブリックが単に「魔法」を表すことなく、HBAをサーバーからストレージに接続する方法を模索しています。
パフォーマンスのボトルネックとしてのコントローラーは非常に真実であり、一部のアーキテクチャーでも単一障害点を表す可能性があります。これはかなり前から知られています。しばらくの間、これを回避するためのベンダー固有の手法がありましたが、それ以来、業界全体がMPIOまたはマルチパスI/Oと呼ばれるものに収束しました。
MPIOを使用すると、ストレージファブリック全体の複数のパスに同じLUNを表示できます。サーバーのHBAとストレージアレイのHBAがそれぞれストレージファブリックへの2つの接続を持っている場合、サーバーはLUNへの4つの別々のパスを持つことができます。ストレージがサポートしている場合は、これを超える可能性があります。大規模なディスクアレイシステムでデュアルコントローラーをセットアップし、各コントローラーがLUNへのアクティブな接続を提供することは非常に一般的です。 2つの別々のHBAカードと、コントローラーとHBAのペアを接続する2つの物理的に別々のパスを備えたサーバーを追加すると、単一障害点のないストレージパスを使用できます。
より洗練されたコントローラーは、実際には完全なアクティブ/アクティブペアになり、両方のコントローラーが実際にストレージと通信します（通常、調整を支援するために、コントローラー間に何らかの形式の共有キャッシュがあります）。中間層デバイスはアクティブ/アクティブのふりをする場合がありますが、実際に作業を実行しているデバイスは1つだけですが、スタンバイコントローラは、最初にサイレントになり、I/O操作がドロップされない場合にすぐに起動できます。下位層のデバイスは単純なアクティブ/スタンバイにあり、すべてのI/Oが1つのパスに沿って進み、アクティブパスが停止したときにのみ他のパスに移動します。
実際、複数のアクティブコントローラーを使用すると、単一のアクティブコントローラーよりも優れたパフォーマンスを提供できます。そして、はい、ストレージにヒットする十分なシステムとコントローラーの背後に十分な高速ストレージを追加すると、接続されているすべてのサーバーが認識できるようにコントローラーを十分に飽和させることができます。これをシミュレートする良い方法は、パリティRAIDボリュームを再構築する必要があるようにすることです。
すべてのシステムがMPIOを利用して複数のactiveパスを使用できるわけではありませんが、それはまだやや新しいことです。また、すべてのコントローラーの側で解決する必要がある問題の1つは、I/Oが入ったパスや、操作を受け取ったコントローラーに関係なく、すべてのI/O操作が順番にコミットされるようにすることです。追加するコントローラーが多いほど、その問題は難しくなります。ストレージI/Oは基本的にシリアル化された操作であり、大規模なパラライズではうまく機能しません。
コントローラを追加することである程度のゲインを得ることができますが、それを完全に機能させるために必要な複雑さが増すため、ゲインは急速に低下します。
パフォーマンスの低いデバイスをギャングしようとする際の問題は、ソフトウェアがストレージにアクセスする方法の性質です。一般的なプログラムはreadリクエストを発行し、read操作のセマンティクスでは、オペレーティングシステムがreadの結果をプロセスに提供する必要があります。一般に、オペレーティングシステムには、そのプロセスまたはスレッドが次に何を必要とするかを知る方法がありません。先読みで推測を試みることはできますが、常に正しいとは限りません。
したがって、多くの平凡なコントローラーを使用しようとすると、平凡なコントローラーがワイヤー上で要求を取得してワイヤーから要求を配信するのに時間がかかるため、待ち時間が長くなります。他のコントローラーがたくさんアイドル状態になっているという事実は、それほど速度を上げません。
ここにはいくつかのアプリケーション依存性があります。一部のワークロードは、さまざまな場所から多数のリクエストを発行するか、非同期ファイル読み取りAPIを使用して、同じスレッドが複数のリクエストを発行してから、いずれかのリクエストが完了するのを待ちます。一部のアプリケーションは先読みの恩恵を大きく受け、多くの待ち時間を取り除きます。ただし、十分に機能する汎用ソリューションが必要な場合は、次に必要なデータを把握する前にコントローラーを待たないように、低レイテンシーを提供するコントローラーが必要です。