第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 クラスターに適用されます。また、カスタム環境ファイルに追加された設定はすべて定義する必要があります。
手順
-
/home/stack/templates/
にstorage-config.yaml
ファイルを作成します。この例では、~/templates/storage-config.yaml
ファイルには、お使いの環境用のオーバークラウド関連のほとんどのカスタム設定が含まれています。カスタム環境ファイルに追加するパラメーターは、/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml
ファイルの対応するデフォルト設定を上書きします。 ~/templates/storage-config.yaml
にparameter_defaults
セクションを追加します。このセクションには、お使いのオーバークラウド用のカスタム設定が含まれます。たとえば、ネットワークサービス (neutron
) のネットワーク種別としてvxlan
を設定するには、以下のスニペットをカスタム環境ファイルに追加します。parameter_defaults: NeutronNetworkType: vxlan
必要に応じて、実際の要件に応じて
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 を設定」を参照してください。
手順
カスタム環境ファイル (
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 インスタンスを設定する必要があります。
-
リモート RGW インスタンスがリッスンするデフォルトのポートは
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
追加の環境ファイルを指定してオーバークラウドをデプロイします。
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 (nic4
と nic5
) を使用し、バックエンドストレージネットワークトラフィック専用に使用されます。
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 カスタムインターフェーステンプレートの例: 複数のボンディングされたインターフェース」を参照してください。