SAN ファイバチャネルの構成

ファイバチャネル (FC) は、ほぼ SCSI のためのトランスポートとしてのみ使用されるギガビット速度のネットワークテクノロジです。FC は、アプライアンスでサポートされるいくつかのブロックプロトコルのうちの 1 つです。FC を経由して LUN をシェアするには、アプライアンスにオプションの FC カードが 1 枚以上装着されている必要があります。

デフォルトでは、すべての FC ポートがターゲットモードになるように構成されます。アプライアンスを使用してバックアップ用のテープ SAN に接続する場合は、1 つ以上のポートをイニシエータモードで構成する必要があります。ポートをイニシエータモードで構成するには、アプライアンスをリセットする必要があります。複数のポートを、同時にイニシエータモードで構成できます。

各 FC ポートには WWN (World Wide Name) が割り当てられます。また、ほかのブロックプロトコルと同様に、FC ターゲットを SAN のターゲットグループとイニシエータグループにグループ化し、ポートの帯域幅を特定の LUN または LUN のグループ専用に割り当てることができます。FC ポートがターゲットとして構成されたあとは、リモートで検出されたポートを検証したり、確認したりできます。

Oracle ZFS Storage Appliance を使用した FC SAN ブートソリューションの詳細は、http://www.oracle.com/technetwork/articles/servers-storage-admin/fbsanboot-365291.html にある Oracle Sun ZFS Storage Appliance を使用した FC SAN ブートの実装に関するホワイトペーパーを参照してください。

クラスタでは、イニシエータには各 LUN への 2 つのパス (またはパスのセット) があります。1 つのパス (またはパスのセット) は、その LUN に関連付けられたストレージをインポートしたヘッドになり、もう一方のパス (またはパスのセット) は、そのヘッドのクラスタ化されたピアになります。最初のパス (またはパスのセット) はアクティブであり、2 番目のパス (またはパスのセット) はスタンバイです。テイクオーバーが発生した場合は、アクティブパスが使用不可になり、スタンバイパスが (しばらくして) アクティブに移行されたあと、入出力が続行されます。このマルチパスへのアプローチは、非対称論理ユニットアクセス (ALUA) と呼ばれます。これを ALUA 対応イニシエータと組み合わせると、クラスタテイクオーバーをより高レベルのアプリケーションに対して透過的にすることができます。

イニシエータは、それぞれの WWN で識別されます。ほかのブロックプロトコルと同様に、イニシエータに対して別名を作成できます。FC イニシエータに対する別名を作成しやすくするために、検出されたポートの WWN から WWN を選択できます。また、ほかのブロックプロトコルと同様に、イニシエータをグループに収集できます。LUN が特定のイニシエータグループに関連付けられている場合、その LUN は、そのグループ内のイニシエータからのみ表示できます。ほとんどの FC SAN では、LUN は常に、その LUN が作成されたシステムに対応するイニシエータグループに関連付けられています。

このアプライアンスは、ALUA に準拠したアレイです。ALUA 環境で FC イニシエータを正しく構成するには ALUA 対応ドライバが必要であり、さらにイニシエータ固有のチューニングが必要になる可能性があります。詳細は、Oracle ZFS Storage Appliance: クライアントマルチパスを設定する方法 (Doc ID 1628999.1) を参照してください。

FC のパフォーマンスは分析を通して監視できます。その場合、操作またはスループットをイニシエータ、ターゲット、または LUN ごとに分解できます。

図 2-15  FC のパフォーマンス

また、操作の場合は、オフセット、待機時間、サイズ、および SCSI コマンドごとにも分解できます。これにより、FC 操作の内容だけでなく、その方法や理由についても理解できます。

このアプライアンスは、各ヘッド上の LUN を提供するためにリソースのグローバルなセットを利用するように設計されています。アプライアンス内の FC ポートは多数の並行要求を処理できるため、一般には、クライアント上の待ち行列の深さを制限することは必要ありません。そうであったとしても、これらの待ち行列がオーバーランして、SCSI トランスポートエラーが発生する可能性がわずかに存在します。このような待ち行列のオーバーランは多くの場合、次の状態の 1 つ以上に関連しています。

• フロントエンド上の多重定義されたポート。1 つの FC ポートに関連付けられたホストが多すぎるか、または 1 つの FC ポートを経由してアクセスされる LUN が多すぎる場合

• 縮退したアプライアンス動作モード。アクティブ/アクティブのクラスタ構成になるように設計されている環境でのクラスタテイクオーバーなど

待ち行列のオーバーランの可能性はわずかですが、待ち行列の深さをクライアント単位に積極的に制限すれば、この可能性を完全に解消できます。待ち行列の適切な深さの制限を決定するには、ターゲットポートの数を求め、それにポートあたりの並行コマンドの最大数 (2048) を掛け、さらにその積をプロビジョニングされる LUN の数で割るべきです。縮退した動作モードに対応するには、クラスタピアにまたがる LUN の数を合計して LUN の数を決定するべきですが、ターゲットポートの数には 2 つのクラスタピアのうちの少ない方を取ります。たとえば、アクティブ/アクティブ構成の 7420 デュアルヘッドクラスタで、1 つのヘッドが 2 つの FC ポートと 100 個の LUN を備え、もう一方のヘッドが 4 つの FC ポートと 28 個の LUN を備えている場合は、最悪の事態を考慮した待ち行列の最大の深さを 2 つのポートに 2048 コマンドを掛けて 100 + 28 の LUN で割った値、つまり LUN あたり 32 コマンドにするべきです。

待ち行列の最大の深さのチューニングはイニシエータに固有の作業ですが、Solaris では、大域変数 ssd_max_throttle を調整することによってこれが実現されます。

光学部品の破損や変形、不安定なケーブル配線などのリンクレベルの問題をトラブルシューティングするには、 FC ポートごとのエラー統計情報を調べます。いずれかの数値が 0 から大幅に外れているか、または増加している場合は、リンクレベルの問題が発生していて、リンクレベルの診断の実行が必要なことを示している可能性があります。