第4章 ストレージサービスのカスタマイズ

director の提供する heat テンプレートコレクションには、基本的な Ceph Storage 設定を有効にするために必要なテンプレートおよび環境ファイルがすでに含まれています。

director は、/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml 環境ファイルを使用して Ceph クラスターを作成し、デプロイ中にこれをオーバークラウドと統合します。このクラスターは、コンテナー化された Ceph Storage ノードを特色とします。OpenStack のコンテナー化されたサービスに関する詳細は、『director のインストールと使用方法』ガイドの「CLI ツールを使用した基本的なオーバークラウドの設定」を参照してください。

Red Hat OpenStack director により、基本的なデフォルト設定もデプロイされた Ceph クラスターに適用されます。また、カスタム環境ファイルに追加された設定はすべて定義する必要があります。

手順

  1. /home/stack/templates/storage-config.yaml ファイルを作成します。この例では、~/templates/storage-config.yaml ファイルには、お使いの環境用のオーバークラウド関連のほとんどのカスタム設定が含まれています。カスタム環境ファイルに追加するパラメーターは、/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml ファイルの対応するデフォルト設定を上書きします。
  2. ~/templates/storage-config.yamlparameter_defaults セクションを追加します。このセクションには、お使いのオーバークラウド用のカスタム設定が含まれます。たとえば、ネットワークサービス (neutron) のネットワーク種別として vxlan を設定するには、以下のスニペットをカスタム環境ファイルに追加します。

    parameter_defaults:
      NeutronNetworkType: vxlan
  3. 必要に応じて、実際の要件に応じて parameter_defaults 配下に以下のオプションを設定します。

    オプション説明デフォルト値

    CinderEnableIscsiBackend

    iSCSI バックエンドを有効にします。

    false

    CinderEnableRbdBackend

    Ceph Storage バックエンドを有効にします。

    true

    CinderBackupBackend

    Ceph または swift をボリュームのバックアップのバックエンドとして設定します。詳細は、「バックアップサービスで Ceph を使用する設定」を参照してください。

    ceph

    NovaEnableRbdBackend

    Nova の一時ストレージ用に Ceph Storage を有効にします。

    true

    GlanceBackend

    Image サービスが使用するバックエンドを定義します。rbd (Ceph)、swift、または file を設定可能です。

    rbd

    GnocchiBackend

    Telemetry サービスが使用するバックエンドを定義します。rbd (Ceph)、swift、または file を設定可能です。

    rbd

    注記

    デフォルト設定を使用する場合には、~/templates/storage-config.yaml からオプションを省くことができます。

カスタム環境ファイルの内容は、以下のセクションで適用する設定により異なります。完全な例は「付録A 環境ファイルのサンプル: Ceph Storage クラスターの作成」を参照してください。

以下のサブセクションでは、director が適用する一般的なデフォルトのストレージサービスの設定を上書きする方法について説明します。

4.1. Ceph Metadata Server の有効化

Ceph Metadata Server (MDS) は ceph-mds デーモンを実行し、CephFS に保管されたファイルに関するメタデータを管理します。CephFS は、NFS を介して使用できます。NFS を介した CephFS の使用に関する詳細は、『File System Guide』および『CephFS via NFS Back End Guide for the Shared File System Service』を参照してください。

注記

Red Hat は、Shared File System サービスの NFS バックエンドを介した CephFS のみを使用した Ceph MDS のデプロイをサポートします。

手順

Ceph Metadata Server を有効にするには、オーバークラウド作成時に以下の環境ファイルを呼び出します。

  • /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-mds.yaml

詳細は、「オーバークラウドデプロイメントの開始」を参照してください。Ceph Metadata Server に関する詳細は、「Configuring Metadata Server Daemons」を参照してください。

注記

デフォルトでは、Ceph Metadata Server はコントローラーノードにデプロイされます。Ceph Metadata Server を専用のノードにデプロイすることができます。詳細は、「Ceph MDS サービス向けのカスタムロールとフレーバーの作成」を参照してください。

4.2. Ceph Object Gateway の有効化

Ceph Object Gateway (RGW) は、Ceph Storage クラスター内のオブジェクトストレージケイパビリティーへのインターフェースを使用してアプリケーションを提供します。RGW をデプロイする際には、デフォルトの Object Storage サービス (swift) を Ceph に置き換えることができます。詳細は、『Object Gateway Configuration and Administration Guide』を参照してください。

