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 の設定
ネットワークデバイス、データリンク、およびインタフェースに障害が発生しても、クラスタ化サブシステムではヘッドに障害が発生しません。アプライアンスの内部または外部で発生したネットワーク障害から保護するには、IPMP または LACP あるいはその両方を使用する必要があります。可用性に対する包括的なアプローチには、ネットワークの正しい構成、およびネットワーク全体の冗長化計画が必要です。
図 2-23 ネットワークのクラスタ化
ネットワークインタフェースに静的な IP 構成が含まれる場合は、シングルトンリソースとプライベートリソースのどちらかとして構成できます。DHCP を使用して構成したインタフェースはプライベートにする必要があり、クラスタで DHCP を使用することは推奨されていません。シングルトンリソースとして構成された場合、インタフェースの構築に使用されるすべてのデータリンクおよびデバイスは、一度に 1 つのヘッドでのみアクティブにできます。同様に、フェイルオーバー状態でサービスを提供するには、各ヘッド上の対応するデバイスを同じネットワークに接続する必要があります。この例は前の図で示しています。
ネットワークインタフェースをデバイスおよびデータリンクから構成する場合は、クラスタが正しく動作するように、各シングルトンインタフェースに同じ識別子を使用するデバイス、および両方のヘッドで使用可能な機能が含まれることが重要になります。デバイス識別子はデバイスタイプおよび最初にアプライアンスで検出される順序によって異なるため、クラスタ化されたヘッドに同じハードウェアをインストールする必要があります。両方のヘッドの各スロットには同じハードウェアを装着する必要があり、両方のヘッドにはスロットを同じ順序で装着する必要があります。公認の Oracle 再販業者またはサービス担当者は、これらの要件を満たすハードウェアアップグレードの計画を支援できます。
常に、ルートは明示的に単一のネットワークインタフェースにバインドされます。ルートはリソースマネージャー内でシンビオートとして表現され、バインド先のインタフェースが運用可能なときにのみアクティブにできます。したがって、現在スタンバイモードのインタフェースにバインドされたルート (エクスポート済み) は、そのインタフェースがテイクオーバープロセス中に有効化されるまで無効です。これは、2 つのプールが構成され、共通のサブネットで使用可能にされる場合に重要です。サブネットが、ほかの 1 つ以上のネットワークに到達するためにアプライアンスで使用されるルーターのホームであれば、個別のルート (たとえば、2 番目のデフォルトルート) を構成して、そのサブネットに接続するアクティブおよびスタンバイの各インタフェースにバインドする必要があります。
例:
インタフェース e1000g3 は 'alice' に割り当てられ、e1000g4 は 'bob' に割り当てられています。
各インタフェースは 172.16.27.0/24 ネットワーク内のアドレスを持ち、172.16.27.1 経由で到達可能な 172.16.64.0/22 ネットワーク内のクライアントにサービスを提供するために使用できます。
172.16.27.1 経由で 172.16.64.0/22 に到達するルートを 2 つ作成する必要があります。1 つは e1000g3 にバインドし、もう 1 つは 1000g4 にバインドします。
クラスタ化された各ヘッドに、管理でのみ使用される IP アドレス (ほとんどの場合は専用の管理ネットワーク上にある) を割り当て、インタフェースをプライベートリソースとして指定することはよい方法です。これにより、AKCS_STRIPPED 状態で、フェイルバックの待機中である場合でも、管理ネットワークから動作中のヘッドに到達できるようになります。これが重要なのは、ヘッドはサービスを提供していない場合でも、サービス (LDAP や Active Directory など) が使用中で、ほかのネットワークリソースへのアクセスが必要な場合です。これが現実的でない場合は、システムコンソールを使用してヘッドを管理できるように、信用できるネットワークまたはシリアル端末あるいはその両方にサービスプロセッサを接続する必要があります。
これらのアクションのどちらも実行しない場合は、フェイルバックが完了するまで、新規にブートしたヘッドの管理またはモニターができません。特定のストレージプール用のサービスを提供しているヘッドをモニターまたは管理することが必要な場合があります。これが役立つ可能性が高いのは、ストレージ自体の一部を変更 (シェアプロパティーの変更や新規 LUN の作成など) する必要がある場合です。これを行うには、管理タスクを実行するサービスインタフェースのいずれかを使用するか、一致するプールを管理するためにのみ使用される個別のシングルトンインタフェースを割り当てます。どちらの場合でも、管理に使用されるプールと同じヘッドにインタフェースを割り当てるようにしてください。