コンテナーガイド

PDF

Red Hat Ceph Storage 3

コンテナーへの Red Hat Ceph Storage のデプロイと管理

概要

このドキュメントでは、Red Hat Ceph Storage をコンテナーにデプロイして管理する方法について説明します。

第1章コンテナーへの Red Hat Ceph Storage のデプロイ

この章では、Ansible アプリケーションと ceph-ansible Playbook を使用して Red Hat Ceph Storage 3 をコンテナーにデプロイする方法について説明します。

Red Hat Ceph Storage をインストールするには、「コンテナーへの Red Hat Ceph Storage Cluster のインストール」を参照してください。
Ceph Object Gatewayをインストールするには、「コンテナーへの Ceph Object Gateway のインストール」を参照してください。
メタデータサーバをインストールするには、「メタデータサーバーのインストール」を参照してください。
Ansibleの --limit オプションについては、「limit オプションについて」を参照してください。

1.1. 前提条件

有効なカスタマーサブスクリプションを取得します。
クラスタノードの準備各ノードで以下を行います。

1.1.1. Red Hat Ceph Storage ノードの CDN への登録とサブスクリプションのアタッチ

各 Red Hat Ceph Storage (RHCS) ノードをコンテンツ配信ネットワーク (CDN) に登録し、ノードがソフトウェアリポジトリーにアクセスできるように適切なサブスクリプションを割り当てます。各 RHCS ノードは、Red Hat Enterprise Linux 7 のベースコンテンツとエクストラリポジトリのコンテンツに完全にアクセスできる必要があります。

前提条件

有効な Red Hat サブスクリプション
RHCS のノードは、インターネットに接続できる必要があります。
インストール中にインターネットにアクセスできない RHCS ノードの場合、最初にインターネットにアクセスできるシステムで次の手順を実行する必要があります。
1. ローカル Docker レジストリーを起動します。
```
# docker run -d -p 5000:5000 --restart=always --name registry registry:2
```
2. Red Hat Customer Portal から Red Hat Ceph Storage 3.x イメージをプルします。
```
# docker pull registry.access.redhat.com/rhceph/rhceph-3-rhel7
```
3. イメージにタグを付けます。
```
 # docker tag registry.access.redhat.com/rhceph/rhceph-3-rhel7 <local-host-fqdn>:5000/cephimageinlocalreg
```
  <local-host-fqdn> をローカルホストの FQDN に置き換えます。
4. イメージを、起動したローカルの Docker レジストリーにプッシュします。
```
# docker push <local-host-fqdn>:5000/cephimageinlocalreg
```
  <local-host-fqdn> をローカルホストの FQDN に置き換えます。

手順

ストレージクラスター内のすべてのノードで root ユーザーとして以下の手順を実行します。

ノードを登録する。プロンプトが表示されたら、Red Hat カスタマーポータルの認証情報を入力します。
```
# subscription-manager register
```
CDN から最新のサブスクリプションデータをプルします。
```
# subscription-manager refresh
```
Red Hat Ceph Storage で利用可能なサブスクリプションの一覧を表示します。
```
# subscription-manager list --available --all --matches="*Ceph*"
```
適切なサブスクリプションを特定し、プール ID を取得します。
サブスクリプションを割り当てます。
```
# subscription-manager attach --pool=$POOL_ID
```
置き換え
$POOL_ID を、直前の手順で特定されたプール ID に置き換えます。

デフォルトのソフトウェアリポジトリーを無効にします。次に、Red Hat Enterprise Linux 7 Server、Red Hat Enterprise Linux 7 Server Extras、および RHCS リポジトリーを有効にします。

# subscription-manager repos --disable=*
# subscription-manager repos --enable=rhel-7-server-rpms
# subscription-manager repos --enable=rhel-7-server-extras-rpms
# subscription-manager repos --enable=rhel-7-server-rhceph-3-mon-els-rpms
# subscription-manager repos --enable=rhel-7-server-rhceph-3-osd-els-rpms
# subscription-manager repos --enable=rhel-7-server-rhceph-3-tools-els-rpms

システムを更新して、最新のパッケージを受け取ります。
```
# yum update
```

1.1.2. `sudo` アクセスのある Ansible ユーザーの作成

Ansible は、ソフトウェアをインストールし、パスワードを要求せずに設定ファイルを作成するための root 権限を持つユーザーとして、すべての Red Hat Ceph Storage (RHCS) ノードにログインできる必要があります。Ansible を使用して Red Hat Ceph Storage クラスターをデプロイおよび設定する際に、ストレージクラスター内のすべてのノードにパスワードなしの root アクセスで Ansible ユーザーを作成する必要があります。

前提条件

ストレージクラスター内のすべてのノードへの root または sudo アクセスがある。

手順

Ceph ノードに root ユーザーとしてログインします。
```
ssh root@$HOST_NAME
```
置き換え
$HOST_NAME は、Ceph ノードのホスト名に置き換えます。
例
```
# ssh root@mon01
```
プロンプトに従い root パスワードを入力します。
新しい Ansible ユーザーを作成します。
```
adduser $USER_NAME
```
置き換え
$USER_NAME は、Ansible ユーザーの新規ユーザー名に置き換えます。
例
```
# adduser admin
```
重要
ceph をユーザー名として使用しないでください。ceph ユーザー名は、Ceph デーモン用に予約されます。クラスター全体で統一されたユーザー名を使用すると、使いやすさが向上しますが、侵入者は通常、そのユーザー名をブルートフォース攻撃に使用するため、明白なユーザー名の使用は避けてください。
このユーザーに新しいパスワードを設定します。
```
# passwd $USER_NAME
```
置き換え
$USER_NAME は、Ansible ユーザーの新規ユーザー名に置き換えます。
例
```
# passwd admin
```
プロンプトが表示されたら、新しいパスワードを 2 回入力します。
新規に作成されたユーザーの sudo アクセスを設定します。
```
cat << EOF >/etc/sudoers.d/$USER_NAME
$USER_NAME ALL = (root) NOPASSWD:ALL
EOF
```
置き換え
$USER_NAME は、Ansible ユーザーの新規ユーザー名に置き換えます。
例
```
# cat << EOF >/etc/sudoers.d/admin
admin ALL = (root) NOPASSWD:ALL
EOF
```
正しいファイル権限を新しいファイルに割り当てます。
```
chmod 0440 /etc/sudoers.d/$USER_NAME
```
置き換え
$USER_NAME は、Ansible ユーザーの新規ユーザー名に置き換えます。
例
```
# chmod 0440 /etc/sudoers.d/admin
```

関連情報

Red Hat Enterprise Linux 7 の『システム管理者のガイド』 の「新しいユーザーの追加」セクションを参照してください。

1.1.3. Ansible のパスワードなしの SSH の有効化

Ansible 管理ノードで SSH キーペアを生成し、ストレージクラスター内の各ノードに公開キーを配布して、Ansible がパスワードの入力を求められることなくノードにアクセスできるようにします。

前提条件

sudo アクセス権を持つ Ansible ユーザーを作成

手順

Ansible 管理ノードから、Ansible ユーザーとして次の手順を実行します。

SSH キーペアを生成し、デフォルトのファイル名を受け入れ、パスフレーズを空のままにします。
```
[user@admin ~]$ ssh-keygen
```
公開鍵をストレージクラスター内のすべてのノードにコピーします。
```
ssh-copy-id $USER_NAME@$HOST_NAME
```
置き換え
$USER_NAME は、Ansible ユーザーの新規ユーザー名に置き換えます。
$HOST_NAME は、Ceph ノードのホスト名に置き換えます。
例
```
[user@admin ~]$ ssh-copy-id admin@ceph-mon01
```
~/.ssh/config ファイルを作成および編集します。
重要
~/.ssh/config ファイルを作成および編集することで、ansible-playbook コマンドを実行するたびに -u $USER_NAME オプションを指定する必要はありません。
1. SSH config ファイルを作成します。
```
[user@admin ~]$ touch ~/.ssh/config
```
2. 編集のために config ファイルを開きます。ストレージクラスターの各ノードの Hostname と User オプションを設定します。
```
Host node1
   Hostname $HOST_NAME
   User $USER_NAME
Host node2
   Hostname $HOST_NAME
   User $USER_NAME
...
```
  置き換え
  $HOST_NAME は、Ceph ノードのホスト名に置き換えます。
  $USER_NAME は、Ansible ユーザーの新規ユーザー名に置き換えます。
  例
```
Host node1
   Hostname monitor
   User admin
Host node2
   Hostname osd
   User admin
Host node3
   Hostname gateway
   User admin
```
~/.ssh/config ファイルに正しいファイルパーミッションを設定します。
```
[admin@admin ~]$ chmod 600 ~/.ssh/config
```

1.1.4. Red Hat Ceph Storage のファイアウォールの設定

Red Hat Ceph Storage (RHCS) は firewalld サービスを使用します。

Monitor デーモンは、Ceph Storage クラスター内の通信にポート 6789 を使用します。

各 Ceph OSD ノードで、OSD デーモンは範囲 6800-7300 内の複数のポートを使用します。

パブリックネットワークを介してクライアントおよびモニターと通信するための 1 つ
クラスターネットワーク上で他の OSD にデータを送信する 1 つ (利用可能な場合)。それ以外の場合は、パブリックネットワーク経由でデータを送信します。
可能な場合は、クラスターネットワークを介してハートビートパケットを交換するための 1 つ。それ以外の場合は、パブリックネットワーク経由

Ceph Manager (ceph-mgr) デーモンは、6800-7300 範囲内のポートを使用します。同じノード上で Ceph Monitor と ceph-mgr デーモンを共存させることを検討してください。

Ceph Metadata Server ノード(ceph-mds) は、6800～7300 の範囲のポートを使用します。

Ceph Object Gateway ノードは、デフォルトで 8080 を使用するように Ansible によって設定されます。ただし、デフォルトのポート (例: ポート 80) を変更できます。

SSL/TLS サービスを使用するには、ポート 443 を開きます。

前提条件

ネットワークハードウェアが接続されている。

手順

以下のコマンドを root ユーザーで実行します。

すべての RHCS ノードで、firewalld サービスを起動します。これを有効にして、システムの起動時に実行し、実行していることを確認します。
```
# systemctl enable firewalld
# systemctl start firewalld
# systemctl status firewalld
```

すべての Monitor ノードで、パブリックネットワークの 6789 ポートを開く。

[root@monitor ~]# firewall-cmd --zone=public --add-port=6789/tcp
[root@monitor ~]# firewall-cmd --zone=public --add-port=6789/tcp --permanent

ソースアドレスに基づいてアクセスを制限するには、以下を実行します。

firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="IP_address/netmask_prefix" port protocol="tcp" \
port="6789" accept"

firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="IP_address/netmask_prefix" port protocol="tcp" \
port="6789" accept" --permanent

置き換え

IP_address には、Monitor ノードのネットワークアドレスを指定します。
netmask_prefix には、CIDR 表記のネットマスクを指定します。

例

[root@monitor ~]# firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="192.168.0.11/24" port protocol="tcp" \
port="6789" accept"

[root@monitor ~]# firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="192.168.0.11/24" port protocol="tcp" \
port="6789" accept" --permanent

すべての OSD ノードで、パブリックネットワークでポート 6800-7300 を開きます。
```
[root@osd ~]# firewall-cmd --zone=public --add-port=6800-7300/tcp
[root@osd ~]# firewall-cmd --zone=public --add-port=6800-7300/tcp --permanent
```
別のクラスターネットワークがある場合には、適切なゾーンでコマンドを繰り返します。
すべての Ceph Manager (ceph-mgr) ノード (通常はMonitorのノードと同じ) で、パブリックネットワークの 6800～7300 番ポートを開きます。
```
[root@monitor ~]# firewall-cmd --zone=public --add-port=6800-7300/tcp
[root@monitor ~]# firewall-cmd --zone=public --add-port=6800-7300/tcp --permanent
```
別のクラスターネットワークがある場合には、適切なゾーンでコマンドを繰り返します。
すべての Ceph Metadata Server (ceph-mds) ノードにおいて、パブリックネットワークでポート 6800 を開きます。
```
[root@monitor ~]# firewall-cmd --zone=public --add-port=6800/tcp
[root@monitor ~]# firewall-cmd --zone=public --add-port=6800/tcp --permanent
```
別のクラスターネットワークがある場合には、適切なゾーンでコマンドを繰り返します。

すべての Ceph Object Gateway ノードで、パブリックネットワーク上の関連するポートを開きます。

デフォルトの Ansible が設定されたポート 8080 を開くには、以下のコマンドを実行します。

[root@gateway ~]# firewall-cmd --zone=public --add-port=8080/tcp
[root@gateway ~]# firewall-cmd --zone=public --add-port=8080/tcp --permanent

ソースアドレスに基づいてアクセスを制限するには、以下を実行します。

firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="IP_address/netmask_prefix" port protocol="tcp" \
port="8080" accept"

firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="IP_address/netmask_prefix" port protocol="tcp" \
port="8080" accept" --permanent

置き換え

オブジェクトゲートウェイノードのネットワークアドレスを含む IP_address。
netmask_prefix には、CIDR 表記のネットマスクを指定します。

例

[root@gateway ~]# firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="192.168.0.31/24" port protocol="tcp" \
port="8080" accept"

[root@gateway ~]# firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="192.168.0.31/24" port protocol="tcp" \
port="8080" accept" --permanent

オプション:Ansible を使用して Ceph Object Gateway をインストールし、使用する Ceph Object Gateway を Ansible が構成するデフォルトのポートを 8080 からポート 80 に変更した場合は、次のポートを開きます。

