クラスタ化におけるネットワークの考慮点
ネットワークデバイス、データリンク、およびインタフェースに障害が発生しても、クラスタ化サブシステムではコントローラに障害が発生しません。アプライアンスの内部または外部で発生したネットワーク障害から保護するには、IPMP または LACP あるいはその両方を使用する必要があります。可用性に対する包括的なアプローチには、ネットワークの正しい構成、およびネットワーク全体の冗長化計画が必要です。
図 4 ネットワークのクラスタ化
ネットワークインタフェースに静的な 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 の作成など) する必要がある場合です。これを行うには、管理タスクを実行するサービスインタフェースのいずれかを使用するか、一致するプールを管理するためにのみ使用される個別のシングルトンインタフェースを割り当てます。どちらの場合でも、管理に使用されるプールと同じコントローラにインタフェースを割り当てるようにしてください。
NFSv4.1 クライアントへの影響 - クラスタ構成で特定のネットワークを変更すると、NFSv4.1 クライアントに対する要求の保守が悪影響を受ける可能性があります。IP アドレスとその所有者との関係が変更された場合のベストプラクティスは、クライアントからファイルシステムを再マウントすることです。NFSv4.0 とは異なり、NFSv4.1 プロトコルを使用すると、複数の IP アドレス上のクライアント接続を同じ NFSv4.1 プロトコルリースに関連付けることができます。IP アドレスとその所有者との関係が変更されると、相互にフェイルオーバーする IP アドレスのグループが同じでなくなるため、クライアントがファイルシステムを再マウントすることで強制的にリース関係が再確立されます。
関連トピック