手順

デプロイメントで RGW を有効にするには、オーバークラウド作成時に以下の環境ファイルを呼び出します。

  • /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-rgw.yaml

詳細は、「オーバークラウドデプロイメントの開始」を参照してください。

デフォルトでは、Ceph Storage は OSD ごとに 250 の配置グループを許可します。RGW を有効にすると、Ceph Storage は RGW が必要とする追加プールを 6 つ作成します。新しいプールは以下の通りです。

  • .rgw.root
  • default.rgw.control
  • default.rgw.meta
  • default.rgw.log
  • default.rgw.buckets.index
  • default.rgw.buckets.data
注記

デプロイメントでは、default はプールが属するゾーンの名前に置き換えられます。

したがって、RGW を有効にする際には、新しいプールに対応するように CephPoolDefaultPgNum パラメーターを使用して、デフォルトの pg_num を必ず設定してください。Ceph プールの配置グループ数を計算する方法の詳細は、「異なる Ceph プールへのカスタムの属性の割り当て」を参照してください。

デフォルトの Object Storage サービスは、Ceph Object Gateway に直接置き換えられます。したがって、通常 swift を使用するその他すべてのサービスは、swift の代わりに Ceph Object Gateway をシームレスに使い始めることができます (追加設定は必要ありません)。詳細は、『Block Storage Backup Guide』を参照してください。

4.3. 外部の Ceph Object Gateway を使用するための Ceph Object Store の設定

Red Hat OpenStack Platform (RHOSP) director は、外部の Ceph Object Gateway (RGW) を Object Store サービスとして設定することをサポートしています。外部 RGW サービスで認証するには、Identity サービス (keystone) のユーザーとそのロールを確認するように RGW を設定する必要があります。

外部 Ceph Object Gateway の設定方法に関する詳細は、『Ceph Object Gateway ガイドでの Keystone の使用』「Keystone 認証を使用するように Ceph Object Gateway を設定」を参照してください。

手順

  1. カスタム環境ファイル (swift-external-params.yaml 等) に以下の parameter_defaults を追加し、実際のデプロイメントに合わせて値を調整します。

    parameter_defaults:
       ExternalSwiftPublicUrl: 'http://<Public RGW endpoint or loadbalancer>:8080/swift/v1/AUTH_%(project_id)s'
       ExternalSwiftInternalUrl: 'http://<Internal RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
       ExternalSwiftAdminUrl: 'http://<Admin RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
       ExternalSwiftUserTenant: 'service'
       SwiftPassword: 'choose_a_random_password'
    注記

    サンプルコードスニペットには、お使いの環境で使用する値とは異なるパラメーター値が含まれる場合があります。

    • リモート RGW インスタンスがリッスンするデフォルトのポートは 8080 です。外部 RGW の設定方法によっては、ポートが異なる場合があります。
    • オーバークラウドで作成した swift ユーザーは、SwiftPassword パラメーターで定義したパスワードを使用します。rgw_keystone_admin_password を使用し、Identity サービスに対する認証に同じパスワードを使用するように外部 RGW インスタンスを設定する必要があります。
  2. Ceph 設定ファイルに以下のコードを追加して、Identity サービスを使用するように RGW を設定します。変数の値を実際の環境に応じて調整します。

        rgw_keystone_api_version: 3
        rgw_keystone_url: http://<public Keystone endpoint>:5000/
        rgw_keystone_accepted_roles: 'member, Member, admin'
        rgw_keystone_accepted_admin_roles: ResellerAdmin, swiftoperator
        rgw_keystone_admin_domain: default
        rgw_keystone_admin_project: service
        rgw_keystone_admin_user: swift
        rgw_keystone_admin_password: <Password as defined in the environment parameters>
        rgw_keystone_implicit_tenants: 'true'
        rgw_keystone_revocation_interval: '0'
        rgw_s3_auth_use_keystone: 'true'
        rgw_swift_versioning_enabled: 'true'
        rgw_swift_account_in_url: 'true'
    注記

    デフォルトでは、director は Identity サービスに以下のロールとユーザーを作成します。

    • rgw_keystone_accepted_admin_roles: ResellerAdmin, swiftoperator
    • rgw_keystone_admin_domain: default
    • rgw_keystone_admin_project: service
    • rgw_keystone_admin_user: swift
  3. 追加の環境ファイルを指定してオーバークラウドをデプロイします。

    openstack overcloud deploy --templates \
    -e <your environment files>
    -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml
    -e swift-external-params.yaml