[root@gateway ~]# firewall-cmd --zone=public --add-port=80/tcp
[root@gateway ~]# firewall-cmd --zone=public --add-port=80/tcp --permanent

ソースアドレスに基づいてアクセスを制限するには、以下のコマンドを実行します。

firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="IP_address/netmask_prefix" port protocol="tcp" \
port="80" accept"

firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="IP_address/netmask_prefix" port protocol="tcp" \
port="80" accept" --permanent

置き換え

オブジェクトゲートウェイノードのネットワークアドレスを含む IP_address。
netmask_prefix には、CIDR 表記のネットマスクを指定します。

例

[root@gateway ~]# firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="192.168.0.31/24" port protocol="tcp" \
port="80" accept"

[root@gateway ~]# firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="192.168.0.31/24" port protocol="tcp" \
port="80" accept" --permanent

オプション:SSL/TLS を使用するには、443 ポートを開きます。

[root@gateway ~]# firewall-cmd --zone=public --add-port=443/tcp
[root@gateway ~]# firewall-cmd --zone=public --add-port=443/tcp --permanent

ソースアドレスに基づいてアクセスを制限するには、以下のコマンドを実行します。

firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="IP_address/netmask_prefix" port protocol="tcp" \
port="443" accept"

firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="IP_address/netmask_prefix" port protocol="tcp" \
port="443" accept" --permanent

置き換え

オブジェクトゲートウェイノードのネットワークアドレスを含む IP_address。
netmask_prefix には、CIDR 表記のネットマスクを指定します。

例

[root@gateway ~]# firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="192.168.0.31/24" port protocol="tcp" \
port="443" accept"
[root@gateway ~]# firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
source address="192.168.0.31/24" port protocol="tcp" \
port="443" accept" --permanent

関連情報

パブリックネットワークおよびクラスターネットワークの詳細は、「Red Hat Ceph Storage のネットワーク設定の確認」を参照してください。
Firewalld の詳細は、 Red Hat Enterprise Linux 7 のセキュリティーガイドのファイアウォールの使用の章を参照してください。

1.1.5. HTTP プロキシーの使用

Ceph ノードが HTTP/HTTPS プロキシーの背後にある場合は、レジストリー内のイメージにアクセスするように docker を設定する必要があります。以下の手順に従って、HTTP/HTTPS プロキシーを使用して docker のアクセスを設定します。

前提条件

実行中の HTTP/HTTPS プロキシー

手順

root として、docker サービスの systemd ディレクトリーを作成します。
```
# mkdir /etc/systemd/system/docker.service.d/
```
root として、HTTP/HTTPS 設定ファイルを作成します。
1. HTTP の場合は、/etc/systemd/system/docker.service.d/http-proxy.conf ファイルを作成し、以下の行をファイルに追加します。
```
[Service]
Environment="HTTP_PROXY=http://proxy.example.com:80/"
```
2. HTTPS の場合は、/etc/systemd/system/docker.service.d/https-proxy.conf ファイルを作成し、以下の行をファイルに追加します。
```
[Service]
Environment="HTTPS_PROXY=https://proxy.example.com:443/"
```
root として、ceph-ansible Playbook を実行する前に、ストレージクラスター内のすべての Ceph ノードに HTTP/HTTPS 設定ファイルをコピーします。

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` を使用している場合は Yes	`devices` 設定を使用している場合は使用できません。
`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 のインベントリファイルを編集します。サンプルホストをコメントアウトすることを忘れないでください。
1. [mons] セクションの下に Monitor のノードを追加します。
```
[mons]
<monitor-host-name>
<monitor-host-name>
<monitor-host-name>
```
2. [osds] セクションの下に OSD ノードを追加します。ノードがシーケンシャルなネーミングの場合は、レンジの使用を検討してください。
```
[osds]
<osd-host-name[1:10]>
```
  注記
  新規インストールの OSD の場合、デフォルトのオブジェクトストア形式は BlueStore です。
  または、mons セクションと osds セクションの下に同じノードを追加することで、1 つのノードに OSD デーモンと一緒にモニターを配置することもできます。詳細は、2章コンテナー化された Ceph デーモンのコロケーション を参照してください。
オプションで、ベアメタルまたはコンテナー内のすべてのデプロイメントで、ansible-playbook を使用してカスタム CRUSH 階層を作成できます。
1. 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' }"
```
2. 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 階層を追加します。
3. 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 }}"
```
4. ツリーを表示します。
```
[root@mon ~]# ceph osd tree
```
5. プールを検証します。
```
# 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 ファイル) を編集するために開きます。例のホストをコメントアウトします。
1. [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
```
1. 次のように 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
```

1.3. すべての NVMe ストレージに OSD Ansible 設定の構成

ストレージに NVMe (Non-volatile Memory Express) デバイスのみを使用する場合のパフォーマンスを最適化するには、各 NVMe デバイスに 4 つの OSD を構成します。通常、OSD はデバイスごとに1つしか設定されないため、NVMe デバイスのスループットを十分に活用できません。

注記

SSD と HDD を混在させる場合、SSD は OSD ではなくジャーナルまたは block.db のいずれかに使用されます。

注記

テストでは、各 NVMe デバイスに 4 つの OSD を設定すると、最適なパフォーマンスが得られます。osds_per_device:4 を設定することをお勧めしますが、必須ではありません。他の値を設定すると、お客様の環境でより良いパフォーマンスが得られる場合があります。

前提条件

Ceph クラスターのソフトウェアおよびハードウェアの要件をすべて満たすこと。

手順

osd_scenario:lvm および osds_per_device:4 を group_vars/osds.yml に設定します。
```
osd_scenario: lvm
osds_per_device: 4
```

devices の下に NVMe デバイスを一覧表示します。

devices:
  - /dev/nvme0n1
  - /dev/nvme1n1
  - /dev/nvme2n1
  - /dev/nvme3n1

group_vars/osds.yml の設定は以下のようになります。

osd_scenario: lvm
osds_per_device: 4
devices:
  - /dev/nvme0n1
  - /dev/nvme1n1
  - /dev/nvme2n1
  - /dev/nvme3n1

注記

lvm_volumes ではなく、この設定で devices を使用する必要があります。これは、lvm_volumes が、通常、作成済みの論理ボリュームで使用され、osds_per_device は Ceph による論理ボリュームの自動作成を意味するためです。

関連情報

1.4. コンテナーへの Ceph Object Gateway のインストール

ceph-ansible playbook で Ansible アプリケーションを使用して、Ceph Object Gateway をコンテナーにインストールします。

前提条件

稼働中の Red Hat Ceph Storage クラスター

手順

特に指定がない限り、Ansible 管理ノードから次のコマンドを実行します。

root ユーザーとして、/usr/share/ceph-ansible/ ディレクトリーにナビゲートします。
```
[root@admin ~]# cd /usr/share/ceph-ansible/
```
group_vars/all.yml ファイルの radosgw_interface パラメーターのコメントを外します。
```
radosgw_interface: interface
```
interface を、Ceph Object Gateway ノードがリッスンするインターフェイスに置き換えます。
オプション:デフォルトの変数を変更します。
1. group_vars ディレクトリーにある rgws.yml.sample ファイルの新しいコピーを作成します。
```
[root@admin ceph-ansible]# cp group_vars/rgws.yml.sample group_vars/rgws.yml
```
2. group_vars/rgws.yml ファイルを編集します。詳細については、rgws.yml ファイルを参照してください。
Ceph Object Gateway ノードのホスト名を、デフォルトで /etc/ansible/hosts にある Ansible インベントリーファイルの [rgws] セクションに追加します。
```
[rgws]
gateway01
```
または、[osds] セクションと [rgws] セクションの下に同じノードを追加することで、Ceph Object Gateway を OSD デーモンと同じノードに配置することもできます。詳細は、「コンテナー化された Ceph デーモンのコロケーション」を参照してください。
Ansible ユーザーとして、ceph-ansible Playbook を実行します。
```
[user@admin ceph-ansible]$ ansible-playbook site-docker.yml --limit rgws
```
注記
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
```
Ceph Object Gateway ノードが正常にデプロイされたことを確認します。
1. root ユーザーとして Monitor ノードに接続します。
```
ssh hostname
```
  hostname を Monitor ノードのホスト名に置き換えます。次に例を示します。
```
[user@admin ~]$ ssh root@monitor
```
2. Ceph Object Gateway プールが正しく作成されたことを確認します。
```
[root@monitor ~]# docker exec ceph-mon-mon1 rados lspools
rbd
cephfs_data
cephfs_metadata
.rgw.root
default.rgw.control
default.rgw.data.root
default.rgw.gc
default.rgw.log
default.rgw.users.uid
```
3. Ceph クラスターと同じネットワーク上の任意のクライアント (モニターノードなど) から、curl コマンドを使用して、Ceph Object Gateway ホストの IP アドレスを使用してポート 8080 で HTTP 要求を送信します。
```
curl http://IP-address:8080
```
  IP-address を Ceph Object Gateway ノードの IP アドレスに置き換えます。Ceph Object Gateway ホストの IP アドレスを確認するには、ifconfig または ip コマンドを使用します。
```
[root@client ~]# curl http://192.168.122.199:8080
<?xml version="1.0" encoding="UTF-8"?><ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><Owner><ID>anonymous</ID><DisplayName></DisplayName></Owner><Buckets></Buckets></ListAllMyBucketsResult>
```
4. バケットを一覧表示します。
```
[root@monitor ~]# docker exec ceph-mon-mon1 radosgw-admin bucket list
```

関連情報

Red Hat Enterprise Linux 用の Red Hat Ceph Storage 3 Ceph Object Gateway ガイド
limit オプションについて

1.5. メタデータサーバーのインストール

Ansible 自動化アプリケーションを使用して Ceph Metadata Server (MDS) をインストールします。Ceph File System をデプロイするには、メタデータサーバーデーモンが必要です。

前提条件

稼働中の Red Hat Ceph Storage クラスター

手順

Ansible 管理ノードで以下の手順を実行します。

新しいセクション [mdss] を /etc/ansible/hosts ファイルに追加します。
```
[mdss]
hostname
hostname
hostname
```
hostname を、Ceph Metadata Server をインストールするノードのホスト名に置き換えます。
[osds] セクションおよび [mdss] セクションに同じノードを追加して、1 つのノードにメタデータサーバーと OSD デーモンを同じ場所に置く事ができます。詳細は、「コンテナー化された Ceph デーモンのコロケーション」を参照してください。
/usr/share/ceph-ansible ディレクトリーに移動します。
```
[root@admin ~]# cd /usr/share/ceph-ansible
```
オプション:デフォルトの変数を変更します。
1. mdss.yml という名前の group_vars/mdss.yml.sample ファイルのコピーを作成します。
```
[root@admin ceph-ansible]# cp group_vars/mdss.yml.sample group_vars/mdss.yml
```
2. オプションで、mdss.yml のパラメーターを編集します。詳細は、mdss.yml を参照してください。
Ansible のユーザーとして、Ansible のプレイブックを実行します。
```
[user@admin ceph-ansible]$ ansible-playbook site-docker.yml --limit mdss
```
メタデータサーバーをインストールしたら、設定を行います。詳細は、Red Hat Ceph Storage3 の Ceph ファイルシステムガイドの メタデータサーバーデーモンの設定 の章を参照してください。

関連情報

Red Hat Ceph Storage 3 のCeph ファイルシステムガイド
limit オプションについて

1.6. NFS-Ganesha ゲートウェイのインストール

Ceph NFS Ganesha ゲートウェイは、Ceph Object Gateway 上に構築される NFS インターフェースで、ファイルシステム内のファイルを Ceph Object Storage に移行するために POSIX ファイルシステムインターフェースを使用するアプリケーションを Ceph Object Gateway に提供します。

前提条件

稼働中の Ceph ストレージクラスター (active + clean の状態が望ましい)。
Ceph Object Gateway を実行するノードを少なくとも 1 つ。
開始前の手順を実行します。

手順

Ansible 管理ノードで以下のタスクを実行します。

サンプルファイルから nfss ファイルを作成します。

[root@ansible ~]# cd /usr/share/ceph-ansible/group_vars
[root@ansible ~]# cp nfss.yml.sample nfss.yml

[nfss] グループの下にゲートウェイホストを /etc/ansible/hosts ファイルに追加して、Ansible へのグループメンバーシップを特定します。ホストがシーケンシャルに命名されている場合は、範囲を指定します。以下は例になります。
```
[nfss]
<nfs_host_name_1>
<nfs_host_name_2>
<nfs_host_name[3..10]>
```
Ansible の設定ディレクトリである /etc/ansible/ に移動します。
```
[root@ansible ~]# cd /usr/share/ceph-ansible
```
管理者キーを Ceph Object Gateway ノードにコピーするには、/usr/share/ceph-ansible/group_vars/nfss.yml ファイルの copy_admin_key 設定をコメント解除します。
```
copy_admin_key: true
```

/usr/share/ceph-ansible/group_vars/nfss.yml ファイルの FSAL (File System Abstraction Layer) セクションを設定します。ID、S3 ユーザー ID、S3 アクセスキーおよびシークレットを指定します。NFSv4 の場合は、以下のようになります。

