iSCSI：ターゲットごとのLUN？
私の質問は特にZFS/COMSTARに関連していますが、一般的にすべてのiSCSIシステムに適用できると思います。
公開するすべてのLUNのターゲットを作成することをお勧めしますか？または、複数のLUNを持つ単一のターゲットを持つことは良い習慣ですか？
どちらのアプローチもパフォーマンスに影響を与えますか？そして、他のアプローチが理にかなっているクロスオーバーポイントはありますか？
ユースケースはVMディスクで、各ディスク（zvol）はLUNです。これまでのところ、VMごとに個別のターゲットを作成しましたが、すべてのLUNを含む単一のターゲットはおそらく管理を大幅に簡素化します...ただし、単一のターゲットごとに数百のLUNが必要になる場合があります（その場合、そのターゲットへの数十のイニシエーター接続が必要になる可能性があります）
ベストプラクティスは、複数のLUNを単一のターゲットにぶら下げることです。合計でいくつのターゲットが変化するか、またそれらのターゲットのうち実際に同じLUNを公開しているターゲットの数も異なります。クライアントが設定するMPIOパスごとに1つのターゲットを推奨する傾向があるため、システムを設定する場合は、少なくとも2つのターゲットが必要になります（ただし、これらは同じターゲットグループとターゲットポータルグループの一部であり、同じビューを提供します-それは完全にiSCSIMPIO用です）。
2つの目標を超える唯一の理由は、一般に、ビジネス、ネットワーク、またはその他のユースケース固有の圧力によってもたらされる論理的な分離のためです。環境のサイズと複雑さにもよりますが、4、8、さらには最大16のターゲットはそれほどクレイジーではありません。 16を超えている場合、特に多くの場合、アーキテクチャに誤りがある可能性が高くなり、専門家に確認を依頼する必要があります。 iSCSI MPIOを使用している場合（そして必須、iSCSI MPIOを使用していない場合、ファイルシステムとNFSに対するzvolsとiSCSIの唯一の主要な勝利が失われ、現在、iSCSI over NFSを使用することのメリットはほとんどなく、デメリットも非常に多いため、通常は偶数のターゲット（2、4、6、8など）が必要であり、各ペアが同じビュー（LUN）を提供します。 。
また、COMSTARは、ビューの処理方法が十分にインテリジェントであるため、ターゲットグループとホストグループを実際に作成して適切に割り当てる限り、単一のターゲットで、実際のLUNIDが存在する可能性のある数十または数百のLUNを提供できることにも注意してください。着信イニシエーター（クライアント）に公開されるのは578などではありませんが、代わりに、すべてのイニシエーターに対して0まで低くなる可能性があります。これは、Linux（特に古いフレーバー）など、検出したすべてのLUNにデバイスを自動検出して割り当てるという厄介な習慣があり、処理できるLUNの最大数があるクライアントOSを扱う場合に重要です。また、最大の「LUN番号」（表示されるLUNの数ではなく、実際のLUN番号自体）もあります。
私はそれを定量化することに時間を費やしたことはありませんが、私の直感的な反応は、128個のLUNを備えた1つのターゲットで感じるのと同じ量の128個のターゲットでそれぞれ1つのLUNを備えたパフォーマンスへの影響を感じるか、わずかに悪いことです。 128ターゲットでのパフォーマンス。間違いなくexpectation by COMSTARは、COMSTAR以前の時代のようにターゲットごとに1つのLUNではなく、複数のLUNを持つターゲットを設定しているということです。
一般的な環境についてのコメントについて：
VMの総数が少ない（100未満、できれば50未満）場合にのみ、VM）ごとに個別のLUNを作成する必要がありますORプールのエクスポート/インポート中にサービスがオフラインの状況でプールのエクスポート/インポートを必要とする高可用性の形式は考慮されていません。
これは、COMSTAR overZFSを介して多数のLUNをエクスポート/インポートして完全に初期化するのにかかる時間と関係があります。 zvolを追加するたびに、インポートする時間がXミリ秒長くなります。数十と大したことではありませんが、1000にスケールアップすると、すぐに顕著な問題が発生します。以前は、3,000を超えるzvolを使用してSun 7410を管理していましたが、これは、クラスタリング機能（基本的に、一方のノードからプールをエクスポートし、もう一方のノードにインポートする）を使用してフェイルオーバーを実行するために15分の大部分を占めていました。 15分間の怪物の場合のように、手動フェイルオーバーを実行する場合）。これは主にデータセットの数によるものであり、さらにそれらはzvolでした。 3,000個のファイルシステム（zvolではない）で繰り返されたまったく同じシナリオは、わずか5分しかかかりませんでした（まだ長いですが、すでに3倍短く、これは数年前です。これらのタスクを完了するための合計時間は、それ以来、ZFSで改善されていますが、ファイルシステムに対するzvolの違いと、完全にインポートしてオンラインになるまでの時間は残っています。最後に確認しました。
これで、セットアップに2つ以上のノードがなく、それらの間で迅速にエクスポートおよびインポートすることが期待される場合、多くのzvolを持たない最大の理由はなくなりました。それでも、あなたの質問に直接関係のない他の多くの理由から、それらの1,000個を特に良いアイデアにすることはできません。それらを分離することで得られる恩恵は、大量のzvolを持つことによって引き起こされる管理上およびパフォーマンス上の問題によっていくらか相殺されます。私のお金では、VMごとに1つのデータセットが必要な場合でも（ええと、特に場合）、代わりにNFSを使用することを強くお勧めします。
複数のターゲットは、潜在的な表面積を増やします。実際、これは、スイッチがストレージに持つリンクの数と、使用する必要がある専用のiSCSIスイッチ間にあるリンクの数によって異なります。
これは、ハッシュと負荷分散、および表示するパスの数と関係があります。理想的には、ターゲットデバイスからネットワークへのリンクが4つある場合、4つのIPアドレスが必要であり、5つ目はターゲットの「検出」に使用される可能性があります。
したがって、唯一の本当の答えは、状況によって異なります。