4.4. バックアップサービスで Ceph を使用する設定

Block Storage Backup サービス (cinder-backup) は、デフォルトでは無効になっています。Block Storage Backup サービスを有効にするには、以下の手順を実行します。

手順

オーバークラウドの作成時に、以下の環境ファイルを呼び出します。

  • /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml

4.5. Ceph ノード向けの複数のボンディングされたインターフェースの設定

ボンディングされたインターフェースを使用して、複数の NIC を組み合わせ、ネットワーク接続に冗長性を追加します。Ceph ノードに十分な NIC がある場合には、各ノードに複数のボンディングされたインターフェースを作成して冗長化機能を拡張することができます。

これにより、ノードが必要とする各ネットワーク接続にボンディングされたインターフェースの使用が可能となります。これにより、冗長性と各ネットワーク専用の接続の両方が提供されます。

ボンディングされたインターフェースを最も簡単に実装するには、2 つのボンディングを使用して、Ceph ノードが使用する各ストレージネットワークに 1 つずつボンディングを設定します。Ceph ノードが使用するストレージネットワークは以下のとおりです。

フロントエンドストレージネットワーク (StorageNet)
Ceph クライアントはこのネットワークを使用して、対応する Ceph クラスターと対話します。
バックエンドストレージネットワーク (StorageMgmtNet)
Ceph クラスターはこのネットワークを使用して、クラスターの配置グループポリシーに従ってデータのバランスを取ります。詳細は、『Red Hat Ceph Storage Architecture Guide』「Placement Groups (PGs)」を参照してください。

複数のボンディングされたインターフェースを設定するには、新しいネットワークインターフェーステンプレートを作成する必要があります。これは、director が複数のボンディングされた NIC をデプロイするために使用できるサンプルテンプレートを提供しないからです。ただし、director は単一のボンディングされたインターフェースをデプロイするテンプレートは提供します。このテンプレートは /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans/ceph-storage.yaml です。このテンプレートでは、追加の NIC 用に追加のボンディングされたインターフェースを定義することができます。

注記

カスタムインターフェーステンプレートの作成に関する詳細は、『オーバークラウドの高度なカスタマイズ』ガイドの「カスタムネットワークインターフェーステンプレート」を参照してください。

以下のスニペットには、/usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans/ceph-storage.yaml ファイルで定義されている単一のボンディングされたインターフェース用のデフォルトの定義が記載されています。

  type: ovs_bridge // 1
  name: br-bond
  members:
    -
      type: ovs_bond // 2
      name: bond1 // 3
      ovs_options: {get_param: BondInterfaceOvsOptions} 4
      members: // 5
        -
          type: interface
          name: nic2
          primary: true
        -
          type: interface
          name: nic3
    -
      type: vlan // 6
      device: bond1 // 7
      vlan_id: {get_param: StorageNetworkVlanID}
      addresses:
        -
          ip_netmask: {get_param: StorageIpSubnet}
    -
      type: vlan
      device: bond1
      vlan_id: {get_param: StorageMgmtNetworkVlanID}
      addresses:
        -
          ip_netmask: {get_param: StorageMgmtIpSubnet}
1
br-bond という名前の単一のブリッジは、このテンプレートで定義されているボンディングをメンバーとします。この行は、ブリッジの種別 (OVS) を定義しています。
2
br-bond ブリッジの最初のメンバーは、ボンディングされたインターフェース自体で、bond1 という名前が付いています。この行は、bond1 のボンディングの種別を定義しており、これも OVS に指定されています。
3
デフォルトのボンディングの名前は bond1 です。
4
ovs_options のエントリーは、director が特定のボンディングモジュールディレクティブのセットを使用するように指示します。これらのディレクティブは、BondInterfaceOvsOptions に渡されます。これもこのファイルで設定できます。ボンディングモジュールディレクティブの設定に関する詳細は、「ボンディングモジュールのディレクティブの設定」を参照してください。
5
ボンディングの members セクションは、bond1 でボンディングされるネットワークインターフェースを定義します。この例では、ボンディングされるインターフェースは nic2 (プライマリーインターフェースとして設定) と nic3 を使用します。
6
br-bond ブリッジには、他にも 2 つのメンバーが含まれています。これは、フロントエンドストレージネットワーク (StorageNetwork) とバックエンドストレージネットワーク (StorageMgmtNetwork) の両方の VLAN です。
7
device パラメーターは、VLAN が使用しなければならないデバイスを定義します。この例では、両方の VLAN がボンディングされたインターフェース bond1 を使用します。