###################
# FSAL RGW Config #
###################
#ceph_nfs_rgw_export_id: <replace-w-numeric-export-id>
#ceph_nfs_rgw_pseudo_path: "/"
#ceph_nfs_rgw_protocols: "3,4"
#ceph_nfs_rgw_access_type: "RW"
#ceph_nfs_rgw_user: "cephnfs"
# Note: keys are optional and can be generated, but not on containerized, where
# they must be configered.
#ceph_nfs_rgw_access_key: "<replace-w-access-key>"
#ceph_nfs_rgw_secret_key: "<replace-w-secret-key>"

警告

アクセスおよびシークレットキーは任意で、生成できます。

Ansible Playbook の実行:

[user@admin ceph-ansible]$ ansible-playbook site-docker.yml --limit nfss

1.7. コンテナーへの Ceph iSCSI ゲートウェイのインストール

Ansible デプロイメントアプリケーションは、コンテナーに Ceph iSCSI ゲートウェイを設定するために必要なデーモンとツールをインストールします。

前提条件

稼働中の Red Hat Ceph Storage クラスター

手順

root ユーザーとして、/etc/ansible/hosts ファイルを開いて編集します。iSCSI ゲートウェイグループにノード名エントリーを追加します。
例
```
[iscsigws]
ceph-igw-1
ceph-igw-2
```
/usr/share/ceph-ansible ディレクトリーに移動します。
```
[root@admin ~]# cd /usr/share/ceph-ansible/
```
iscsigws.yml.sample ファイルのコピーを作成し、iscsigws.yml という名前を付けます。
```
[root@admin ceph-ansible]# cp group_vars/iscsigws.yml.sample group_vars/iscsigws.yml
```
重要
新しいファイル名 (iscsigws.yml) と新しいセクション見出し (iscsigws) は、Red Hat Ceph Storage 3.1 以降にのみ適用されます。以前のバージョンの Red Hat Ceph Storage から 3.1 にアップグレードすると、古いファイル名 (iscsi-gws.yml) と古いセクション見出し (iscsi-gws) が引き続き使用されます。
重要
現在、Red Hat は、コンテナーベースのデプロイメントで ceph-ansible を使用してインストールする以下のオプションをサポートしていません。
- gateway_iqn
- rbd_devices
- client_connections
これらのオプションを手動で設定する手順について は、コンテナーでの Ceph iSCSI ゲートウェイの設定 セクションを参照してください。
iscsigws.yml ファイルを開いて編集します。
IPv4 アドレスまたは IPv6 アドレスを使用して、iSCSI ゲートウェイ IP アドレスを追加して、gateway_ip_list オプションを設定します。
例
```
gateway_ip_list: 192.168.1.1,192.168.1.2
```
重要
IPv4 アドレスと IPv6 アドレスを混在させることはできません。
必要に応じて、trusted_ip_list オプションのコメントを解除し、SSL を使用する場合は IPv4 または IPv6 アドレスを適宜追加します。SSL を設定するには、iSCSI ゲートウェイコンテナーへの root アクセスが必要です。SSL を設定するには、以下の手順を実行します。
1. 必要に応じて、すべての iSCSI ゲートウェイコンテナー内に openssl パッケージをインストールします。
2. プライマリー iSCSI ゲートウェイコンテナーで、SSL キーを保持するディレクトリーを作成します。
```
# mkdir ~/ssl-keys
# cd ~/ssl-keys
```
3. プライマリー iSCSI ゲートウェイコンテナーで、証明書とキーファイルを作成します。
```
# openssl req -newkey rsa:2048 -nodes -keyout iscsi-gateway.key -x509 -days 365 -out iscsi-gateway.crt
```
  注記
  環境情報を入力するよう求められます。
4. プライマリー iSCSI ゲートウェイコンテナーで、PEM ファイルを作成します。
```
# cat iscsi-gateway.crt iscsi-gateway.key > iscsi-gateway.pem
```
5. プライマリー iSCSI ゲートウェイコンテナーで、公開鍵を作成します。
```
# openssl x509 -inform pem -in iscsi-gateway.pem -pubkey -noout > iscsi-gateway-pub.key
```
6. プライマリー iSCSI ゲートウェイコンテナーから、iscsi-gateway.crt、iscsi-gateway.pem、iscsi-gateway-pub.key、および iscsi-gateway.key ファイルを他の iSCSI ゲートウェイコンテナーの /etc/ceph/ ディレクトリーにコピーします。
必要に応じて、次の iSCSI ターゲット API サービスオプションのいずれかを確認し、コメントを解除します。
```
#api_user: admin
#api_password: admin
#api_port: 5000
#api_secure: false
#loop_delay: 1
#trusted_ip_list: 192.168.122.1,192.168.122.2
```

必要に応じて、次のリソースオプションのいずれかを確認してコメントを外し、ワークロードのニーズに応じて更新します。

# TCMU_RUNNER resource limitation
#ceph_tcmu_runner_docker_memory_limit: 1g
#ceph_tcmu_runner_docker_cpu_limit: 1

# RBD_TARGET_GW resource limitation
#ceph_rbd_target_gw_docker_memory_limit: 1g
#ceph_rbd_target_gw_docker_cpu_limit: 1

# RBD_TARGET_API resource limitation
#ceph_rbd_target_api_docker_memory_limit: 1g
#ceph_rbd_target_api_docker_cpu_limit: 1

Ansible のユーザーとして、Ansible のプレイブックを実行します。
```
[user@admin ceph-ansible]$ ansible-playbook site-docker.yml --limit iscsigws
```
Red Hat Enterprise Linux Atomic の場合、--skip-tags=with_pkg オプションを追加します。
```
[user@admin ceph-ansible]$ ansible-playbook site-docker.yml --limit iscsigws --skip-tags=with_pkg
```
Ansible Playbook が完了したら、trusted_ip_list オプションにリストされている各ノードで、TCP ポート 3260 と iscsigws.yml ファイルで指定された api_port を開きます。
注記
api_port オプションが指定されていない場合、デフォルトのポートは 5000 です。

関連情報

コンテナーへの Red Hat Ceph Storage の インストールに関する詳細は、コンテナーへの Red Hat Ceph Storage クラスター のインストールセクションを参照してください。
Ceph の iSCSI ゲートウェイオプションの詳細については、Red Hat Ceph Storage Block Device Guide の 表 8.1 を参照してください。
iSCSI ターゲット API オプションの詳細については、Red Hat Ceph Storage Block Device Guide の 表 8.2 を参照してください。
iscsigws.yml ファイルの例については、Red Hat Ceph Storage Block Device Guide の 付録 A を参照してください。

1.7.1. コンテナーでの Ceph iSCSI ゲートウェイの設定

Ceph iSCSI ゲートウェイの設定は、iSCSI ターゲット、論理ユニット番号 (LUN)、およびアクセス制御リスト (ACL) を作成および管理するための gwcli コマンドラインユーティリティーを使用して行います。

前提条件

稼働中の Red Hat Ceph Storage クラスター
iSCSI ゲートウェイソフトウェアのインストール。

手順

root ユーザーとして、iSCSI ゲートウェイのコマンドラインインターフェイスを開始します。
```
# docker exec -it rbd-target-api gwcli
```

IPv4 アドレスまたは IPv6 アドレスのいずれかを使用して iSCSI ゲートウェイを作成します。

構文

>/iscsi-target create iqn.2003-01.com.redhat.iscsi-gw:$TARGET_NAME
> goto gateways
> create $ISCSI_GW_NAME $ISCSI_GW_IP_ADDR
> create $ISCSI_GW_NAME $ISCSI_GW_IP_ADDR

例

>/iscsi-target create iqn.2003-01.com.redhat.iscsi-gw:ceph-igw
> goto gateways
> create ceph-gw-1 10.172.19.21
> create ceph-gw-2 10.172.19.22

重要

IPv4 アドレスと IPv6 アドレスを混在させることはできません。

RADOS ブロックデバイス (RBD) を追加します。
構文
```
> cd /disks
>/disks/ create $POOL_NAME image=$IMAGE_NAME size=$IMAGE_SIZE[m|g|t] max_data_area_mb=$BUFFER_SIZE
```
例
```
> cd /disks
>/disks/ create rbd image=disk_1 size=50g max_data_area_mb=32
```
重要
プール名またはイメージ名にピリオド (.) を含めることはできません。
警告
Red Hat サポートからの指示がない限り、max_data_area_mb オプションを調整しないでください。
max_data_area_mb オプションは、iSCSI ターゲットと Ceph クラスターの間で SCSI コマンドデータを渡す時に各イメージが使用できるメモリー量をメガバイト単位で制御します。この値が小さすぎると、パフォーマンスに影響を与える過剰なキューのフル再試行が発生する可能性があります。値が大きすぎると、1 つのディスクがシステムのメモリーを過剰に使用する結果になり、他のサブシステムの割り当てエラーを引き起こす可能性があります。デフォルト値は 8 です。
この値は、reconfigure コマンドを使用して変更できます。このコマンドを有効にするには、イメージが iSCSI イニシエーターによって使用されていてはなりません。
構文
```
>/disks/ reconfigure max_data_area_mb $NEW_BUFFER_SIZE
```
例
```
>/disks/ reconfigure max_data_area_mb 64
```
クライアントを作成します。
構文
```
> goto hosts
> create iqn.1994-05.com.redhat:$CLIENT_NAME
> auth chap=$USER_NAME/$PASSWORD
```
例
```
> goto hosts
> create iqn.1994-05.com.redhat:rh7-client
> auth chap=iscsiuser1/temp12345678
```
重要
CHAP の無効化は、Red Hat Ceph Storage 3.1 以降でのみサポートされています。Red Hat は、CHAP が有効になっているクライアントと CHAP が無効になっているクライアントの混在をサポートしていません。すべてのクライアントの CHAP を有効にするか、無効にする必要があります。デフォルトの動作としては、イニシエーター名でイニシエーターを認証するだけです。
イニシエーターがターゲットへのログインに失敗している場合、一部のイニシエーターで CHAP 認証が正しく設定されていない可能性があります。
例
```
o- hosts ................................ [Hosts: 2: Auth: MISCONFIG]
```
hosts レベルで次のコマンドを実行して、すべての CHAP 認証をリセットします。
```
/> goto hosts
/iscsi-target...csi-igw/hosts> auth nochap
ok
ok
/iscsi-target...csi-igw/hosts> ls
o- hosts ................................ [Hosts: 2: Auth: None]
  o- iqn.2005-03.com.ceph:esx ........... [Auth: None, Disks: 4(310G)]
  o- iqn.1994-05.com.redhat:rh7-client .. [Auth: None, Disks: 0(0.00Y)]
```

ディスクをクライアントに追加します。

構文

>/iscsi-target..eph-igw/hosts> cd iqn.1994-05.com.redhat:$CLIENT_NAME
> disk add $POOL_NAME.$IMAGE_NAME

例

>/iscsi-target..eph-igw/hosts> cd iqn.1994-05.com.redhat:rh7-client
> disk add rbd.disk_1

次のコマンドを実行して、iSCSI ゲートウェイの設定を確認します。
```
> ls
```
必要に応じて、API が SSL を正しく使用していることを確認し、/var/log/rbd-target-api.log ファイルで https を調べます。次に例を示します。
```
Aug 01 17:27:42 test-node.example.com python[1879]:  * Running on https://0.0.0.0:5000/
```
次のステップは、iSCSI イニシエーターを設定することです。

関連情報

コンテナーへの Red Hat Ceph Storage の インストールに関する詳細は、コンテナーへの Red Hat Ceph Storage クラスター のインストールセクションを参照してください。
コンテナーへの iSCSI ゲートウェイソフトウェアのインストールの詳細については、コンテナー への Ceph iSCSI ゲートウェイのインストール セクションを参照してください。
iSCSI イニシエーターの接続に関する詳細は、Red Hat Ceph Storage Block Device Guide の Configuring the iSCSI Initiator セクションを参照してください。

1.7.2. コンテナー内の Ceph iSCSI ゲートウェイの削除

Ceph iSCSI ゲートウェイ設定は、Ansible を使用して削除できます。

前提条件

稼働中の Red Hat Ceph Storage クラスター
iSCSI ゲートウェイソフトウェアのインストール。
エクスポートされた RBD イメージ。
Red Hat Ceph Storage クラスターへのルートレベルのアクセス。
iSCSI イニシエーターへのルートレベルのアクセス。
Ansible 管理ノードへのアクセス

手順

iSCSI ゲートウェイ設定をパージする前に、すべての iSCSI イニシエーターを切断します。適切なオペレーティングシステムについては、次の手順に従ってください。
1. Red Hat Enterprise Linux イニシエーター:
  root で次のコマンドを実行します。
  構文
```
iscsiadm -m node -T TARGET_NAME --logout
```
  TARGET_NAME は、設定した iSCSI ターゲット名に置き換えます。
  例
```
# iscsiadm -m node -T iqn.2003-01.com.redhat.iscsi-gw:ceph-igw --logout
Logging out of session [sid: 1, target: iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw, portal: 10.172.19.21,3260]
Logging out of session [sid: 2, target: iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw, portal: 10.172.19.22,3260]
Logout of [sid: 1, target: iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw, portal: 10.172.19.21,3260] successful.
Logout of [sid: 2, target: iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw, portal: 10.172.19.22,3260] successful.
```
2. Windows イニシエーター:
  詳細は、Microsoft のドキュメントを参照してください。
3. VMware ESXi イニシエーター:
  詳細は、VMware のドキュメントを参照してください。
root ユーザーとして、iSCSI ゲートウェイコマンドラインユーティリティーを実行します。
```
# gwcli
```

ホストを削除します。

構文

