Oracle ZFS Storage Appliance の概要
Oracle ZFS Storage Appliance の構成
BUI を使用した LACP 集計リンクインタフェースの作成
プローブベースのリンク状態障害検出を使用した IPMP グループの作成
リンク状態のみの障害検出を使用した IPMP グループの作成
BUI を使用した InfiniBand パーティションのデータリンクとインタフェースの作成
BUI を使用したクラスタ化されたコントローラでの VLAN ID なしの VNIC の作成
BUI を使用したクラスタ化されたコントローラでの同じ VLAN ID の VNIC の作成
CLI を使用したマルチホーミングプロパティーの「厳しい」への変更
BUI を使用した LUN と FC イニシエータグループの関連付け
CLI を使用した LUN と FC イニシエーターグループの関連付け
CLI を使用したイニシエータとイニシエータグループの別名のスクリプト作成
CLI を使用した自動生成の IQN を持つ iSCSI ターゲットの追加
CLI を使用した RADIUS 認証を使用する特定の IQN を持つ iSCSI ターゲットの追加
CLI を使用した CHAP 認証を使用する iSCSI イニシエータの追加
BUI を使用した、ダッシュボードの表示のみが可能なユーザーの追加
Oracle ZFS Storage Appliance の設定
テイクオーバーおよびフェイルバックの最中には間隔があり、この間はストレージへのアクセスをクライアントに提供できません。この間隔の長さは構成によって異なり、クライアントに与える正確な影響は、データアクセスに使用しているプロトコルに依存します。これらの影響を理解して緩和することにより、正常なクラスタ配備と最悪のタイミングでのコストのかかる障害とを区別できるようになります。
一般に、NFS (すべてのバージョン) クライアントは機能停止をアプリケーションソフトウェアから非表示にします。これにより、サーバーが使用不可の間は I/O 操作が遅延します。NFSv2 および NFSv3 は、サービス復元のほぼ直後に回復するステートレスプロトコルです。NFSv4 は起動時にクライアント猶予期間を組み込み、一般にこの間は I/O を実行できません。Oracle ZFS Storage Appliance では、この猶予期間を調整できます (図を参照)。猶予期間を短縮すると、テイクオーバーまたはフェイルバックあるいはその両方の明らかな影響が少なくなります。計画的な停止の場合、Oracle ZFS Storage Appliance は、NFSv4 クライアントに対して猶予なしの回復を提供するため、猶予期間の遅延が回避されます。猶予なしの回復の詳細は、NFS プロパティーの猶予期間プロパティーを参照してください。
図 2-28 クラスタの猶予期間
サービス中断中の iSCSI 動作はイニシエータに依存しますが、一般に、サービスがクライアント固有のタイムアウト期間内に復元されると、イニシエータは回復します。詳細は、イニシエータのドキュメントを確認してください。一般に、iSCSI ターゲットはテイクオーバーの完了直後に、追加の遅延なしでサービスを提供できます。
SMB、FTP、および HTTP/WebDAV はコネクション型のプロトコルです。これらのサービスに関連付けられたセッション状態は、基になるストレージおよびネットワーク接続とともに転送できないため、これらのプロトコルのいずれかを使用するすべてのクライアントはテイクオーバーまたはフェイルバック中に切断され、操作の完了後に再接続する必要があります。
複数の要素でテイクオーバー時間 (およびこれに密接に関連するフェイルバック時間) が影響を受けますが、大部分の構成で、これらの時間はディスクセットリソースのインポートに必要な時間で占められます。ディスクセットごとの一般的なインポート時間は、15 秒から 20 秒の範囲です (ディスクセット数にリニアに比例します)。半分のディスクシェルフのディスクベイがストレージプールに取り込まれて割り当てられた場合、ディスクセットは 1 つのディスクシェルフの半分で構成されます。未割り当てのディスクおよび空のディスクベイは、テイクオーバー時間に影響を与えません。ディスクセットリソースのインポートにかかる時間は、管理者によって調整または変更可能なパラメータの影響を受けません。したがって、クラスタ化された配備を計画している管理者は、次のいずれかを行うようにしてください。
関連するテイクオーバー時間をクライアントが許容できるように、インストール済みのストレージを制限する
予測される最大テイクオーバー時間を超えるようにクライアント側タイムアウト値を調整する。
通常はディスクセットのインポートは大部分がテイクオーバー時間で構成されますが、唯一の要素ではないことに注意してください。プールのインポートプロセス中に、インテントログの記録を再実行する必要があり、各シェアおよび LUN は適切なサービスを使用してシェアする必要があります。単一のシェアまたは LUN におけるこれらのアクティビティーの実行に必要な時間の合計は、非常に短い時間 (数十ミリ秒程度) ですが、シェア数が多くなると、テイクオーバー時間に大きく影響する可能性があります。したがって、シェア数を比較的少なく (数千個以下に) 保持すると、これらの時間を大幅に短縮できます。
通常、どのような構成でも、フェイルバック時間はテイクオーバー時間よりも長くなります。これは、フェイルバックが次のような 2 段階の操作であるためです。まず、ソースアプライアンスが、割り当てられた所有者以外のすべてのリソースをエクスポートします。次にターゲットアプライアンスが、独自に割り当てられたリソースでのみ標準テイクオーバー手順を実行します。したがって、障害発生時には、常にヘッド A からヘッド B へのフェイルバックの方がヘッド B からヘッド A へのテイクオーバーよりも時間がかかります。この追加のフェイルバック時間は、テイクオーバー時間に比べるとエクスポートされるディスクセットの数に依存しません。したがって、シェアおよび LUN の数を少なく維持すると、フェイルバックへの影響はテイクオーバーよりも大きくなる可能性があります。フェイルバックは常に管理者によって開始される点に留意することも重要です。したがって、フェイルバックにより発生するサービス中断が長くなる場合は、業務の混乱がもっとも少ない時間にスケジュールできます。
注: このセクションに記載した推定時間は、ソフトウェア/ファームウェアバージョン 2009.04.10,1-0 の場合のものです。その他のバージョンでの実行は異なり、実際のパフォーマンスは異なる可能性があります。クラスタ化されたアプライアンスを本番環境に配備する前に、テイクオーバーおよびクライアントアプリケーションへの正確な影響をテストすることが重要です。