5.24.5 OVM RACクラスタ間のInfiniBandパーティションの実装: 制限されたメンバーシップの設定

2016年10月の12.1.0.2データベース・バンドル・パッチでセキュリティ拡張機能が導入され、2016年10月の12.1.0.2バンドル・パッチより前に使用されていた完全なメンバーシップのかわりに、制限されたメンバーシップを使用して、データベース・ノードのGUIDをストレージpkeyに割り当てることができます。これは、ストレージpkeyインタフェースを使用するとあるRACクラスタのあるRACノードが別のRACクラスタのRACノードと通信できるセキュリティ上の問題の対策になります。

完全なメンバーシップと制限されたメンバーシップ

InfiniBandパーティションは、相互の通信を許可されるInfiniBandノードのグループを定義します。InfiniBandパーティションで、マスター・サブネット・マネージャによって管理されるカスタムまたは一意のパーティション・キーを定義して、カスタムのパーティション・キーにメンバーを割り当てます。同じパーティション・キーを持つメンバーのみが相互に通信できます。1つのパーティション・キーのメンバーは、別のパーティション・キーを持つメンバーとは、メンバーシップのタイプにかかわらず、通信できません。1つのクラスタのOVM RACクラスタ・ノードには、クラスタウェア通信用の1つのパーティション・キーと、ストレージ・セルとの通信用の別のパーティション・キーが割り当てられます。このように、RACクラスタのノードは、異なるパーティション・キーが割り当てられた別のRACクラスタのノードとは通信できません。このことは、イーサネットの分野のタグ付けされたVLANと概念的に非常に似ています。

パーティション・キー(pkey)は15ビットの整数で、0x1から0x7FFFの値を持ちます。追加のビットであるメンバーシップ・ビットによって、パーティションのメンバーのメンバーシップが識別されます。メンバーシップは次のとおりです:

  • 完全: メンバーシップ・ビットは1に設定されます。完全なメンバーシップを持つメンバーは、相互に通信できることに加えて、同じパーティション・キー内の制限されたメンバーシップを持つメンバーと通信できます。

  • 制限: メンバーシップ・ビットは0に設定されます。パーティション内の制限されたメンバーシップを持つメンバーは、相互に通信できません。ただし、同じパーティション内の完全なメンバーシップを持つ他のメンバーと通信できます。

pkeyとメンバーシップ・ビットが組み合されて16ビットの整数を構成します。最も重要なビットはメンバーシップ・ビットです。

デフォルトで、InfiniBandサブネット・マネージャは、パーティション・キー0x7FFF (制限されたメンバーシップ)または0xFFFF (完全なメンバーシップ)により識別される単一パーティションを提供します。

HCAポートは、最大で128個のパーティションに参加できます。それぞれのパーティション・キーで新しいIPoIBネットワーク・インタフェースが提供されます。たとえば、パーティション・キー0xa001を持つInfiniBandポート1が新しいネットワーク・インタフェースになります。これらのインタフェースには、ifcfg-<interface>ファイル・パラメータによって意味のある名前が付けられます。

1つのInfiniBandノードを複数のパーティションのメンバーにできます。パケットがデータベース・ノードに到着すると、パケットのパーティション・キー(pkey)がサブネット・マネージャ構成と照合されます。この検証により、データベース・ノードが、それがメンバーになっているパーティションの外部の別のデータベース・ノードと通信できなくなります。

InfiniBandファブリック内のすべてのノードには、/sys/class/infiniband/mlx4_0/ports/[1-2]/pkeysで確認できるパーティション・キーの表があります。ノードのそれぞれのキュー・ペア(QP)には、その表の1つのエントリにマッピングされる索引(pkey)が関連付けられています。QPの送信キューからパケットが送信される場合は、索引付きのpkeyが添付されます。QPの受信キューでパケットを受信した場合は、索引付きのpkeyが受信パケットのものと比較されます。一致しない場合、パケットは警告なしで破棄されます。受信チャネル・アダプタはその到着を認識せず、同様に送信チャネル・アダプタも受信確認を取得しません。送信済パケットは単に失われたパケットとして示されます。受信パケットのpkeyがQPの受信キューの索引付きのpkeyと一致した場合にのみ、ハンドシェイクが行われてパケットが受け入れられ、送信チャネル・アダプタに確認が送信されます。このようにして、同じパーティションのメンバーのみが相互に通信でき、そのパーティションのメンバーではないホスト(つまり、パーティション表にそのpkeyを持たないホスト)とは通信できないようになっています。

次のステップで、2016年10月の12.1.0.2データベース・バンドル・パッチが適用されたpkey対応環境でこの拡張機能を設定する方法について説明します。次で説明するように、考えられるシナリオは2つあります。

ケース1.ローリング形式によるpkey対応環境での機能の実装

このケースでは、すでに2016年10月の12.1.0.2データベース・バンドル・パッチを適用しています。