/> cd /iscsi-target/iqn.2003-01.com.redhat.iscsi-gw:_TARGET_NAME_/hosts
/> /iscsi-target...TARGET_NAME/hosts> delete CLIENT_NAME

TARGET_NAME を設定済みの iSCSI ターゲット名に置き換え、CLIENT_NAME を iSCSI イニシエーター名に置き換えます。

例

/> cd /iscsi-target/iqn.2003-01.com.redhat.iscsi-gw:ceph-igw/hosts
/> /iscsi-target...eph-igw/hosts> delete iqn.1994-05.com.redhat:rh7-client

ディスクを削除します。
構文
```
/> cd /disks/
/disks> delete POOL_NAME.IMAGE_NAME
```
POOL_NAME をプールの名前に置き換え、IMAGE_NAME をイメージの名前に置き換えます。
例
```
/> cd /disks/
/disks> delete rbd.disk_1
```
iSCSI ターゲットおよびゲートウェイ設定を削除します。
```
/> cd /iscsi-target/
/iscsi-target> clearconfig confirm=true
```
Ceph Monitor または Client ノードで、root ユーザーとして、iSCSI ゲートウェイ設定オブジェクト (gateway.conf) を削除します。
```
[root@mon ~]# rados rm -p pool gateway.conf
```
オプションで、エクスポートされた Ceph RADOS Block Device (RBD) が不要になった場合は、RBD イメージを削除します。root ユーザーとして、Ceph Monitor またはクライアントノードで以下のコマンドを実行します。
構文
```
rbd rm IMAGE_NAME
```
例
```
[root@mon ~]# rbd rm rbd01
```

関連情報

コンテナーへの Red Hat Ceph Storage の インストールに関する詳細は、コンテナーへの Red Hat Ceph Storage クラスター のインストールセクションを参照してください。
コンテナーへの iSCSI ゲートウェイソフトウェアのインストールの詳細については、コンテナー への Ceph iSCSI ゲートウェイのインストール セクションを参照してください。

1.7.3. iSCSI ターゲットのパフォーマンスの最適化

ネットワーク上で iSCSI ターゲット転送データを送信する方法を制御する設定は多数あります。これらの設定を使用して、iSCSI ゲートウェイのパフォーマンスを最適化できます。

警告

Red Hat サポートの指示または本書の記載がない限り、この設定は変更しないでください。

gwcli reconfigure サブコマンド

gwcli reconfigure サブコマンドは、iSCSI ゲートウェイのパフォーマンスの最適化に使用される設定を制御します。

iSCSI ターゲットのパフォーマンスに影響する設定

max_data_area_mb
cmdsn_depth
immediate_data
initial_r2t
max_outstanding_r2t
first_burst_length
max_burst_length
max_recv_data_segment_length
max_xmit_data_segment_length

関連情報

max_data_area_mb に関する情報 (gwcli reconfigure を使用して調整する方法を示す例を含む) は、ブロックデバイスガイドのコマンドラインインターフェイスを使用した iSCSI ターゲットの設定セクションと、コンテナーガイド のコンテナーでの Ceph iSCSI ゲートウェイの設定セクションにあります。

1.8. `limit` オプションについて

本セクションでは、Ansible の --limit オプションを説明します。

Ansible は --limit オプションをサポートしており、インベントリーファイルの特定のセクションに対して site および site-docker Ansible Playbook を使用できます。

$ ansible-playbook site.yml|site-docker.yml --limit osds|rgws|clients|mdss|nfss|iscsigws

たとえば、コンテナーに OSD のみを再デプロイするには、Ansible ユーザーとして以下のコマンドを実行します。

$ ansible-playbook /usr/share/ceph-ansible/site-docker.yml --limit osds

1.9. 関連情報

Red Hat Enterprise Linux Atomic Host のコンテナー入門ガイド

第2章コンテナー化された Ceph デーモンのコロケーション

このセクションでは、以下について説明します。

コロケーションの仕組みとその利点
同じ場所に配置されたデーモン専用のリソースを設定する方法

2.1. コロケーションの仕組みとその利点

コンテナー化された Ceph デーモンを同じノードの同じ場所に配置できます。Ceph のサービスの一部を共存する利点を以下に示します。

小規模での総所有コスト (TCO) の大幅な改善
最小設定の場合は、6 ノードから 3 ノードまで削減します。
より簡単なアップグレード
リソース分離の改善

コロケーションの仕組み

Ansible インベントリーファイルの適切なセクションに同じノードを追加することで、次のリストから 1 つのデーモンを OSD デーモンと同じ場所に配置できます。

Ceph Object Gateway (radosgw)
メタデータサーバー (MDS)
RBD mirror (rbd-mirror)
監視および Ceph Manager デーモン (ceph-mgr)
NFS Ganesha

以下の例は、コロケートデーモンを持つインベントリーファイルがどのようになるかを示しています。

例2.1 同じ場所に配置されたデーモンを含む Ansible インベントリーファイル

[mons]
<hostname1>
<hostname2>
<hostname3>

[mgrs]
<hostname1>
<hostname2>
<hostname3>

[osds]
<hostname4>
<hostname5>
<hostname6>

[rgws]
<hostname4>
<hostname5>

図2.1「同じ場所に配置されたデーモン」イメージおよび図2.2「同じ場所に配置されていないデーモン」イメージは、同じ場所に置かれたデーモンと、同じ場所に置かれていないデーモンの相違点を示しています。

図2.1 同じ場所に配置されたデーモン

図2.2 同じ場所に配置されていないデーモン

複数のコンテナー化された Ceph デーモンを同じノードにコロケートする場合、Playbook ceph-ansible は専用の CPU および RAM リソースをそれぞれに予約します。デフォルトでは、ceph-ansible は Red Hat Ceph Storage Hardware Selection Guide 3 の推奨最小ハードウェアの章に記載されている値を使用します。デフォルト値の変更方法は、「同じ場所に配置されたデーモンの専用リソースの設定」セクションを参照してください。

2.2. 同じ場所に配置されたデーモンの専用リソースの設定

同じノードで 2 つの Ceph デーモンを共存させる場合には、Playbook ceph-ansible は各デーモンに CPU および RAM リソースを予約します。ceph-ansible が使用するデフォルト値は、『Red Hat Ceph Storage ハードウェア選択ガイド』の「推奨される最小ハードウェア」の章に記載されています。デフォルト値を変更するには、Ceph デーモンのデプロイ時に必要なパラメーターを設定します。

手順

デーモンのデフォルト CPU 制限を変更するには、デーモンのデプロイ時に、適切な .yml 設定ファイルに ceph_daemon-type_docker_cpu_limit パラメーターを設定します。詳細は以下の表を参照してください。

デーモン	パラメーター	設定ファイル
OSD	`ceph_osd_docker_cpu_limit`	`osds.yml`
MDS	`ceph_mds_docker_cpu_limit`	`mdss.yml`
RGW	`ceph_rgw_docker_cpu_limit`	`rgws.yml`

たとえば、Ceph Object Gateway のデフォルトの CPU 制限を 2 に変更するには、以下のように /usr/share/ceph-ansible/group_vars/rgws.yml ファイルを編集します。

ceph_rgw_docker_cpu_limit: 2

OSD デーモンのデフォルト RAM を変更するには、デーモンのデプロイ時に /usr/share/ceph-ansible/group_vars/all.yml ファイルに osd_memory_target を設定します。たとえば、OSD RAM を 6 GB に制限するには、以下を実行します。
```
ceph_conf_overrides:
  osd:
    osd_memory_target=6000000000
```
重要
ハイパーコンバージドインフラストラクチャー (HCI) 設定では、osd_memory_target パラメーターを使用して OSD のメモリーを制限することをお勧めします。ceph_osd_docker_memory_limit パラメーターは必要ありませんが、使用する場合は、ceph_osd_docker_memory_limit を osd_memory_target よりも 50% 高く設定して、CGroup 制限が HCI 設定のデフォルトよりも制約されるようにします。たとえば、osd_memory_target が 6 GB に設定されている場合は、ceph_osd_docker_memory_limit を 9 GB に設定します。
```
ceph_osd_docker_memory_limit: 9g
```

警告

ceph_osd_docker_memory_limit パラメーターは使用しないでください。値を超えると、OSD が使用されていれば実行を停止することができます。osd_memory_target パラメーターはソフト制限を設定して、値を超えるとコンテナーが実行を停止し、割り込みサービスを停止するようにします。

関連情報

/usr/share/ceph-ansible/group_vars/ ディレクトリーにある設定ファイルのサンプル

2.3. 関連情報

第3章コンテナーで実行される Ceph クラスターの管理

この章では、コンテナーで実行される Ceph クラスターで実行する基本的な管理タスクについて説明します。

「コンテナー内で実行される Ceph デーモンの開始、停止、および再起動」
「コンテナー内で実行される Ceph デーモンのログファイルの表示」
「Ansible によってデプロイされたクラスターのパージ」
「コンテナーで実行される Red Hat Ceph Storage クラスターのアップグレード」

3.1. コンテナー内で実行される Ceph デーモンの開始、停止、および再起動

systemctl コマンドを使用して、コンテナーで実行するCeph デーモンの起動、停止、再起動を行います。

手順

コンテナーで実行している Ceph デーモンを起動、停止、または再起動するには、以下の形式で構成されるように、root で systemctl コマンドを実行します。
```
systemctl action ceph-daemon@ID
```
ここで、
- action は、実行するアクション (start、stop、または restart) です。
- daemon で、osd、mon、mds、または rgwです。
- ID は以下のいずれかになります。
  - ceph-mon デーモン、ceph-mds デーモン、または ceph-rgw デーモンが実行している短いホスト名。
  - lvm に設定されている osd_scenario パラメーターが展開された場合の ceph-osd デーモンの ID
  - osd_scenario パラメーターを collocated または non-collocated に設定してデプロイされた場合に ceph-osd デーモンが使用するデバイス名
たとえば、osd01 で ceph-osd デーモンを再起動するには、以下のコマンドを実行します。
```
# systemctl restart ceph-osd@osd01
```
ceph-monitor01 ホストで実行する ceph-mon デーモンを起動するには、以下のコマンドを実行します。
```
# systemctl start ceph-mon@ceph-monitor01
```
ceph-rgw01 ホストで実行する ceph-rgw デーモンを停止するには、以下のコマンドを実行します。
```
# systemctl stop ceph-radosgw@ceph-rgw01
```
アクションが正常に完了したことを確認します。
```
systemctl status ceph-daemon@_ID
```
以下は例になります。
```
# systemctl status ceph-mon@ceph-monitor01
```

関連情報

Red Hat Ceph Storage 3 の 管理ガイド の systemd サービスとしての Ceph の実行 セクション。

3.2. コンテナー内で実行される Ceph デーモンのログファイルの表示

コンテナーホストからの journald デーモンを使用して、コンテナーから Ceph デーモンのログファイルを表示します。

手順

Ceph ログファイル全体を表示するには、以下の形式で構成される root で journalctl コマンドを実行します。
```
journalctl -u ceph-daemon@ID
```
ここで、
- daemon は Ceph デーモン (osd、mon、または rgw) です。
- ID は以下のいずれかになります。
  - ceph-mon デーモン、ceph-mds デーモン、または ceph-rgw デーモンが実行している短いホスト名。
  - lvm に設定されている osd_scenario パラメーターが展開された場合の ceph-osd デーモンの ID
  - osd_scenario パラメーターを collocated または non-collocated に設定してデプロイされた場合に ceph-osd デーモンが使用するデバイス名
たとえば、ID osd01 の ceph-osd デーモンのログ全体を表示するには、以下のコマンドを実行します。
```
# journalctl -u ceph-osd@osd01
```
最近のジャーナルエントリーのみを表示するには、-f オプションを使用します。
```
journalctl -fu ceph-daemon@ID
```
たとえば、ceph-monitor01 ホストで実行する ceph-mon デーモンの最近のジャーナルエントリーのみを表示するには、以下のコマンドを実行します。
```
# journalctl -fu ceph-mon@ceph-monitor01
```

注記

sosreport ユーティリティーを使用して journald ログを表示することもできます。SOS レポートの詳細については、Red Hat カスタマーポータルのソリューションの What is a sosreport and how to create one in Red Hat Enterprise Linux 4.6 and later? を参照してください。

関連情報

journalctl(1) の man ページ

3.3. コマンドラインインターフェースを使用した Ceph OSD の追加

OSD を Red Hat Ceph Storage に手動で追加するハイレベルのワークフローを以下に示します。

ceph-osd パッケージをインストールして、新規 OSD インスタンスを作成します。
OSD データおよびジャーナルドライブを準備してマウントします。
新規 OSD ノードを CRUSH マップに追加します。
所有者およびグループパーミッションを更新します。
ceph-osd デーモンを有効にして起動します。

重要

ceph-disk コマンドは非推奨となりました。ceph-volume コマンドは、コマンドラインインターフェースから OSD をデプロイするのに推奨される方法です。現在、ceph-volume コマンドは lvm プラグインのみをサポートしています。Red Hat は、本ガイドで両方のコマンドを参照として使用している例を提供します。これにより、ストレージ管理者は ceph-disk に依存するカスタムスクリプトを ceph-volume に変換できます。

ceph-volume コマンドの使用方法は、Red Hat Ceph Storage Administration Guideを参照してください。

注記

カスタムストレージクラスター名の場合は、ceph コマンドおよび ceph-osd コマンドで --cluster $CLUSTER_NAME オプションを使用します。

前提条件

Red Hat Ceph Storage クラスターが実行中である。
Installation Guide for Red Hat Enterprise Linux または Ubuntu の Requirements for Installing Red Hat Ceph Storage の章を参照してください。
新規ノードへの root アクセスがあること。

