1.2. コンテナーへの Red Hat Ceph Storage Cluster のインストール
ceph-ansible
playbook で Ansible アプリケーションを使用して、Red Hat Ceph Storage 3 をコンテナーにインストールします。
実稼動環境で使用される Ceph クラスターは、通常、10 個以上のノードで設定されます。Red Hat Ceph Storage をコンテナーイメージとしてデプロイするには、Red Hat では、少なくとも 3 つの OSD と 3 つの Monitor ノードで設定される Ceph クラスターを使用することを推奨しています。
Ceph は 1 つのモニターで実行できますが、実稼働クラスターで高可用性を確保するためには、Red Hat は少なくとも 3 つのモニターノードを持つデプロイメントのみをサポートします。
前提条件
Ansible 管理ノードで root ユーザーアカウントを使用して、Red Hat Ceph Storage 3 Tools リポジトリーと Ansible リポジトリーを有効にします。
[root@admin ~]# subscription-manager repos --enable=rhel-7-server-rhceph-3-tools-els-rpms --enable=rhel-7-server-ansible-2.6-rpms
ceph-ansible
パッケージをインストールします。[root@admin ~]# yum install ceph-ansible
手順
指示がない限り、Ansible の管理ノードから以下のコマンドを実行します。
Ansibleのユーザーとして、
ceph-ansible
Playbook で生成された一時的な値をAnsibleが保存するceph-ansible-keys
ディレクトリーを作成します。[user@admin ~]$ mkdir ~/ceph-ansible-keys
root として、
/etc/ansible/
ディレクトリーに/usr/share/ceph-ansible/group_vars
ディレクトリーへのシンボリックリンクを作成します。[root@admin ~]# ln -s /usr/share/ceph-ansible/group_vars /etc/ansible/group_vars
/usr/share/ceph-ansible
ディレクトリーに移動します。[root@admin ~]$ cd /usr/share/ceph-ansible
yml.sample
ファイルのコピーを新たに作成します。[root@admin ceph-ansible]# cp group_vars/all.yml.sample group_vars/all.yml [root@admin ceph-ansible]# cp group_vars/osds.yml.sample group_vars/osds.yml [root@admin ceph-ansible]# cp site-docker.yml.sample site-docker.yml
コピーしたファイルを編集します。
group_vars/all.yml
ファイルを編集します。アンコメントする最も一般的な必須およびオプションのパラメータについては、以下の表を参照してください。なお、この表にはすべてのパラメータが含まれているわけではありません。重要カスタムクラスター名の使用はサポートされていないため、
cluster: ceph
パラメータにceph
以外の値を設定しないでください。表1.1 Ansible の一般的な設定 オプション 値 必要性 備考 monitor_interface
Monitor ノードがリッスンするインターフェイス
MONITOR_INTERFACE
、MONITOR_ADDRESS
、またはMONITOR_ADDRESS_BLOCK
が必要です。monitor_address
Monitor ノードがリッスンするアドレス
monitor_address_block
Ceph のパブリックネットワークのサブネット
ノードの IP アドレスは不明だが、サブネットはわかっている場合に使用します
ip_version
ipv6
IPv6 アドレスを使用している場合は Yes
journal_size
必要なジャーナルのサイズ (MB)
不要
public_network
Ceph パブリックネットワークの IP アドレスとネットマスク
必要
Red Hat Enterprise Linux のインストールガイドのRed Hat Ceph Storage のネットワーク設定の検証 セクション
cluster_network
Ceph クラスターネットワークの IP アドレスとネットマスク
不要
ceph_docker_image
rhceph/rhceph-3-rhel7
、またはローカル Docker レジストリーを使用する場合はcephimageinlocalreg
必要
containerized_deployment
true
必要
ceph_docker_registry
registry.access.redhat.com
、またはローカル Docker レジストリーを使用する場合は<local-host-fqdn>
必要
all.yml
ファイルの例は次のようになります。monitor_interface: eth0 journal_size: 5120 public_network: 192.168.0.0/24 ceph_docker_image: rhceph/rhceph-3-rhel7 containerized_deployment: true ceph_docker_registry: registry.access.redhat.com
詳細は、
all.yml
ファイルを参照してください。group_vars/osds.yml
ファイルを編集します。アンコメントする最も一般的な必須およびオプションのパラメータについては、以下の表を参照してください。なお、この表にはすべてのパラメータが含まれているわけではありません。重要OSD のインストールには、OSD がインストールされている機器とは異なる物理的な機器を使用してください。オペレーティングシステムと OSD 間で同じデバイスを共有すると、パフォーマンスの問題が発生することになります。
表1.2 OSD Ansible 設定 オプション 値 必要性 備考 osd_scenario
collocated
。ログ先行書き込みとキー/値データ (Blue Store) またはジャーナル (File Store) と OSD データに同じデバイスを使用non-collocated
。SSD や NVMe メディアなどの専用デバイスを使用して先行書き込みログとキー/値データ (Blue Store) またはジャーナルデータ(File Store)を保存するためlvm
: OSDデータの保存に論理ボリュームマネージャを使用する場合必要
osd_scenario:non-collocated
、ceph-ansible
を使用する場合、devices
とdedicated_devices
の変数の数が一致することを期待します。たとえば、devices
で 10 個のディスクを指定する場合は、dedicated_devices
で 10 個のエントリーを指定する必要があります。osd_auto_discovery
OSD を自動的に検出する場合は
true
osd_scenario: collocated
を使用している場合は Yesdevices
設定を使用している場合は使用できません。devices
ceph data
が保存されているデバイスのリストデバイスのリストを指定する場合は Yes
osd_auto_discovery
設定を使用する場合は使用できません。osd_scenario
としてlvm
を使用し、devices
オプションを設定する場合、ceph-volume lvm batch
モードは最適化された OSD 構成を作成します。dedicated_devices
ceph journal
が保存されている非コロケーション OSD 専用デバイスのリストosd_scenario: non-collocated
場合は Yes非分割型のデバイスであること
dmcrypt
OSD を暗号化する場合は
true
不要
デフォルトは
false
lvm_volumes
File Store または Blue Store 辞書のリスト
osd_scenario: lvm
使用している場合、ストレージ デバイスがdevices
を使用して定義されている場合は Yes各ディクショナリーには、
data
キー、journal
キー、およびdata_vg
キーが含まれている必要があります。論理ボリュームまたはボリュームグループはすべて、完全パスではなく、名前にする必要があります。data
キーおよびjournal
キーは論理ボリューム (LV) またはパーティションにすることができますが、複数のdata
論理ボリュームに 1 つのジャーナルを使用しないでください。data_vg
キーは、data
論理ボリューム含むボリュームグループである必要があります。必要に応じて、journal_vg
キーを使用して、ジャーナル LV を含むボリュームグループを指定できます (該当する場合)。サポートされているさまざまな構成については、以下の例を参照してください。osds_per_device
デバイスごとに作成する OSD 数。
不要
デフォルトは
1
ですosd_objectstore
OSD の Ceph オブジェクトストアタイプ。
不要
デフォルトは
bluestore
です。もう一つの選択肢は、filestore
です。アップグレードに必要です。以下は、
collocated
、non-collocated
、lvm
の 3つの OSD シナリオを使用した場合のosds.yml
ファイルの例です。指定されていない場合、デフォルトの OSD オブジェクトストアフォーマットは BlueStore です。コロケート済み
osd_objectstore: filestore osd_scenario: collocated devices: - /dev/sda - /dev/sdb
コロケートされていない - BlueStore
osd_objectstore: bluestore osd_scenario: non-collocated devices: - /dev/sda - /dev/sdb - /dev/sdc - /dev/sdd dedicated_devices: - /dev/nvme0n1 - /dev/nvme0n1 - /dev/nvme1n1 - /dev/nvme1n1
コロケートされていない例では、デバイスごとに 1 つずつ、4 つの Blue Store OSD が作成されます。この例では、従来のハードドライブ (
sda
、sdb
、sdc
、sdd
) がオブジェクトデータに使用され、ソリッドステートドライブ (SSD) (/ dev/nvme0n1
、/ dev/nvme1n1
) が Blue Store データベースに使用されて書き込みます-先行書き込みログ。この構成では、/dev/sda
および/dev/sdb
デバイスを/dev/nvme0n1
デバイスとペアにし、/dev/sdc
および/dev/sdd
デバイスを/dev/nvme1n1
デバイスとペアにします。非コロケーション - Filestore
osd_objectstore: filestore osd_scenario: non-collocated devices: - /dev/sda - /dev/sdb - /dev/sdc - /dev/sdd dedicated_devices: - /dev/nvme0n1 - /dev/nvme0n1 - /dev/nvme1n1 - /dev/nvme1n1
LVM simple
osd_objectstore: bluestore osd_scenario: lvm devices: - /dev/sda - /dev/sdb
または
osd_objectstore: bluestore osd_scenario: lvm devices: - /dev/sda - /dev/sdb - /dev/nvme0n1
これらの単純な構成では
ceph-ansible
はバッチモード (ceph-volume lvm batch
) を使用して OSD を作成します。最初のシナリオでは、
devices
を従来のハードドライブまたは SSD の場合には、デバイスごとに OSD が 1 つ作成されます。2 つ目のシナリオでは、従来のハードドライブと SSD が混在している場合、データは従来のハードドライブ (
sda
、sdb
) に配置され、BlueStore データベース (block.db
) は SSD (nvme0n1
) にできる限り大きく作成されます。LVM advance
osd_objectstore: filestore osd_scenario: lvm lvm_volumes: - data: data-lv1 data_vg: vg1 journal: journal-lv1 journal_vg: vg2 - data: data-lv2 journal: /dev/sda data_vg: vg1
または
osd_objectstore: bluestore osd_scenario: lvm lvm_volumes: - data: data-lv1 data_vg: data-vg1 db: db-lv1 db_vg: db-vg1 wal: wal-lv1 wal_vg: wal-vg1 - data: data-lv2 data_vg: data-vg2 db: db-lv2 db_vg: db-vg2 wal: wal-lv2 wal_vg: wal-vg2
これらの事前シナリオ例では、事前にボリュームグループと論理ボリュームを作成しておく必要があります。それらは
ceph-ansible
によって作成されません。注記すべての NVMe SSD を使用する場合は、
osd_scenario: lvm
とosds_per_device:4
オプション。詳細については、Red Hat Ceph Storage Container Guide の Configuring OSD Ansible settings for all NVMe Storage セクションを参照してください。詳細は、
osds.yml
ファイルのコメントをご覧ください。
デフォルトでは
/etc/ansible/hosts
にある Ansible のインベントリファイルを編集します。サンプルホストをコメントアウトすることを忘れないでください。[mons]
セクションの下に Monitor のノードを追加します。[mons] <monitor-host-name> <monitor-host-name> <monitor-host-name>
[osds]
セクションの下に OSD ノードを追加します。ノードがシーケンシャルなネーミングの場合は、レンジの使用を検討してください。[osds] <osd-host-name[1:10]>
注記新規インストールの OSD の場合、デフォルトのオブジェクトストア形式は BlueStore です。
または、
mons
セクションとosds
セクションの下に同じノードを追加することで、1 つのノードに OSD デーモンと一緒にモニターを配置することもできます。詳細は、2章コンテナー化された Ceph デーモンのコロケーション を参照してください。
オプションで、ベアメタルまたはコンテナー内のすべてのデプロイメントで、
ansible-playbook
を使用してカスタム CRUSH 階層を作成できます。Ansible のインベントリーファイルを設定します。
osd_crush_location
パラメーターを使用して、OSD ホストを CRUSH マップの階層内のどこに配置するかを指定します。OSD の場所を指定するために、2 つ以上の CRUSH バケットタイプを指定し、1 つのバケットのtype
をホストに指定する必要があります。デフォルトでは、これには、root
、datacenter
、room
、row
、pod
、pdu
、rack
、chassis
およびhost
が含まれます。構文
[osds] CEPH_OSD_NAME osd_crush_location="{ 'root': ROOT_BUCKET_', 'rack': 'RACK_BUCKET', 'pod': 'POD_BUCKET', 'host': 'CEPH_HOST_NAME' }"
例
[osds] ceph-osd-01 osd_crush_location="{ 'root': 'default', 'rack': 'rack1', 'pod': 'monpod', 'host': 'ceph-osd-01' }"
crush_rule_config
パラメーターとcreate_crush_tree
パラメーターをTrue
に設定し、デフォルトの CRUSH ルールを使用しない場合は、少なくとも 1 つの CRUSH ルールを作成します。たとえば、HDD デバイスを使用している場合は、次のようにパラメーターを編集します。crush_rule_config: True crush_rule_hdd: name: replicated_hdd_rule root: root-hdd type: host class: hdd default: True crush_rules: - "{{ crush_rule_hdd }}" create_crush_tree: True
SSD デバイスを使用している場合は、以下のようにパラメーターを編集してください。
crush_rule_config: True crush_rule_ssd: name: replicated_ssd_rule root: root-ssd type: host class: ssd default: True crush_rules: - "{{ crush_rule_ssd }}" create_crush_tree: True
注記ssd と hdd の両方の OSD がデプロイされていない場合、デフォルトの CRUSH ルールは失敗します。これは、デフォルトのルールに、定義する必要のあるクラスパラメーターが含まれているためです。
注記この構成を機能させるには、以下の手順で説明するように、host_vars ディレクトリーの OSD ファイルにもカスタム CRUSH 階層を追加します。
group_vars/clients.yml
ファイルで作成したcrush_rules
を使用してpools
を作成します。例
copy_admin_key: True user_config: True pool1: name: "pool1" pg_num: 128 pgp_num: 128 rule_name: "HDD" type: "replicated" device_class: "hdd" pools: - "{{ pool1 }}"
ツリーを表示します。
[root@mon ~]# ceph osd tree
プールを検証します。
# for i in $(rados lspools);do echo "pool: $i"; ceph osd pool get $i crush_rule;done pool: pool1 crush_rule: HDD
ベアメタル またはコンテナー内 のすべてのデプロイメントで、Ansible インベントリーファイル (デフォルトでは
/etc/ansible/hosts
ファイル) を編集するために開きます。例のホストをコメントアウトします。[mgrs]
セクションに Ceph Manager (ceph-mgr
) ノードを追加します。Ceph Manager デーモンを Monitor ノードにコロケーションします。[mgrs] <monitor-host-name> <monitor-host-name> <monitor-host-name>
Ansible ユーザーとして、Ansible が Ceph ホストに到達できることを確認します。
[user@admin ~]$ ansible all -m ping
root
として、/var/log/ansible/
ディレクトリーを作成し、ansible
ユーザーに適切な権限を割り当てます。[root@admin ~]# mkdir /var/log/ansible [root@admin ~]# chown ansible:ansible /var/log/ansible [root@admin ~]# chmod 755 /var/log/ansible
次のように
log_path
値を更新して、/usr/share/ceph-ansible/ansible.cfg
ファイルを編集します。log_path = /var/log/ansible/ansible.log
Ansible ユーザーとして、
/usr/share/ceph-ansible/
ディレクトリーに移動します。[user@admin ~]$ cd /usr/share/ceph-ansible/
ceph-ansible
Playbook を実行します。[user@admin ceph-ansible]$ ansible-playbook site-docker.yml
注記Red Hat Ceph Storage を Red Hat Enterprise Linux Atomic Host ホストにデプロイする場合は、
--skip-tags=with_pkg
オプションを使用します。[user@admin ceph-ansible]$ ansible-playbook site-docker.yml --skip-tags=with_pkg
注記デプロイメントの速度を増やすには、
--forks
オプションをansible-playbook
に指定します。デフォルトでは、ceph-ansible
はフォークを20
に設定します。この設定では、ノードを同時にインストールします。一度に最大 30 個のノードをインストールするには、ansible-playbook --forks 30 PLAYBOOKFILE
を実行します。管理ノードのリソースが過剰に使用されていないことを確認するために、監視する必要があります。そうである場合は、--forks
に渡される数を減らします。モニターノードの root アカウントを使用して、Ceph クラスターのステータスを確認します。
docker exec ceph-<mon|mgr>-<id> ceph health
以下を置き換えます。
-
<id>
を Monitor ノードのホスト名に置き換えます。
以下は例になります。
[root@monitor ~]# docker exec ceph-mon-mon0 ceph health HEALTH_OK
-