NIC を少なくとも 2 つ追加すると、ブリッジとボンディングされたインターフェースをもう 1 つ定義できます。次に、VLAN の 1 つを新しいボンディングされたインターフェースに移動できます。これにより、両方のストレージネットワーク接続のスループットと信頼性が向上します。

/usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans/ceph-storage.yaml ファイルをこの目的でカスタマイズする場合には、Red Hat では、デフォルトの OVS (type: ovs_bond) の代わりに Linux ボンディング (type: linux_bond) を使用することを推奨しています。このボンディングの種別は、エンタープライズレベルの実稼働デプロイメントにより適しています。

以下の編集済みスニペットは、bond2 という名前の新しい Linux ボンディングをメンバーとする追加の OVS ブリッジ (br-bond2) を定義します。bond2 インターフェースは、2 つの追加の NIC (nic4nic5) を使用し、バックエンドストレージネットワークトラフィック専用に使用されます。

  type: ovs_bridge
  name: br-bond
  members:
    -
      type: linux_bond
      name: bond1
      bonding_options: {get_param: BondInterfaceOvsOptions} // 1
      members:
        -
          type: interface
          name: nic2
          primary: true
        -
          type: interface
          name: nic3
    -
      type: vlan
      device: bond1
      vlan_id: {get_param: StorageNetworkVlanID}
      addresses:
        -
          ip_netmask: {get_param: StorageIpSubnet}
-
  type: ovs_bridge
  name: br-bond2
  members:
    -
      type: linux_bond
      name: bond2
      bonding_options: {get_param: BondInterfaceOvsOptions}
      members:
        -
          type: interface
          name: nic4
          primary: true
        -
          type: interface
          name: nic5
    -
      type: vlan
      device: bond1
      vlan_id: {get_param: StorageMgmtNetworkVlanID}
      addresses:
        -
          ip_netmask: {get_param: StorageMgmtIpSubnet}
1
bond1 および bond2 は両方とも (OVS ではなく) Linux ボンディングであるため、ovs_options の代わりに bonding_options を使用してボンディングディレクティブを設定します。詳細は、「ボンディングモジュールのディレクティブの設定」を参照してください。

このカスタマイズされたテンプレートの完全な内容は、「付録B カスタムインターフェーステンプレートの例: 複数のボンディングされたインターフェース」を参照してください。

4.5.1. ボンディングモジュールのディレクティブの設定

ボンディングされたインターフェースを追加および設定したら、BondInterfaceOvsOptions パラメーターを使用して各ボンディングされたインターフェースが使用するディレクティブを設定します。この情報は、/usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans/ceph-storage.yaml ファイルの parameters: セクションにあります。以下のスニペットには、このパラメーターのデフォルトの定義 (空欄) を示しています。

BondInterfaceOvsOptions:
    default: ''
    description: The ovs_options string for the bond interface. Set
                 things like lacp=active and/or bond_mode=balance-slb
                 using this option.
    type: string

default: の行に必要なオプションを定義します。たとえば、802.3ad (モード 4) と LACP レート 1 (fast) を使用するには、'mode=4 lacp_rate=1' を以下のように設定します。

BondInterfaceOvsOptions:
    default: 'mode=4 lacp_rate=1'
    description: The bonding_options string for the bond interface. Set
                 things like lacp=active and/or bond_mode=balance-slb
                 using this option.
    type: string

サポートされるその他のボンディングオプションに関する詳細は、『オーバークラウドの高度なカスタマイズ』ガイドの「Open vSwitch ボンディングのオプション」を参照してください。カスタマイズした /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans/ceph-storage.yaml テンプレートの完全な内容は、「付録B カスタムインターフェーステンプレートの例: 複数のボンディングされたインターフェース」を参照してください。