手順

Red Hat Ceph Storage 3 OSD ソフトウェアリポジトリーを有効にします。
Red Hat Enterprise Linux
```
[root@osd ~]# subscription-manager repos --enable=rhel-7-server-rhceph-3-osd- els-rpms
```
/etc/ceph/ ディレクトリーを作成します。
新しい OSD ノードで、Ceph 管理キーリングと設定ファイルを Ceph Monitor ノードの 1 つからコピーします。
ceph-osd パッケージを新しい Ceph OSD ノードにインストールします。
Red Hat Enterprise Linux
```
[root@osd ~]# yum install ceph-osd
```

新規 OSD について、ジャーナルを共存させるか、または専用のジャーナルを使用するかどうかを決定します。

注記

--filestore オプションが必要です。

ジャーナルを共存させる OSD の場合:

構文

[root@osd ~]# docker exec $CONTAINER_ID ceph-disk --setuser ceph --setgroup ceph prepare  --filestore /dev/$DEVICE_NAME

例:

[root@osd ~]# docker exec ceph-osd-osd1 ceph-disk --setuser ceph --setgroup ceph prepare  --filestore /dev/sda

専用のジャーナルを持つ OSD の場合:

構文

[root@osd ~]# docker exec $CONTAINER_ID ceph-disk --setuser ceph --setgroup ceph prepare  --filestore /dev/$DEVICE_NAME /dev/$JOURNAL_DEVICE_NAME

または

[root@osd ~]# docker exec $CONTAINER_ID ceph-volume lvm prepare  --filestore --data /dev/$DEVICE_NAME --journal /dev/$JOURNAL_DEVICE_NAME

例

[root@osd ~]# docker exec ceph-osd-osd1 ceph-disk --setuser ceph --setgroup ceph prepare  --filestore /dev/sda /dev/sdb

[root@osd ~]# docker exec ceph-osd-osd1 ceph-volume lvm prepare  --filestore --data /dev/vg00/lvol1 --journal /dev/sdb

noup オプションを設定します。
```
[root@osd ~]# ceph osd set noup
```

新しい OSD をアクティベートします。

構文

[root@osd ~]# docker exec $CONTAINER_ID ceph-disk activate /dev/$DEVICE_NAME

または

[root@osd ~]# docker exec $CONTAINER_ID ceph-volume lvm activate --filestore $OSD_ID $OSD_FSID

例

[root@osd ~]# docker exec ceph-osd-osd1 ceph-disk activate /dev/sda

[root@osd ~]# docker exec ceph-osd-osd1 ceph-volume lvm activate --filestore 0 6cc43680-4f6e-4feb-92ff-9c7ba204120e

OSD を CRUSH マップに追加します。
構文
```
ceph osd crush add $OSD_ID $WEIGHT [$BUCKET_TYPE=$BUCKET_NAME ...]
```
例
```
[root@osd ~]# ceph osd crush add 4 1 host=node4
```
注記
複数のバケットを指定する場合、コマンドは OSD を指定したバケットから最も具体的なバケットに配置、および 指定した他のバケットに従ってバケットを移動します。
注記
CRUSH マップを手動で編集することもできます。Red Hat Ceph Storage 3 の Storage Strategies ガイドの Editing a CRUSH map セクションを参照してください。
重要
ルートバケットのみを指定する場合、OSD はルートに直接アタッチしますが、CRUSH ルールは OSD がホストバケット内に置かれることを想定します。
noup オプションの設定を解除します。
```
[root@osd ~]# ceph osd unset noup
```

新規作成されたディレクトリーの所有者とグループのパーミッションを更新します。

構文

chown -R $OWNER:$GROUP $PATH_TO_DIRECTORY

例

[root@osd ~]# chown -R ceph:ceph /var/lib/ceph/osd
[root@osd ~]# chown -R ceph:ceph /var/log/ceph
[root@osd ~]# chown -R ceph:ceph /var/run/ceph
[root@osd ~]# chown -R ceph:ceph /etc/ceph

カスタム名のクラスターを使用する場合は、以下の行を適切なファイルに追加します。
Red Hat Enterprise Linux
```
[root@osd ~]# echo "CLUSTER=$CLUSTER_NAME" >> /etc/sysconfig/ceph
```
$CLUSTER_NAME は、カスタムクラスター名に置き換えます。
新規 OSD が 起動 し、データを受信する準備ができていることを確認するには、OSD サービスを有効にして起動します。
構文
```
systemctl enable ceph-osd@$OSD_ID
systemctl start ceph-osd@$OSD_ID
```
例
```
[root@osd ~]# systemctl enable ceph-osd@4
[root@osd ~]# systemctl start ceph-osd@4
```

3.4. コマンドラインインターフェースを使用した Ceph OSD の削除

ストレージクラスターから OSD を削除するには、クラスターマップの更新、その認証キーの削除、OSD マップからの OSD の削除、および ceph.conf ファイルからの OSD の削除を行う必要があります。ノードに複数のドライブがある場合は、この手順を繰り返して、それぞれのドライブについて OSD を削除する必要がある場合があります。

前提条件

実行中の Red Hat Ceph Storage クラスター
利用可能な OSD が十分になるようにして、ストレージクラスターが ほぼ完全 な比率にならないようにしてください。
OSDノードへの root アクセス権限があること。

手順

OSD サービスを無効にし、停止します。

構文

systemctl disable ceph-osd@$DEVICE_NAME
systemctl stop ceph-osd@$DEVICE_NAME

例

[root@osd ~]# systemctl disable ceph-osd@sdb
[root@osd ~]# systemctl stop ceph-osd@sdb

OSD が停止したら、停止 します。

ストレージクラスターから OSD を削除します。
構文
```
ceph osd out $DEVICE_NAME
```
例
```
[root@osd ~]# ceph osd out sdb
```
重要
OSD が削除されると、Ceph は再バランス調整を開始し、データをストレージクラスター内の他の OSD にコピーします。Red Hat は、次の手順に進む前に、ストレージクラスターが active+clean になるまで待つことを推奨します。データの移行を確認するには、以下のコマンドを実行します。
```
[root@monitor ~]# ceph -w
```
CRUSH マップから OSD を削除して、データを受信しないようにします。
構文
```
ceph osd crush remove $OSD_NAME
```
例
```
[root@osd ~]# ceph osd crush remove osd.4
```
注記
CRUSH マップをコンパイルし、デバイス一覧から OSD を削除して、ホストバケットの項目としてデバイスを削除するか、またはホストバケットを削除することもできます。CRUSH マップにあり、ホストを削除するには、マップを再コンパイルしてからこれを設定します。詳細は、Storage Strategies Guide を参照してください。

OSD 認証キーを削除します。

構文

ceph auth del osd.$DEVICE_NAME

例

[root@osd ~]# ceph auth del osd.sdb

OSD を削除します。

構文

ceph osd rm $DEVICE_NAME

例

[root@osd ~]# ceph osd rm sdb

ストレージクラスターの設定ファイル (デフォルトでは /etc/ceph.conf) を編集して、OSD エントリーが存在する場合は削除します。
例
```
[osd.4]
host = $HOST_NAME
```
OSD を手動で追加している場合は、/etc/fstab ファイルで OSD への参照を削除します。
更新された設定ファイルを、ストレージクラスター内の他のすべてのノードの /etc/ceph/ ディレクトリーにコピーします。
構文
```
scp /etc/ceph/$CLUSTER_NAME.conf $USER_NAME@$HOST_NAME:/etc/ceph/
```
例
```
[root@osd ~]# scp /etc/ceph/ceph.conf root@node4:/etc/ceph/
```

3.5. OSD ID の保持中に OSD ドライブの置き換え

障害のある OSD ドライブを置き換える場合は、元の OSD ID および CRUSH マップエントリーを保持できます。

注記

ceph-volume lvm コマンドのデフォルトは、OSD 用の BlueStore です。FileStore OSD を使用するには、--filestore、--data、および --journal オプションを使用します。

詳細は、OSD データおよびジャーナルドライブの準備セクションを参照してください。

前提条件

実行中の Red Hat Ceph Storage クラスター
障害の発生したディスク。

手順

OSD を破棄します。

ceph osd destroy $OSD_ID --yes-i-really-mean-it

例

$ ceph osd destroy 1 --yes-i-really-mean-it

必要に応じて、交換ディスクを以前使用していた場合は、ディスクを ザッピングする 必要があります。
```
docker exec $CONTAINER_ID ceph-volume lvm zap $DEVICE
```
例
```
$ docker exec ceph-osd-osd1 ceph-volume lvm zap /dev/sdb
```

既存の OSD ID で新規 OSD を作成します。

docker exec $CONTAINER_ID ceph-volume lvm create --osd-id $OSD_ID --data $DEVICE

例

$ docker exec ceph-osd-osd1 ceph-volume lvm create --osd-id 1 --data /dev/sdb

3.6. Ansible によってデプロイされたクラスターのパージ

Ceph クラスターを使用する必要がなくなった場合は、purge-docker-cluster.yml Playbook を使用してクラスターをパージします。クラスターのパージは、インストールプロセスが失敗し、最初からやり直したい場合にも役立ちます。

警告

Ceph クラスターをパージすると、OSD 上のすべてのデータが失われます。

前提条件

/var/log/ansible.log ファイルが書き込み可能であることを確認します。

手順

Ansible の管理ノードから以下のコマンドを使用します。

root ユーザーとして、/usr/share/ceph-ansible/ ディレクトリーにナビゲートします。
```
[root@admin ~]# cd /usr/share/ceph-ansible
```
/usr/share/infrastructure-playbooks/ ディレクトリーから現在のディレクトリーに purge-docker-cluster.yml Playbook をコピーします。
```
[root@admin ceph-ansible]# cp infrastructure-playbooks/purge-docker-cluster.yml .
```
Ansible ユーザーとして、purge-docker-cluster.yml Playbook を使用して Ceph クラスターを消去します。
1. すべてのパッケージ、コンテナー、設定ファイル、および ceph-ansible Playbook によって作成されたすべてのデータを削除するには:
```
[user@admin ceph-ansible]$ ansible-playbook purge-docker-cluster.yml
```
2. デフォルトのもの (/etc/ansible/hosts) とは異なるインベントリーファイルを指定するには、-i パラメーターを使用します。
```
ansible-playbook purge-docker-cluster.yml -i inventory-file
```
  inventory-file をインベントリーファイルへのパスに置き換えます。
  以下は例になります。
```
[user@admin ceph-ansible]$ ansible-playbook purge-docker-cluster.yml -i ~/ansible/hosts
```
3. Ceph コンテナーイメージの削除を省略するには、--skip-tags=”remove_img” オプションを使用します。
```
[user@admin ceph-ansible]$ ansible-playbook --skip-tags="remove_img" purge-docker-cluster.yml
```
4. インストール時にインストールしたパッケージの削除を省略するには、--skip-tags=”with_pkg” オプションを使用します。
```
[user@admin ceph-ansible]$ ansible-playbook --skip-tags="with_pkg" purge-docker-cluster.yml
```

第4章コンテナー内の Red Hat Ceph Storage のアップグレード

Ansible アプリケーションは、コンテナー内で実行されている Red Hat Ceph Storage のアップグレードを実行します。

4.1. 前提条件

Red Hat Ceph Storage クラスターが実行中である。

4.2. コンテナーで実行される Red Hat Ceph Storage クラスターのアップグレード

このセクションでは、Red Hat Ceph Storage コンテナーイメージの新しいマイナーまたはメジャーバージョンにアップグレードする方法について説明します。

ストレージクラスターをアップグレードするには、「ストレージクラスターのアップグレード」を参照してください。
Red Hat Ceph Storage Dashboard をアップグレードするには、「Red Hat Ceph Storage Dashboard のアップグレード」を参照してください。

管理ノードの /usr/share/ceph-ansible/infrastructure-playbooks/ ディレクトリーにある Ansiblerolling_update.yml Playbook を使用して、Red Hat Ceph Storage の 2 つのメジャーバージョンまたはマイナーバージョン間でアップグレードするか、非同期更新を適用します。

Ansible は Ceph ノードを以下の順序でアップグレードします。

ノードの監視
MGR ノード
OSD ノード
MDS ノード
Ceph Object Gateway ノード
その他すべての Ceph クライアントノード

注記

Red Hat Ceph Storage 3 では、/usr/share/ceph-ansible/group_vars/ ディレクトリーにある Ansible 設定ファイルにいくつかの変更が導入されており、特定のパラメーターの名前が変更されたり削除されたりしています。したがって、バージョン 3 にアップグレードした後、all.yml.sample ファイルと osds.yml.sample ファイルから新しいコピーを作成する前に、all.yml ファイルと osds.yml ファイルのバックアップコピーを作成してください。変更点の詳細は、付録A バージョン 2 と 3 の間の Ansible 変数の変更 をご覧ください。

注記

Red Hat Ceph Storage 3.1 以降では、Object Gateway および高速 NVMe ベースの SSD (および SATA SSD) を使用する場合のパフォーマンスのためにストレージを最適化するために、新しい Ansible プレイブックが導入されています。Playbook は、ジャーナルとバケットインデックスを SSD に一緒に配置することでこれを行います。これにより、すべてのジャーナルを 1 つのデバイスに配置する場合に比べてパフォーマンスを向上させることができます。これらの Playbook は、Ceph のインストール時に使用されます。既存の OSD は動作し続け、アップグレード中に追加のステップは必要ありません。このようにストレージを最適化するために OSD を同時に再設定する際に、Ceph クラスターをアップグレードする方法はありません。ジャーナルまたはバケットインデックスに異なるデバイスを使用するには、OSD を再プロビジョニングする必要があります。詳細は、Ceph Object Gateway for Production での LVM での NVMe の最適な使用を参照してください。

