Red Hat Training
A Red Hat training course is available for Red Hat Ceph Storage
3.2. Red Hat Ceph Storage クラスターのインストール
ceph-ansible
playbook 付きの Ansible アプリケーションを使用して、Red Hat Ceph Storage 3 をインストールします。
本番の Ceph ストレージクラスターは、最低でも 3 台のモニターホストと、複数の OSD デーモンを搭載した 3 台の OSD ノードが必要です。
前提条件
Ansible 管理ノードの root アカウントを使用して、
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.yml.sample site.yml
コピーしたファイルを編集します。
group_vars/all.yml
ファイルを編集します。アンコメントする最も一般的な必須およびオプションのパラメーターについては、以下の表を参照してください。なお、この表にはすべてのパラメーターが含まれているわけではありません。重要カスタムクラスター名の使用はサポートされていないため、
cluster: ceph
パラメーターにceph
以外の値を設定しないでください。表3.1 Ansible の一般的な設定
オプション 値 必須 備考 ceph_origin
repository
またはdistro
またはlocal
はい
repository
値は、新しいリポジトリーで Ceph をインストールすることを意味します。distro
の値は、個別のリポジトリーファイルが追加されず、Linux ディストリビューションに含まれる Ceph のバージョンをすべて取得することを意味します。local
の値は、Ceph バイナリーがローカルマシンからコピーされることを意味します。ceph_repository_type
cdn
またはiso
はい
ceph_rhcs_version
3
はい
ceph_rhcs_iso_path
ISO イメージへのパス
ISO イメージを使用する場合は Yes
monitor_interface
Monitor ノードがリッスンするインターフェイス
MONITOR_INTERFACE
、MONITOR_ADDRESS
、またはMONITOR_ADDRESS_BLOCK
が必要です。monitor_address
Monitor ノードがリッスンするアドレス
monitor_address_block
Ceph のパブリックネットワークのサブネット
ノードの IP アドレスは不明だが、サブネットはわかっている場合に使用します
ip_version
ipv6
IPv6 アドレスを使用している場合は Yes
public_network
IPv6 を使用する場合には、Ceph パブリックネットワークの IP アドレスとネットマスク、または対応する IPv6 アドレス
はい
cluster_network
Ceph クラスターネットワークの IP アドレスとネットマスク
いいえ、デフォルトは
public_network
ですconfigure_firewall
Ansible は適切なファイアウォールルールの設定を試みます
いいえ。値を
true
またはfalse
に設定します。all.yml
ファイルの例は次のようになります。ceph_origin: distro ceph_repository: rhcs ceph_repository_type: cdn ceph_rhcs_version: 3 monitor_interface: eth0 public_network: 192.168.0.0/24
注記必ず
all.yml
ファイルでceph_origin
をdistro
に設定してください。これにより、インストールプロセスで正しいダウンロードリポジトリーが使用されるようになります。注記ceph_rhcs_version
オプションを3
に設定すると、最新バージョンの Red Hat Ceph Storage 3 がプルされます。警告デフォルトでは、Ansible はインストール済みの再起動を試みますが、マスクされた
firewalld
サービスにより、Red Hat Ceph Storage デプロイメントが失敗する可能性があります。この問題を回避するには、all.yml
ファイルでconfigure_firewall
オプションをfalse
に設定します。firewalld
サービスを実行している場合は、all.yml
ファイルでconfigure_firewall
オプションを使用する必要はありません。詳細は、
all.yml
ファイルを参照してください。group_vars/osds.yml
ファイルを編集します。アンコメントする最も一般的な必須およびオプションのパラメーターについては、以下の表を参照してください。なお、この表にはすべてのパラメーターが含まれているわけではありません。重要OSD のインストールには、OSD がインストールされている機器とは異なる物理的な機器を使用してください。オペレーティングシステムと OSD 間で同じデバイスを共有すると、パフォーマンスの問題が発生することになります。
表3.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 インストールガイドの Red Hat Enterprise Linux 用の すべての NVMe Storage の OSDAnsible 設定の設定 または Ubuntu 用のすべての NVMe Storage の OSDAnsible 設定の設定 を参照してください。詳細は、
osds.yml
ファイルのコメントをご覧ください。
デフォルトでは
/etc/ansible/hosts
にある Ansible のインベントリーファイルを編集します。サンプルホストをコメントアウトすることを忘れないでください。[mons]
セクションの下に Monitor のノードを追加します。[mons] MONITOR_NODE_NAME1 MONITOR_NODE_NAME2 MONITOR_NODE_NAME3
[osds]
セクションの下に OSD ノードを追加します。ノードがシーケンシャルなネーミングの場合は、レンジの使用を検討してください。[osds] OSD_NODE_NAME1[1:10]
注記新規インストールの OSD の場合、デフォルトのオブジェクトストア形式は BlueStore です。
オプションで、
devices
およびdedicated_devices
オプションを使用して、OSD ノードが使用するデバイスを指定します。複数のデバイスをリストアップするには、コンマで区切ったリストを使用します。構文
[osds] CEPH_NODE_NAME devices="['DEVICE_1', 'DEVICE_2']" dedicated_devices="['DEVICE_3', 'DEVICE_4']"
例
[osds] ceph-osd-01 devices="['/dev/sdc', '/dev/sdd']" dedicated_devices="['/dev/sda', '/dev/sdb']" ceph-osd-02 devices="['/dev/sdc', '/dev/sdd', '/dev/sde']" dedicated_devices="['/dev/sdf', '/dev/sdg']"
デバイスを指定しない場合は、
osds.yml
ファイルのosd_auto_discovery
オプションをtrue
に設定してください。注記OSD が異なる名前の
デバイス
を使用する場合や、いずれかの OSD でデバイスのいずれかに障害が発生した場合に、devices およびdedicated_devices
パラメーターを使用すると便利です。
必要に応じて、すべてのデプロイメント (ベアメタル または コンテナー 内) ホスト固有のパラメーターを使用する場合は、ホストに固有のパラメーターが含まれるホストファイルで
host_vars
ディレクトリーを作成します。ストレージクラスターに追加される新しい Ceph OSD ノードを
/etc/ansible/host_vars/
ディレクトリーに作成します。構文
touch /etc/ansible/host_vars/OSD_NODE_NAME
例
[root@admin ~]# touch /etc/ansible/host_vars/osd07
ホスト固有のパラメーターで ファイルを更新します。ベアメタル デプロイメントでは、devices: および
dedicated_
セクションをファイルに追加できます。devices:
例
devices: - /dev/sdc - /dev/sdd - /dev/sde - /dev/sdf dedicated_devices: - /dev/sda - /dev/sdb
オプションで、ベアメタルまたはコンテナー内のすべてのデプロイメントで、
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 ルールは失敗します。これは、デフォルトのルールに、定義する必要のあるclass
パラメーターが含まれているためです。注記さらに、上記の手順で説明されているように、カスタムの CRUSH 階層を
host_vars
ディレクトリーの OSD ファイルに追加し、この設定を有効にします。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
次の行を
/etc/ansible/ansible.cfg
ファイルに追加します。retry_files_save_path = ~/
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.yml
注記デプロイメントの速度を増やすには、
--forks
オプションをansible-playbook
に指定します。デフォルトでは、ceph-ansible
はフォークを20
に設定します。この設定では、ノードを同時にインストールします。一度に最大 30 個のノードをインストールするには、ansible-playbook --forks 30 PLAYBOOKFILE
を実行します。管理ノードのリソースが過剰に使用されていないことを確認するために、監視する必要があります。そうである場合は、--forks
に渡される数を減らします。モニターノードの root アカウントを使用して、Ceph クラスターのステータスを確認します。
[root@monitor ~]# ceph health HEALTH_OK
rados
を使用してクラスターが機能していることを確認します。モニターノードから、8 つの配置グループを持つテストプールを作成します。
構文
[root@monitor ~]# ceph osd pool create <pool-name> <pg-number>
例
[root@monitor ~]# ceph osd pool create test 8
hello-world.txt
というファイルを作成します。構文
[root@monitor ~]# vim <file-name>
例
[root@monitor ~]# vim hello-world.txt
オブジェクト名
hello-world
を使用して、hello-world.txt
をテストプールにアップロードします。構文
[root@monitor ~]# rados --pool <pool-name> put <object-name> <object-file>
例
[root@monitor ~]# rados --pool test put hello-world hello-world.txt
テストプールからファイル名
fetch.txt
としてhello-world
をダウンロードします。構文
[root@monitor ~]# rados --pool <pool-name> get <object-name> <object-file>
例
[root@monitor ~]# rados --pool test get hello-world fetch.txt
fetch.txt
の内容を確認してください。[root@monitor ~]# cat fetch.txt
出力は以下のようになります。
"Hello World!"
注記クラスターの状態を確認するだけでなく、
ceph-medic
ユーティリティーを使用して Ceph Storage Cluster を総合的に診断することができます。『Red Hat Ceph Storage 3 管理ガイド』 の「ceph-medic
を使用した Ceph Storage クラスターの診断 」の章を参照してください。