次のステップを、1回に1つのノードに実行します。

  1. ノードでグリッド・インフラストラクチャを停止します。

    # $GI_HOME/bin/crsctl stop crs

  2. このユーザー・ドメインのOVM RACクラスタ・ノードを管理するdom0 (制御ドメイン)の2つのポートのGUIDを特定します。

    # /usr/sbin/ibstat | grep Port

  3. SMマスターがrootとして実行されているInfiniBandスイッチにログインします。

  4. InfiniBandスイッチで次のコマンドを実行します。

    # /usr/local/sbin/smpartition start

# /usr/local/sbin/smpartition modify -n <storage pkey name> -port <Port GUID1 of the dom0 from step 2> -m limited

# /usr/local/sbin/smpartition modify -n <storage pkey name> -port <Port GUID2 of the dom0 from step 2> -m limited

# /usr/local/sbin/smpartition commit

  5. dom0のこのOVM RACユーザー・ドメイン・ノードのvm.cfgファイルを変更します。

    1. rootとしてdom0にログインします。

    2. /EXAVMIMAGES/GuestImages/<user domain name>/vm.cfgを編集して、次の例に示すようにパーティション・キーを変更します。

      次の行を変更します:

      ib_pkeys = [{'pf':'40:00.0','port':'1','pkey':[ '0xclpkey','0x<stpkey>',]},{'pf':'40:00.0','port':'2','pkey':[ '0xclpkey','0x<stpkey>',]},]

      変更後:

      ib_pkeys = [{'pf':'40:00.0','port':'1','pkey':[ '0xclpkey','0x<mod_stpkey>',]},{'pf':'40:00.0','port':'2','pkey':[ '0xclpkey','0x<mod_stpkey>',]},]

      <mod_stpkey>は、次の式を使用して<stpkey>から導出されます。

      mod_stpkey=$(echo "obase=16;ibase=2;$(expr $(echo "obase=2;ibase=16;$(echo $stpkey|tr [:lower:] [:upper:])"|bc) - 1000000000000000)"|bc|tr [:upper:] [:lower:])

      前述の式の<stpkey>と<mod_stpkey>は、0xの接頭辞なしで指定されています。

  6. ユーザー・ドメインのRACノードの/etc/sysconfig/network-scripts/ifcfg-stib*ファイルを変更します。

    次の式を使用して、これらのファイルのPKEY_IDを編集します。

    mod_stpkey=$(echo "obase=16;ibase=2;$(expr $(echo "obase=2;ibase=16;$(echo $stpkey|tr [:lower:] [:upper:])"|bc) - 1000000000000000)"|bc|tr [:upper:] [:lower:])

    mod_stpkeyが新しいPKEY_IDで、stpkeyが古いPKEY_IDです。

    前述の式の<stpkey>と<mod_stpkey>は、0xの接頭辞なしで指定されています。

  7. ユーザー・ドメインのRACノードの/opt/oracle.cellos/pkey.confを変更します。

    ストレージ・ネットワークpkeyインタフェース(stib*)のPkeyを編集します。

    変更前:

    <Pkey>0xstpkey</Pkey>

    変更後:

    <Pkey>0xmod_stpkey</Pkey>

    mod_stpkeyは、次の式を使用してstpkeyから導出されます。

    mod_stpkey=$(echo "obase=16;ibase=2;$(expr $(echo "obase=2;ibase=16;$(echo $stpkey|tr [:lower:] [:upper:])"|bc) - 1000000000000000)"|bc|tr [:upper:] [:lower:])

    前述の式で使用されているstpkeyとmod_stpkeyは、0xの接頭辞なしで指定されています。

  8. OVM RACユーザー・ドメイン・ノードを再起動します。

    1. rootとしてdom0にログインします。

    2. 次のコマンドを実行します。

      # xm shutdown <user domain name>

# xm create /EXAVMIMAGES/GuestImages/<user domain name>/vm.cfg

  9. クラスタ・ノードでGrid Infrastructureスタックが完全に稼働していることを確認します。

  10. 残りのクラスタ・ノードに対して、1回に1つのノードでこのステップを繰り返します。

ケース2.ローリング形式による2016年10月の12.1.0.2データベース・バンドル・パッチの適用中のpkey対応環境での機能の実装

次のステップを、1回に1つのノードに実行します。

  1. クラスタ・ノードで2016年10月の12.1.0.2データベース・バンドル・パッチを適用します。

  2. パッチが適用されたノードで前述のケース1のステップ1から10を繰り返します。

  3. 次のクラスタ・ノードに進み、前述のステップ1および2を繰り返します。

ノート:

dom0のGUIDが制限されたメンバーシップに変換された後、すべての新しいクラスタのデプロイメントには、2016年10月のデータベース・バンドル・パッチが前提条件として含められるようになります。

親トピック: Oracle ExadataでのOracle VM Oracle RACクラスタ間のInfiniBandパーティションの実装