重要

Playbook rolling_update.yml には、同時に更新するノード数を調整する シリアル 変数が含まれます。Red Hat では、デフォルト値 (1) を使用することを強く推奨します。これにより、Ansible がクラスターノードを 1 つずつアップグレードします。

重要

rolling_update.yml Playbook を使用して Red Hat Ceph Storage 3.x バージョンにアップグレードする場合、Ceph ファイルシステム (Ceph FS)を使用するユーザーは、Metadata Server (MDS) クラスターを手動で更新する必要があります。これは、既知の問題によるものです。

ceph-ansible rolling_update.yml を使用してクラスター全体をアップグレードする前に /etc/ansible/hosts の MDS ホストをコメントアウトしてから、MDS を手動でアップグレードします。/etc/ansible/hosts ファイルでは

 #[mdss]
 #host-abc

MDS クラスターの更新方法など、この既知の問題の詳細については、Red Hat Ceph Storage 3.0 リリースノートを参照してください。

重要

Red Hat Ceph Storage クラスターを以前のバージョンからバージョン 3.2 にアップグレードする場合、Ceph Ansible 設定ではデフォルトのオブジェクトストアタイプが BlueStore に設定されます。OSD オブジェクトストアに FileStore を使用する場合は、Ceph Ansible 設定を明示的に FileStore に設定します。これにより、新たにデプロイされ、置き換えられた OSD は FileStore を使用します。

重要

Playbook rolling_update.yml を使用して Red Hat Ceph Storage 3.x バージョンにアップグレードし、マルチサイト Ceph Object Gateway 設定を使用している場合には、マルチサイト設定を指定するために all.yml ファイルを手動で更新する必要はありません。

前提条件

ストレージクラスター内のすべてのノードで root ユーザーとしてログインします。
ストレージクラスターのすべてのノードで、rhel-7-server-extras-rpms リポジトリーを有効にします。
```
# subscription-manager repos --enable=rhel-7-server-extras-rpms
```
Red Hat Ceph Storage 2.x から 3.x にアップグレードする場合は、Ansible 管理ノードと RBD ミラーリングノードで、Red Hat Ceph Storage 3 Tools リポジトリーを有効にします。
```
# subscription-manager repos --enable=rhel-7-server-rhceph-3-tools-els-rpms
```

Ansible 管理ノードで、Ansible リポジトリーを有効にします。

[root@admin ~]# subscription-manager repos --enable=rhel-7-server-ansible-2.6-rpms

Ansible 管理ノードで、ansible パッケージおよび ceph-ansible パッケージの最新バージョンがインストールされていることを確認します。
```
[root@admin ~]# yum update ansible ceph-ansible
```

4.3. ストレージクラスターのアップグレード

手順

Ansible の管理ノードから以下のコマンドを使用します。

root ユーザーとして、/usr/share/ceph-ansible/ ディレクトリーにナビゲートします。
```
[root@admin ~]# cd /usr/share/ceph-ansible/
```
Red Hat Ceph Storage バージョン 3.x から最新バージョンにアップグレードする場合は、この手順をスキップします。group_vars/all.yml ファイルおよび group_vars/osds.yml ファイルをバックアップします。
```
[root@admin ceph-ansible]# cp group_vars/all.yml group_vars/all_old.yml
[root@admin ceph-ansible]# cp group_vars/osds.yml group_vars/osds_old.yml
[root@admin ceph-ansible]# cp group_vars/clients.yml group_vars/clients_old.yml
```
Red Hat Ceph Storage バージョン 3.x から最新バージョンにアップグレードする場合は、この手順をスキップします。Red Hat Ceph Storage 2.x から 3.x にアップグレードする場合は、group_vars/all.yml.sample、group_vars/osds.yml.sample、group_vars/clients.yml.sample ファイルの新しいコピーを作成して、それぞれ group_vars/all.yml、group_vars/osds.yml、group_vars/clients.yml に名前を変更します。それらを開いて編集します。詳しくは、付録A バージョン 2 と 3 の間の Ansible 変数の変更 と「コンテナーへの Red Hat Ceph Storage Cluster のインストール」をご覧ください。
```
[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 group_vars/clients.yml.sample group_vars/clients.yml
```
Red Hat Ceph Storage バージョン 3.x から最新バージョンにアップグレードする場合は、この手順をスキップします。Red Hat Ceph Storage 2.x から 3.x にアップグレードする場合は、group_vars/clients.yml ファイルを開き、以下の行をアンコメントします。
```
keys:
  - { name: client.test, caps: { mon: "allow r", osd: "allow class-read object_prefix rbd_children, allow rwx pool=test" },  mode: "{{ ceph_keyring_permissions }}" }
```
1. client.test を実際のクライアント名に置き換え、クライアントキーをクライアント定義の行に追加します。以下に例を示します。
```
key: "ADD-KEYRING-HERE=="
```
  これで、行全体の例は次のようになります。
```
- { name: client.test, key: "AQAin8tUMICVFBAALRHNrV0Z4MXupRw4v9JQ6Q==", caps: { mon: "allow r", osd: "allow class-read object_prefix rbd_children, allow rwx pool=test" },  mode: "{{ ceph_keyring_permissions }}" }
```
  注記
  クライアントキーを取得するには、ceph auth get-or-create コマンドを実行して、指定されたクライアントのキーを表示します。
2.x から 3.x にアップグレードする場合、group_vars/all.yml ファイルで ceph_docker_image パラメーターを変更して、Ceph 3 コンテナーのバージョンを指すようにします。
```
ceph_docker_image: rhceph/rhceph-3-rhel7
```
group_vars/all.yml ファイルに fetch_directory パラメーターを追加してください。
```
fetch_directory: <full_directory_path>
```
以下を置き換えます。
- <full_directory_path> を、書き込み可能な場所 (Ansible ユーザーのホームディレクトリーなど) に置き換えます。ストレージクラスターの初期インストール時に使用した既存のパスを入力してください。
既存のパスが失われていたり、なくなっていたりする場合は、まず次のことを行ってください。
1. 既存の group_vars/all.yml ファイルに以下のオプションを追加します。
```
fsid: <add_the_fsid>
generate_fsid: false
```
2. take-over-existing-cluster.yml Ansible playbook を実行します。
```
[user@admin ceph-ansible]$ cp infrastructure-playbooks/take-over-existing-cluster.yml .
[user@admin ceph-ansible]$ ansible-playbook take-over-existing-cluster.yml
```
アップグレードするクラスターに Ceph Object Gateway ノードが含まれている場合は、radosgw_interface パラメーターを group_vars/all.yml ファイルに追加します。
```
radosgw_interface: <interface>
```
以下を置き換えます。
- Ceph Object Gateway がリッスンするインターフェースを使用する <interface>
Red Hat Ceph Storage 3.2 から、デフォルトの OSD オブジェクトストアは BlueStore です。従来の OSD オブジェクトストアを維持するには、osd_objectstore オプションを group_vars/all.yml ファイルの filestore に明示的に設定する必要があります。
```
osd_objectstore: filestore
```
注記
osd_objectstore オプションを filestore に設定し、OSD を置き換えると BlueStore ではなく FileStore が使用されます。
/etc/ansible/hosts にある Ansible インベントリーファイルで、[mgrs] セクションの下に Ceph Manager (ceph-mgr) ノードを追加します。Ceph Manager デーモンを Monitor ノードにコロケーションします。バージョン 3.x から最新のバージョンにアップグレードする場合は、この手順をスキップします。
```
[mgrs]
<monitor-host-name>
<monitor-host-name>
<monitor-host-name>
```
infrastructure-playbooks ディレクトリーから現在のディレクトリーに、rolling_update.yml をコピーします。
```
[root@admin ceph-ansible]# cp infrastructure-playbooks/rolling_update.yml .
```
/var/log/ansible/ ディレクトリーを作成し、ansible ユーザーに適切な権限を割り当てます。
```
[root@admin ceph-ansible]# mkdir /var/log/ansible
[root@admin ceph-ansible]# chown ansible:ansible  /var/log/ansible
[root@admin ceph-ansible]# chmod 755 /var/log/ansible
```
1. 次のように log_path 値を更新して、/usr/share/ceph-ansible/ansible.cfg ファイルを編集します。
```
log_path = /var/log/ansible/ansible.log
```
Ansible ユーザーとして、Playbook を実行します。
```
[user@admin ceph-ansible]$ ansible-playbook rolling_update.yml
```
Ansible インベントリーファイルの特定のノードグループにのみ Playbook を使用するには、--limit オプションを使用します。詳細は、「limit オプションについて」を参照してください。
RBD ミラーリングデーモンノードに root ユーザーとしてログインしているときに、rbd-mirror を手動でアップグレードします。
```
# yum upgrade rbd-mirror
```
デーモンを再起動します。
```
# systemctl restart  ceph-rbd-mirror@<client-id>
```
クラスターの健全性に問題がないことを確認します。
1. root ユーザーとしてモニターノードにログインし、実行中のすべてのコンテナーをリストします。
```
[root@monitor ~]# docker ps
```
2. クラスターの正常性が正常であることを確認します。
```
[root@monitor ~]# docker exec ceph-mon-<mon-id> ceph -s
```
  以下を置き換えます。
  - <mon-id> は、最初の手順で見つかった Monitor コンテナーの名前に置き換えます。
  以下は例になります。
```
[root@monitor ~]# docker exec ceph-mon-monitor ceph -s
```

OpenStack 環境で動作する場合には、すべての cephx ユーザーがプールに RBD プロファイルを使用するように更新します。以下のコマンドは root ユーザーとして実行する必要があります。

Glance ユーザー

ceph auth caps client.glance mon 'profile rbd' osd 'profile rbd pool=<glance-pool-name>'

例

[root@monitor ~]# ceph auth caps client.glance mon 'profile rbd' osd 'profile rbd pool=images'

Cinder ユーザー

ceph auth caps client.cinder mon 'profile rbd' osd 'profile rbd pool=<cinder-volume-pool-name>, profile rbd pool=<nova-pool-name>, profile rbd-read-only pool=<glance-pool-name>'

例

[root@monitor ~]# ceph auth caps client.cinder mon 'profile rbd' osd 'profile rbd pool=volumes, profile rbd pool=vms, profile rbd-read-only pool=images'

OpenStack の一般ユーザー
```
ceph auth caps client.openstack mon 'profile rbd' osd 'profile rbd-read-only pool=<cinder-volume-pool-name>, profile rbd pool=<nova-pool-name>, profile rbd-read-only pool=<glance-pool-name>'
```
例
```
[root@monitor ~]# ceph auth caps client.openstack mon 'profile rbd' osd 'profile rbd-read-only pool=volumes, profile rbd pool=vms, profile rbd-read-only pool=images'
```
重要
ライブクライアントの移行を実行する前に、これらの CAPS 更新を行います。これにより、クライアントがメモリーで実行している新しいライブラリーを使用でき、古い CAPS 設定がキャッシュから破棄され、新しい RBD プロファイル設定が適用されるようになります。

4.4. Red Hat Ceph Storage Dashboard のアップグレード

以下の手順では、Red Hat Ceph Storage Dashboard をバージョン 3.1 から 3.2 にアップグレードする手順の概要を説明しています。

アップグレードする前に、Red Hat Ceph Storage がバージョン 3.1 から 3.2 にアップグレードされていることを確認してください。手順は、4.1.ストレージクラスターのアップグレードを参照してください。

警告

アップグレード手順により、ストレージダッシュボードの履歴データが削除されます。

手順

root ユーザーとして、Ansible 管理ノードから cephmetrics-ansible パッケージを更新します。
```
[root@admin ~]# yum update cephmetrics-ansible
```
/usr/share/cephmetrics-ansible ディレクトリーに移動します。
```
[root@admin ~]# cd /usr/share/cephmetrics-ansible
```
更新された Red Hat Ceph ストレージダッシュボードをインストールします。
```
[root@admin cephmetrics-ansible]# ansible-playbook -v playbook.yml
```

第5章 Red Hat Ceph Storage Dashboard を使用したコンテナーで実行されている Ceph クラスターのモニタリング

Red Hat Ceph Storage Dashboard は、Ceph Storage Cluster の状態を視覚化するためのモニタリングダッシュボードを提供します。また、Red Hat Ceph Storage Dashboard アーキテクチャーは、ストレージクラスターに機能を追加する追加のモジュール用のフレームワークを提供します。

Dashboard の詳細は、「Red Hat Ceph Storage Dashboard」を参照してください。
Dashboard をインストールするには、「Red Hat Ceph Storage Dashboard のインストール」を参照してください。
Dashboard にアクセスするには、「Red Hat Ceph Storage Dashboard へのアクセス」を参照してください。
Dashboard のインストール後にデフォルトのパスワードを変更するには、「デフォルトの Red Hat Ceph Storage ダッシュボードパスワードの変更」を参照してください。
Prometheus プラグインの詳細は、「Red Hat Ceph Storage の Prometheus プラグイン」を参照してください。
Red Hat Ceph Storage Dashboard のアラートおよび設定方法について詳しく知るには、「Red Hat Ceph Storage Dashboard アラート」を参照してください。

前提条件

コンテナーで実行されている Red Hat Ceph Storage クラスター

5.1. Red Hat Ceph Storage Dashboard

Red Hat Ceph Storage Dashboard は、Ceph クラスターのモニタリングダッシュボードを提供し、ストレージクラスターの状態を可視化します。ダッシュボードは Web ブラウザーからアクセスでき、クラスター、モニター、OSD、プール、またはネットワークの状態に関するメトリックおよびグラフを多数提供します。

Red Hat Ceph Storage のこれまでのリリースでは、監視データは collectd プラグインを介して提供され、これにより、データを Graphite 監視ユーティリティーのインスタンスに送信されました。Red Hat Ceph Storage 3.3 以降、監視データは ceph-mgr Prometheus プラグインを使用して ceph-mgr デーモンから直接取得されます。

監視データソースとして Prometheus が導入されたことで、Red Hat Ceph Storage Dashboard ソリューションのデプロイメントと操作管理が簡素化され、全体的なハードウェア要件も軽減されました。Ceph モニタリングデータを直接適用することで、Red Hat Ceph Storage Dashboard ソリューションはコンテナーにデプロイされる Ceph クラスターをよりよくサポートできるようになりました。

注記

アーキテクチャーにおけるこの変更により、監視データの Red Hat Ceph Storage 2.x および 3.0 から Red Hat Ceph Storage 3.3 への移行パスはありません。

Red Hat Ceph Storage Dashboard は、以下のユーティリティーを使用します。

デプロイメント用の Ansible 自動化アプリケーション。
埋め込み Prometheus ceph-mgr プラグイン。
ストレージクラスターの各ノードで実行される Prometheus node-exporter デーモン。
ユーザーインターフェースおよびアラートを提供する Grafana プラットフォーム。

Red Hat Ceph Storage Dashboard は以下の機能をサポートします。

一般機能

Red Hat Ceph Storage 3.1 以降のサポート
SELinux サポート
FileStore および BlueStore OSD バックエンドのサポート
暗号化された OSD および暗号化されていない OSD のサポート
Monitor、OSD、Ceph Object Gateway、および iSCSI ロールのサポート
Metadata Servers (MDS) の初期サポート
ドリルダウンおよびダッシュボードのリンク
15 秒の粒度
ハードディスクドライブ (HDD)、ソリッドステートドライブ (SSD)、Non-volatile Memory Express (NVMe) インターフェース、Intel® Cache Acceleration Software (Intel® CAS) のサポート

ノードメトリクス

CPU および RAM の使用状況
ネットワーク負荷

設定可能なアラート

OOB (Out-of-Band) アラートおよびトリガー
インストール時に通知チャネルが自動的に定義される
デフォルトで作成された Ceph Health Summary ダッシュボード
詳細は、「Red Hat Ceph Storage Dashboard Alerts」セクションを参照してください。

クラスターの概要

OSD 設定概要
OSD FileStore および BlueStore の概要
ロール別のクラスターバージョンの内訳
ディスクサイズの概要
容量およびディスク数によるホストサイズ
配置グループ (PG) の状況内訳
プール数
HDD vs などのデバイスクラスの概要SSD

クラスターの詳細

クラスターフラグの状況 (noout、nodown など)
OSD または Ceph Object Gateway ホストの up および down ステータス
プールごとの容量使用度
Raw 容量の使用状況
アクティブなスクラブおよびリカバリープロセスのインジケーター
増加の追跡および予想 (raw 容量)
OSD ホストおよびディスクを含む、 down または near full の OSD に関する情報
OSD ごとの PG の分散
使用過剰または使用不足の OSD を強調するための PG 数別の OSD

OSD のパフォーマンス

1 秒あたりの I/O 操作に関する情報 (IOPS) およびプール別のスループット
OSD パフォーマンスインジケーター
OSD ごとのディスク統計
クラスター全体のディスクスループット
読み取り/書き込み比率 (クライアント IOPS)
ディスク使用率ヒートマップ
Ceph ロールによるネットワーク負荷

Ceph Object Gateway の詳細

集約された負荷ビュー
ホストごとのレイテンシーとスループット
HTTP 操作によるワークロードの内訳

Ceph iSCSI Gateway の詳細

集約ビュー
設定
パフォーマンス
Gateway ごとのリソース使用度
クライアントごとの負荷および設定
Ceph Block Device 別のイメージパフォーマンス

5.2. Red Hat Ceph Storage Dashboard のインストール

Red Hat Ceph Storage Dashboard は、実行中の Ceph Storage Cluster のさまざまなメトリックを監視するビジュアルダッシュボードを提供します。

注記

Red Hat Ceph Storage Dashboard のアップグレードに関する情報は、『Installation Guide for Red Hat Enterprise Linux』の「Upgrading Red Hat Ceph Storage Dashboard」を参照してください。

前提条件

Ansible Automation アプリケーションでデプロイされたコンテナーで実行される Ceph Storage クラスター。
ストレージクラスターノードは Red Hat Enterprise Linux 7 を使用します。
詳細は、「Red Hat Ceph Storage ノードの CDN への登録とサブスクリプションのアタッチ」を参照してください。
クラスターノードからデータを受信し、Red Hat Ceph Storage Dashboard を提供する別のノードである Red Hat Ceph Storage Dashboard ノード。

Red Hat Ceph Storage Dashboard ノードを準備します。

システムを Red Hat コンテンツ配信ネットワーク (CDN) に登録し、サブスクリプションをアタッチして、Red Hat Enterprise Linux リポジトリーを有効にします。詳細は、「Red Hat Ceph Storage ノードの CDN への登録とサブスクリプションのアタッチ」を参照してください。
すべてのノードで Tools リポジトリーを有効にします。
詳細は、Red Hat Ceph Storage 3『Installation Guide for Red Hat Enterprise Linux』の「Enabling the Red Hat Ceph Storage Repositories」セクションを参照してください。

ファイアウォールを使用している場合は、以下の TCP ポートが開いていることを確認します。

表5.1 TCP ポート要件
ポート	使用方法	場所
`3000`	Grafana	Red Hat Ceph Storage Dashboard ノード。
`9090`	基本的な Prometheus グラフ	Red Hat Ceph Storage Dashboard ノード。
`9100`	Prometheus の `node-exporter` デーモン	すべてのストレージクラスターノード。
`9283`	Ceph データの収集	すべての `ceph-mgr` ノード。
`9287`	Ceph iSCSI ゲートウェイデータ	すべての Ceph iSCSI ゲートウェイノード。

詳細は、Red Hat Enterprise Linux 7『Security Guide』の「Using Firewalls」の章を参照してください。

手順

Ansible 管理ノードで root ユーザーとして以下のコマンドを実行します。

cephmetrics-ansible パッケージをインストールします。
```
[root@admin ~]# yum install cephmetrics-ansible
```
Ceph Ansible インベントリーをベースとして使用し、デフォルトでは /etc/ansible/hosts にある Ansible インベントリーファイルの [ceph-grafana] セクションに Red Hat Ceph Storage Dashboard ノードを追加します。
```
[ceph-grafana]
$HOST_NAME
```
以下を置き換えます。
- $HOST_NAME は、Red Hat Ceph Storage Dashboard ノードの名前に置き換えます。
以下は例になります。
```
[ceph-grafana]
node0
```
/usr/share/cephmetrics-ansible/ ディレクトリーに移動します。
```
[root@admin ~]# cd /usr/share/cephmetrics-ansible
```
Ansible Playbook を実行します。
```
[root@admin cephmetrics-ansible]# ansible-playbook -v playbook.yml
```
重要
MON または OSD ノードを追加するなど、クラスター設定を更新するたびに、cephmetrics Ansible Playbook を再実行する必要があります。
注記
cephmetrics Ansible Playbook は以下のアクションを実行します。
- ceph-mgr インスタンスを更新して、prometheus プラグインを有効にし、TCP ポート 9283 を開きます。
- Prometheus node-exporter デーモンをストレージクラスターの各ノードにデプロイします。
  TCP ポート 9100 を開きます。
  node-exporter デーモンを起動します。
- Grafana および Prometheus コンテナーを、Red Hat Ceph Storage Dashboard ノードの Docker/systemd 下にデプロイします。
  Prometheus は、ceph-mgr ノードおよび各 ceph ホストで稼働している node-exporters からデータを収集するように設定されます。
  TCP ポート 3000 を開きます。
  ダッシュボード、テーマ、およびユーザーアカウントはすべて Grafana に作成されます。
  管理者の Grafana の URL を出力します。

5.3. Red Hat Ceph Storage Dashboard へのアクセス

Red Hat Ceph Storage Dashboard にアクセスすると、Red Hat Ceph Storage クラスターを管理する Web ベースの管理ツールにアクセスできます。

前提条件

Red Hat Ceph Storage Dashboard のインストール。
ノードが適切に同期されない場合に Ceph Storage Dashboard ノード、クラスターノード、およびブラウザーとの間でタイムラグが発生する可能性があるため、NTP がクロックを正しく同期していることを確認してください。Red Hat Ceph Storage 3『Installation Guide for Red Hat Enterprise Linux』の「Configuring the Network Time Protocol for Red Hat Ceph Storage」または「Ubuntu」を参照してください。

手順

Web ブラウザーに以下の URL を入力します。
```
http://$HOST_NAME:3000
```
以下を置き換えます。
- $HOST_NAME は、Red Hat Ceph Storage Dashboard ノードの名前に置き換えます。
以下は例になります。
```
http://cephmetrics:3000
```
admin ユーザーのパスワードを入力します。インストール時にパスワードを設定しなかった場合は、デフォルトのパスワードである admin を使用します。
ログインすると、Ceph At a Glance ダッシュボードに自動的に配置されます。Ceph At a Glance ダッシュボードは、ハイレベルの容量の概要、パフォーマンス、およびノードレベルのパフォーマンス情報を提供します。
例

5.4. デフォルトの Red Hat Ceph Storage ダッシュボードパスワードの変更

Red Hat Ceph Storage Dashboard にアクセスするためのデフォルトのユーザー名およびパスワードは admin および admin に設定されます。セキュリティー上の理由から、インストール後にパスワードを変更する必要がある場合があります。

注記

パスワードをデフォルト値にリセットしないようにするには、/usr/share/cephmetrics-ansible/group_vars/all.yml ファイルでカスタムパスワードを更新します。

前提条件

手順

左上隅の Grafana アイコンをクリックします。
パスワードを変更するユーザー名の上にカーソルを合わせます。この場合、admin になります。
Profile をクリックします。
Change Password をクリックします。
新しいパスワードを 2 回入力し、Change Password をクリックします。

その他のリソース

パスワードを忘れた場合は、Grafana Web ページの「Reset admin password」の手順に従います。

5.5. Red Hat Ceph Storage の Prometheus プラグイン

ストレージ管理者は、パフォーマンスデータを収集し、Red Hat Ceph Storage Dashboard の Prometheus プラグインモジュールを使用してそのデータをエクスポートしてから、このデータでクエリーを実行できます。Prometheus モジュールにより、ceph-mgr は Ceph 関連の状態およびパフォーマンスデータを Prometheus サーバーに公開することができます。

5.5.1. 前提条件

Red Hat Ceph Storage 3.1 以降を稼働している。
Red Hat Ceph Storage Dashboard のインストール。

5.5.2. Prometheus プラグイン

Prometheus プラグインは、ceph-mgr のコレクションポイントから Ceph パフォーマンスカウンターに渡すためのエクスポーターを提供します。Red Hat Ceph Storage Dashboard は、Ceph Monitors や OSD などのすべての MgrClient プロセスから MMgrReport メッセージを受信します。歳簿のサンプル数の循環バッファーには、パフォーマンスカウンタースキーマデータと実際のカウンターデータが含まれます。このプラグインは HTTP エンドポイントを作成し、ポーリング時にすべてのカウンターの最新サンプルを取得します。HTTP パスおよびクエリーパラメーターは無視され、すべてのレポートエンティティーのすべての現存カウンターはテキスト表示形式で返されます。

関連情報

テキスト表示形式についての詳細は、Prometheus ドキュメントを参照してください。

5.5.3. Prometheus 環境の管理

Prometheus を使用して Ceph ストレージクラスターを監視するには、Prometheus エクスポーターを設定および有効にし、Ceph ストレージクラスターに関するメタデータ情報を収集できるようにします。

前提条件

稼働中の Red Hat Ceph Storage 3.1 クラスター
Red Hat Ceph Storage Dashboard のインストール

手順

root ユーザーとして、/etc/prometheus/prometheus.yml ファイルを開いて編集します。
1. global セクションで、scrape_interval および evaluation_interval オプションを 15 秒に設定します。
  例
```
global:
  scrape_interval:     15s
  evaluation_interval: 15s
```
2. scrape_configs セクションの下に honor_labels: true オプションを追加し、ceph-mgr ノードごとに targets オプションおよび instance オプションを編集します。
  例
```
scrape_configs:
  - job_name: 'node'
    honor_labels: true
    static_configs:
    - targets: [ 'node1.example.com:9100' ]
      labels:
        instance: "node1.example.com"
    - targets: ['node2.example.com:9100']
      labels:
        instance: "node2.example.com"
```
  注記
  honor_labels オプションを使用すると、Ceph は Ceph Storage クラスターの任意のノードに関連する適切にラベル付けされたデータを出力できます。これにより、Prometheus が上書きせずに Ceph は適切な instance ラベルをエクスポートできます。
3. 新規ノードを追加するには、以下の形式で targets オプションおよび instance オプションを追加します。
  例
```
- targets: [ 'new-node.example.com:9100' ]
  labels:
    instance: "new-node"
```
  注記
  instance ラベルは、Ceph の OSD メタデータの instance フィールドに表示されるノードの短いホスト名と一致する必要があります。これにより、Ceph 統計をノードの統計と関連付けるのに役立ちます。
以下の形式で、Ceph ターゲットを /etc/prometheus/ceph_targets.yml ファイルに追加します。
例
```
[
    {
        "targets": [ "cephnode1.example.com:9283" ],
        "labels": {}
    }
]
```
Prometheus モジュールを有効にします。
```
# ceph mgr module enable prometheus
```

5.5.4. Prometheus データおよびクエリーの使用

統計名は Ceph の名前と同じで、無効な文字がアンダースコアに変換され、すべての名前の先頭に ceph_ が付きます。すべての Ceph デーモン統計には、ceph_daemon ラベルがあります。そのラベルからデーモンのタイプと ID を識別します (例:osd.123)。統計情報の中には、異なる種類のデーモンから得られるものもあるため、クエリを実行するときには、Ceph Monitorと RocksDB の統計情報が混ざらないように、osd で始まる Ceph デーモンに絞り込む必要があります。グローバル Ceph ストレージクラスター統計には、レポート対象に応じたラベルが付けられています。たとえば、プールに関連するメトリクスには pool_id ラベルが付けられます。コア Ceph のヒストグラムを表す長期的な平均値は、sum と count のパフォーマンスメトリクスのペアで表されます。

以下のクエリーの例は、Prometheus expression browser で使用できます。

OSD の物理ディスク使用状況を表示

(irate(node_disk_io_time_ms[1m]) /10) and on(device,instance) ceph_disk_occupation{ceph_daemon="osd.1"}

オペレーティングシステムから見た OSD の物理的な IOPS を表示

irate(node_disk_reads_completed[1m]) + irate(node_disk_writes_completed[1m]) and on (device, instance) ceph_disk_occupation{ceph_daemon="osd.1"}

プールおよび OSD メタデータシリーズ

特定のメタデータフィールドの表示とクエリーを可能にするために、特別なデータシリーズが出力されます。プールには、以下の例のような ceph_pool_metadataフィールドがあります。

ceph_pool_metadata{pool_id="2",name="cephfs_metadata_a"} 1.0

OSD には、以下の例のような ceph_osd_metadataフィールドがあります。

ceph_osd_metadata{cluster_addr="172.21.9.34:6802/19096",device_class="ssd",ceph_daemon="osd.0",public_addr="172.21.9.34:6801/19096",weight="1.0"} 1.0

node_exporter でのドライブ統計の相関

Ceph からの Prometheus 出力は、Prometheus ノードエクスポーターからの汎用ノードモニタリングと併せて使用するように設計されています。Ceph OSD 統計値と汎用ノード監視ドライブ統計値を相関させると、以下の例のような特別なデータシリーズが出力されます。

ceph_disk_occupation{ceph_daemon="osd.0",device="sdd", exported_instance="node1"}

OSD ID でディスクの統計を取得するには、Prometheus クエリーの and 演算子またはアスタリスク (*) 演算子を使用します。すべてのメタデータメトリクスの値は 1 であるため、アスタリスク演算子で中立になります。アスタリスク演算子を使用すると、group_left および group_right グループ化修飾子を使用することができ、結果として得られるメトリックに、クエリの一方から追加ラベルが付けられます。以下は例になります。

rate(node_disk_bytes_written[30s]) and on (device,instance) ceph_disk_occupation{ceph_daemon="osd.0"}

label_replace の使用

label_replace 関数は、クエリのメトリックにラベルを追加したり、ラベルを変更したりすることができます。OSDとそのディスクの書き込み率を相関させるには、次のようなクエリーを使用できます。

label_replace(rate(node_disk_bytes_written[30s]), "exported_instance", "$1", "instance", "(.*):.*") and on (device,exported_instance) ceph_disk_occupation{ceph_daemon="osd.0"}

関連情報

クエリー作成についての詳細は、Prometheus「querying basics」を参照してください。
詳細は、Prometheus の label_replace ドキュメントを参照してください。

5.5.5. Prometheus expression browser の使用

組み込みの Prometheus expression browser を使用して、収集したデータに対してクエリーを実行します。

前提条件

稼働中の Red Hat Ceph Storage 3.1 クラスター
Red Hat Ceph Storage Dashboard のインストール

手順

Web ブラウザーで Prometheus の URL を入力します。
```
http://$DASHBOARD_SEVER_NAME:9090/graph
```
以下を置き換えます。
- $DASHBOARD_SEVER_NAME は、Red Hat Ceph Storage Dashboard サーバーの名前に置き換えます。
Graph をクリックして、クエリーウィンドウにクエリーを入力または貼り付けし、Execute ボタンを押します。
1. コンソールウィンドウの結果を確認します。
Graph をクリックしてレンダリングされたデータを表示します。

関連情報

詳細は、Prometheus Web サイトの Prometheus expression browser ドキュメントを参照してください。

5.5.6. 関連情報

プロメテウスの Web ページ

5.6. Red Hat Ceph Storage Dashboard アラート

本項では、Red Hat Ceph Storage Dashboard でのアラートについて説明します。

Red Hat Ceph Storage Dashboard のアラートの詳細は、「アラートについて」を参照してください。
アラートを表示するには、「Alert Status ダッシュボードへのアクセス」を参照してください。
通知ターゲットを設定するには、「通知ターゲットの設定」を参照してください。
デフォルトのアラートを変更したり、新規のアラートを追加するには、「デフォルトアラートの変更および新規アラートの追加」を参照してください。

5.6.2. アラートについて

Red Hat Ceph Storage Dashboard は、Grafana プラットフォームで提供されるアラートメカニズムをサポートします。メトリクスが特定の値に到達する際に、ダッシュボードが通知を送信するように設定できます。このようなメトリクスは Alert Status ダッシュボードにあります。

デフォルトでは、Alert Status には、Overall Ceph Health、OSDs Down、または Pool Capacity などの特定のメトリクスがすでに含まれています。このダッシュボードに関心のあるメトリクスを追加したり、トリガーの値を変更したりすることができます。

以下は、Red Hat Ceph Storage Dashboard に含まれる事前に定義されたアラートの一覧です。

Overall Ceph Health
Disks Near Full (>85%)
OSD Down
OSD Host Down
PG’s Stuck Inactive
OSD Host Less - Free Capacity Check
OSD’s With High Response Times
Network Errors
Pool Capacity High
Monitors Down
Overall Cluster Capacity Low
OSDs With High PG Count

5.6.3. Alert Status ダッシュボードへのアクセス

Red Hat Ceph Storage Dashboard の特定のアラートは、Alert Status ダッシュボードでデフォルトで設定されます。ここでは、そのアクセス方法を 2 つ紹介します。

手順

ダッシュボードにアクセスするには、以下を行います。

メインの At the Glance Dashboard で、右上隅の Active Alerts パネルをクリックします。

または以下を行います。

Grafana アイコンの横にある左上隅のダッシュボードメニューをクリックします。Alert Status を選択します。

5.6.4. 通知ターゲットの設定

cephmetrics と呼ばれる通知チャンネルはインストール時に自動的に作成されます。事前設定されているアラートはすべて cephmetrics チャネルを参照しますが、アラートを受け取る前に、必要な通知タイプを選択して通知チャネル定義を完了します。Grafana プラットフォームは、メール、Slack、PagerDuty などのさまざまな通知タイプをサポートします。

手順

通知チャネルを設定するには、Grafana Web ページの Alert Notifications セクションの手順に従います。

5.6.5. デフォルトアラートの変更および新規アラートの追加

ここでは、すでに設定されているアラートのトリガー値を変更する方法と、Alert Status ダッシュボードに新しいアラートを追加する方法について説明します。

手順

アラートのトリガー値を変更したり、新しいアラートを追加したりするには、Grafana Webページの「Alerting Engine & Rules Guide」に従います。
重要
カスタムアラートを上書きしないようにするため、トリガーの値を変更したり、新しいアラートを追加したりするときに、Red Hat Ceph Storage Dashboard パッケージをアップグレードしても、Alert Status ダッシュボードは更新されません。

付録A バージョン 2 と 3 の間の Ansible 変数の変更

Red Hat Ceph Storage 3 では、/usr/share/ceph-ansible/group_vars/ ディレクトリーにある構成ファイルの特定の変数が変更されたか、削除されました。以下の表は、すべての変更点を示しています。バージョン3へのアップグレード後は、all.yml.sample と osds.yml.sample を再度コピーし、これらの変更を反映させてください。詳細については、コンテナーで実行される Red Hat Ceph Storage クラスターのアップグレードを参照してください。

旧オプション	新規オプション	File
`mon_containerized_deployment`	`containerized_deployment`	`all.yml`
`ceph_mon_docker_interface`	`monitor_interface`	`all.yml`
`ceph_rhcs_cdn_install`	`ceph_repository_type: cdn`	`all.yml`
`ceph_rhcs_iso_install`	`ceph_repository_type: iso`	`all.yml`
`ceph_rhcs`	`ceph_origin: repository` および `ceph_repository:rhcs` (デフォルトで有効)	`all.yml`
`journal_collocation`	`osd_scenario: collocated`	`osds.yml`
`raw_multi_journal`	`osd_scenario: non-collocated`	`osds.yml`
`raw_journal_devices`	`dedicated_devices`	`osds.yml`
`dmcrytpt_journal_collocation`	`dmcrypt: true` + `osd_scenario: collocated`	`osds.yml`
`dmcrypt_dedicated_journal`	`dmcrypt: true` + `osd_scenario: non-collocated`	`osds.yml`

コンテナーガイド

コンテナーへの Red Hat Ceph Storage のデプロイと管理

第1章 コンテナーへの Red Hat Ceph Storage のデプロイ

1.1. 前提条件

1.1.1. Red Hat Ceph Storage ノードの CDN への登録とサブスクリプションのアタッチ

前提条件

手順

関連情報

1.1.2. sudo アクセスのある Ansible ユーザーの作成

1.1.3. Ansible のパスワードなしの SSH の有効化

前提条件

手順

関連情報

1.1.4. Red Hat Ceph Storage のファイアウォールの設定

1.1.5. HTTP プロキシーの使用

前提条件

手順

1.2. コンテナーへの Red Hat Ceph Storage Cluster のインストール

前提条件

手順

1.3. すべての NVMe ストレージに OSD Ansible 設定の構成

1.4. コンテナーへの Ceph Object Gateway のインストール

1.5. メタデータサーバーのインストール

1.6. NFS-Ganesha ゲートウェイのインストール

前提条件

手順

関連情報

1.7. コンテナーへの Ceph iSCSI ゲートウェイのインストール

1.7.1. コンテナーでの Ceph iSCSI ゲートウェイの設定

1.7.2. コンテナー内の Ceph iSCSI ゲートウェイの削除

1.7.3. iSCSI ターゲットのパフォーマンスの最適化

1.8. limit オプションについて

1.9. 関連情報

第2章 コンテナー化された Ceph デーモンのコロケーション

2.1. コロケーションの仕組みとその利点

コロケーションの仕組み

2.2. 同じ場所に配置されたデーモンの専用リソースの設定

2.3. 関連情報

第3章 コンテナーで実行される Ceph クラスターの管理

3.1. コンテナー内で実行される Ceph デーモンの開始、停止、および再起動

3.2. コンテナー内で実行される Ceph デーモンのログファイルの表示

3.3. コマンドラインインターフェースを使用した Ceph OSD の追加

3.4. コマンドラインインターフェースを使用した Ceph OSD の削除

3.5. OSD ID の保持中に OSD ドライブの置き換え

3.6. Ansible によってデプロイされたクラスターのパージ

第4章 コンテナー内の Red Hat Ceph Storage のアップグレード

4.1. 前提条件

4.2. コンテナーで実行される Red Hat Ceph Storage クラスターのアップグレード

前提条件

4.3. ストレージクラスターのアップグレード

手順

4.4. Red Hat Ceph Storage Dashboard のアップグレード

第5章 Red Hat Ceph Storage Dashboard を使用したコンテナーで実行されている Ceph クラスターのモニタリング

前提条件

5.1. Red Hat Ceph Storage Dashboard

5.2. Red Hat Ceph Storage Dashboard のインストール

5.3. Red Hat Ceph Storage Dashboard へのアクセス

前提条件

手順

関連情報

5.4. デフォルトの Red Hat Ceph Storage ダッシュボードパスワードの変更

5.5. Red Hat Ceph Storage の Prometheus プラグイン

5.5.1. 前提条件

5.5.2. Prometheus プラグイン

5.5.3. Prometheus 環境の管理

5.5.4. Prometheus データおよびクエリーの使用

5.5.5. Prometheus expression browser の使用

5.5.6. 関連情報

5.6. Red Hat Ceph Storage Dashboard アラート

5.6.1. 前提条件

5.6.2. アラートについて

5.6.3. Alert Status ダッシュボードへのアクセス

手順

5.6.4. 通知ターゲットの設定

手順

5.6.5. デフォルトアラートの変更および新規アラートの追加

手順

関連情報

付録A バージョン 2 と 3 の間の Ansible 変数の変更

詳細情報

第1章コンテナーへの Red Hat Ceph Storage のデプロイ

1.1.2. `sudo` アクセスのある Ansible ユーザーの作成

1.8. `limit` オプションについて

第2章コンテナー化された Ceph デーモンのコロケーション

第3章コンテナーで実行される Ceph クラスターの管理

第4章コンテナー内の Red Hat Ceph Storage のアップグレード