インストールガイド

Red Hat Ceph Storage 4

Red Hat Enterprise Linux への Red Hat Ceph Storage のインストール

Red Hat Ceph Storage Documentation Team

概要

本ガイドでは、AMD64 および Intel 64 のアーキテクチャーで実行している Red Hat Enterprise Linux 8 に Red Hat Ceph Storage をインストールする方法を説明します。

第1章 Red Hat Ceph Storage とは

Red Hat Ceph Storage は、スケーラブルでオープンなソフトウェア定義のストレージプラットフォームであり、エンタープライズ向けバージョンの Ceph ストレージシステムと Ceph 管理プラットフォーム、デプロイメントユーティリティー、およびサポートサービスを組み合わせたものです。

Red Hat Ceph Storage は、クラウドインフラストラクチャーおよび Web スケールのオブジェクトストレージ用に設計されています。Red Hat Ceph Storage クラスターは、以下のタイプのノードで構成されます。

Red Hat Ceph Storage Ansible 管理

この種別のノードは、以前のバージョンの Red Hat Ceph Storage に対して実行された従来の Ceph 管理ノードとして機能します。このタイプのノードは、以下の機能を提供します。

  • 集中ストレージクラスター管理。
  • Ceph 設定ファイルおよびキー。
  • 必要に応じて、セキュリティー上の理由からインターネットにアクセスできないノードに Ceph をインストールするためのローカルリポジトリー。

Ceph Monitor

各 Ceph Monitor ノードは ceph-mon デーモンを実行し、ストレージクラスターマップのマスターコピーを維持します。ストレージクラスターマップには、ストレージクラスタートポロジーが含まれます。Ceph ストレージクラスターに接続するクライアントは、Ceph Monitor からストレージクラスターマッピングの現在のコピーを取得します。これにより、クライアントはストレージクラスターからデータの読み取りおよび書き込みが可能になります。

重要

ストレージクラスターは、1 つの Ceph Monitor でのみ実行できます。ただし、実稼働環境のストレージクラスターで高可用性を確保するために、RedHat は少なくとも 3 つの Ceph Monitor ノードを使用したデプロイメントのみをサポートします。Red Hat は、750 Ceph OSD を超えるストレージクラスター用に合計 5 つの Ceph Monitor をデプロイすることを推奨します。

Ceph OSD

各 Ceph Object Storage Device(OSD)ノードは ceph-osd デーモンを実行し、ノードに接続されている論理ディスクと対話します。ストレージクラスターは、データをこれらの Ceph OSD ノードに保存します。

Ceph は、OSD ノードを非常に少ない状態で実行できます (デフォルトは 3 つですが、実稼働ストレージクラスターは適度な規模から初めてより良いパフォーマンスが向上します)。たとえば、ストレージクラスター内の 50 個の Ceph OSD 等。理想的には、Ceph Storage クラスターには複数の OSD ノードがあり、CRUSH マップを適宜設定して障害のドメインを分離できる場合があります。

Ceph MDS

各 Ceph Metadata Server (MDS) ノードは ceph-mds デーモンを実行し、Ceph File System (CephFS) に保管されたファイルに関するメタデータを管理します。Ceph MDS デーモンは、共有ストレージクラスターへのアクセスも調整します。

Ceph Object Gateway

Ceph Object Gateway ノードは ceph-radosgw デーモンを実行し、librados 上に構築されたオブジェクトストレージインターフェースで、アプリケーションに Ceph ストレージクラスターへの RESTful アクセスポイントを提供します。Ceph Object Gateway は以下の 2 つのインターフェースをサポートします。

  • S3

    Amazon S3 RESTful API の大規模なサブセットと互換性のあるインターフェースでオブジェクトストレージ機能を提供します。

  • Swift

    OpenStack Swift API の大規模なサブセットと互換性のあるインターフェースでオブジェクトストレージ機能を提供します。

関連情報

第2章 Red Hat Ceph Storage のインストール要件

図2.1 前提条件のワークフロー

prereq ワークフローのインストール

Red Hat Ceph Storage をインストールする前に、以下の要件をチェックして、各 Monitor、OSD、メタデータサーバー、およびクライアントノードを適宜準備します。

注記

Red Hat Ceph Storage のリリースおよび対応する Red Hat Ceph Storage パッケージのバージョンは、Red Hat カスタマーポータルの「What are the Red Hat Ceph Storage releases and corresponding Ceph package versions?」を参照してください。

2.1. 前提条件

  • ハードウェア が Red Hat Ceph Storage 4 の最小要件を満たしていることを確認します。

2.2. Red Hat Ceph Storage のインストールに関する要件チェックリスト

タスク必須セクション推奨事項

オペレーティングシステムのバージョンの確認

はい

「Red Hat Ceph Storage のオペレーティングシステム要件」

 

Ceph ノードの登録

はい

「Red Hat Ceph Storage ノードの CDN への登録およびサブスクリプションの割り当て」

 

Ceph ソフトウェアリポジトリーの有効化

はい

「Red Hat Ceph Storage リポジトリーの有効化」

 

OSD ノードでの RAID コントローラーの使用

いいえ

「OSD ノードで RAID コントローラーを使用する際の考慮事項」

RAID コントローラーでライトバックキャッシュを有効にすると、OSD ノードの小規模な I/O 書き込みスループットが増大する場合があります。

ネットワークの設定

はい

「Red Hat Ceph Storage のネットワーク設定の確認」

少なくとも、パブリックネットワークが必要です。ただし、クラスター通信用のプライベートネットワークが推奨されます。

ファイアウォールの設定

いいえ

「Red Hat Ceph Storage のファイアウォールの設定」

ファイアウォールは、ネットワークの信頼レベルを大きくすることができます。

Ansible ユーザーの作成

はい

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

すべての Ceph ノードで Ansible ユーザーを作成する必要があります。

パスワードを使用しない SSH の有効化

はい

「Ansible のパスワードなし SSH の有効化」

Ansible で必須。

注記

デフォルトでは、ceph-ansible は、NTP/chronyd を要件としてインストールします。NTP/chronyd がカスタマイズされている場合は、「Red Hat Ceph Storage の手動インストール」セクションの「Red Hat Ceph Storage のネットワークタイムプロトコルの設定」を参照して、Ceph で正しく機能するように NTP/chronyd を構成する方法を理解してください。

2.3. Red Hat Ceph Storage のオペレーティングシステム要件

Red Hat Ceph Storage 4 の初期リリースは、Red Hat Enterprise Linux 7.7 または Red Hat Enterprise Linux 8.1 でサポートされています。Red Hat Ceph Storage 4.1 の現行バージョンは、Red Hat Enterprise Linux 7.8 または Red Hat Enterprise Linux 8.2 でサポートされています。

Red Hat Ceph Storage 4 は、RPM ベースのデプロイメントまたはコンテナーベースのデプロイメントでサポートされます。

重要

Red Hat Ceph Storage 4 を Red Hat Enterprise Linux 7 上に実行中のコンテナーにデプロイすると、Red Hat Enterprise Linux 8 コンテナーイメージで実行している Red Hat Ceph Storage 4 がデプロイされます。

すべてのノードで、同じオペレーティングシステムバージョン、アーキテクチャー、およびデプロイメントタイプを使用します。たとえば、AMD64 アーキテクチャーと Intel 64 アーキテクチャーの両方を備えたノードの混合、Red Hat Enterprise Linux 7 と Red Hat Enterprise Linux 8 オペレーティングシステムの両方を備えたノードの混合、RPM ベースのデプロイメントとコンテナーベースのデプロイメントの両方を備えたノードの混合は使用しないでください。

重要

Red Hat は、異種アーキテクチャー、オペレーティングシステムバージョン、またはデプロイメントタイプを持つクラスターをサポートしません。

SELinux

デフォルトでは、SELinux は Enforcing モードに設定され、ceph-selinux パッケージがインストールされます。SELinux の詳細は、『データのセキュリティーおよび強化機能ガイド』『Red Hat Enterprise Linux 7 SELinux ユーザーおよび管理者のガイド』、および『Red Hat Enterprise Linux 8 SELinux の使用ガイド』を参照してください。

関連情報

要件のチェックリストに戻ります

2.4. Red Hat Ceph Storage ノードの CDN への登録およびサブスクリプションの割り当て

各 Red Hat Ceph Storage ノードをコンテンツ配信ネットワーク (CDN) に登録し、ノードがソフトウェアリポジトリーにアクセスできるように適切なサブスクリプションを割り当てます。各 Red Hat Ceph Storage ノードは、完全な Red Hat Enterprise Linux 8 ベースコンテンツおよび extras リポジトリーコンテンツにアクセスできる必要があります。特に記述がない限り、ストレージクラスター内のベアメタルおよびコンテナーノードで以下の手順を実行します。

注記

インストール時にインターネットにアクセスできないベアメタルの Red Hat Ceph Storage ノードの場合は、Red Hat Satellite サーバーを使用してソフトウェアコンテンツを提供します。ローカルの Red Hat Enterprise Linux 8 Server ISO イメージをマウントし、Red Hat Ceph Storage ノードを ISO イメージに指定します。詳細は、Red Hat サポート にお問い合わせください。

Red Hat Satellite サーバーに Ceph ノードの登録に関する詳細は、Red Hat カスタマーポータルの記事「How to Register Ceph with Satellite 6」および「How to Register Ceph with Satellite 5」を参照してください。

前提条件

  • 有効な Red Hat サブスクリプション
  • Red Hat Ceph Storage ノードはインターネットに接続できるようにする必要があります。
  • Red Hat Ceph Storage ノードへの root レベルのアクセス。

手順

  1. コンテナー デプロイメントの場合には、Red Hat Ceph Storage ノードがデプロイ中にインターネットにアクセス できない 場合に限ります。最初に、インターネットアクセスのあるノードで、以下の手順を実行する必要があります。

    1. ローカル Docker レジストリーを起動します。

      Red Hat Enterprise Linux 7

      # docker run -d -p 5000:5000 --restart=always --name registry registry:2

      Red Hat Enterprise Linux 8

      # podman run -d -p 5000:5000 --restart=always --name registry registry:2

    2. registry.redhat.io がコンテナーレジストリーの検索パスにあることを確認します。

      編集するために、/etc/containers/registries.conf ファイルを開きます。

      [registries.search]
      registries = [ 'registry.access.redhat.com', 'registry.fedoraproject.org', 'registry.centos.org', 'docker.io']

      registry.redhat.io がファイルに含まれていない場合は、これを追加します。

      [registries.search]
      registries = ['registry.redhat.io', 'registry.access.redhat.com', 'registry.fedoraproject.org', 'registry.centos.org', 'docker.io']
    3. Red Hat カスタマーポータルから Red Hat Ceph Storage 4 イメージ、Prometheus イメージ、およびダッシュボードイメージをプルします。

      Red Hat Enterprise Linux 7

      # docker pull registry.redhat.io/rhceph/rhceph-4-rhel8
      # docker pull registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.1
      # docker pull registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8
      # docker pull registry.redhat.io/openshift4/ose-prometheus:4.1
      # docker pull registry.redhat.io/openshift4/ose-prometheus-alertmanager:4.1

      Red Hat Enterprise Linux 8

      # podman pull registry.redhat.io/rhceph/rhceph-4-rhel8
      # podman pull registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.1
      # podman pull registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8
      # podman pull registry.redhat.io/openshift4/ose-prometheus:4.1
      # podman pull registry.redhat.io/openshift4/ose-prometheus-alertmanager:4.1

      注記

      Red Hat Enterprise Linux 7 および 8 はいずれも、Red Hat Enterprise Linux 8 をベースとした同じコンテナーイメージを使用します。

    4. イメージをタグ付けします。

      Red Hat Enterprise Linux 7

       # docker tag registry.redhat.io/rhceph/rhceph-4-rhel8 LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-rhel8
       # docker tag registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.1 LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-node-exporter:v4.1
       # docker tag registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8 LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-dashboard-rhel8
       # docker tag registry.redhat.io/openshift4/ose-prometheus-alertmanager:4.1 LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-alertmanager:4.1
       # docker tag registry.redhat.io/openshift4/ose-prometheus:4.1 LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus:4.1

      置き換え
      • LOCAL_NODE_FQDN を、ローカルホストの FQDN に置き換えます。

      Red Hat Enterprise Linux 8

       # podman tag registry.redhat.io/rhceph/rhceph-4-rhel8 LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-rhel8
       # podman tag registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.1 LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-node-exporter:v4.1
       # podman tag registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8 LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-dashboard-rhel8
       # podman tag registry.redhat.io/openshift4/ose-prometheus-alertmanager:4.1 LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-alertmanager:4.1
       # podman tag registry.redhat.io/openshift4/ose-prometheus:4.1 LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus:4.1

      置き換え
      • LOCAL_NODE_FQDN を、ローカルホストの FQDN に置き換えます。
    5. イメージを、起動したローカルの Docker レジストリーにプッシュします。

      Red Hat Enterprise Linux 7

       # docker push LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-rhel8
       # docker push LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-node-exporter:v4.1
       # docker push LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-dashboard-rhel8
       # docker push LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-alertmanager:4.1
       # docker push LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus:4.1

      置き換え
      • LOCAL_NODE_FQDN を、ローカルホストの FQDN に置き換えます。

      Red Hat Enterprise Linux 8

       # podman push LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-rhel8
       # podman push LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-node-exporter:v4.1
       # podman push LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-dashboard-rhel8
       # podman push LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-alertmanager:4.1
       # podman push LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus:4.1

      置き換え
      • LOCAL_NODE_FQDN を、ローカルホストの FQDN に置き換えます。
    6. /etc/containers/registries.conf ファイルを編集し、ファイル内のポートでホスト FQDN を追加して保存します。

      [registries.insecure]
      registries = ['LOCAL_NODE_FQDN:5000']
      注記

      この手順は、ローカルの Docker レジストリーにアクセスするすべてのストレージクラスターノードで行う必要があります。

    7. Red Hat Enterprise Linux 7 では、docker サービスを再起動します。

      # systemctl restart docker
      注記

      デプロイメント中に RedHat Ceph Storage ノードがインターネットにアクセスできない場合の all.yml ファイルの例は、「Red Hat Ceph Storage クラスターのインストール」インストールを参照してください。

  2. すべてのデプロイメントで、ベアメタル または コンテナー の場合:

    1. ノードを登録します。プロンプトが表示されたら、適切な Red Hat カスタマーポータルの認証情報を入力します。

      # subscription-manager register
    2. CDN から最新のサブスクリプションデータをプルします。

      # subscription-manager refresh
    3. Red Hat Ceph Storage で利用可能なサブスクリプションの一覧を表示します。

      # subscription-manager list --available --all --matches="*Ceph*"

      適切なサブスクリプションを特定し、プール ID を取得します。

    4. サブスクリプションを割り当てます。

      # subscription-manager attach --pool=POOL_ID
      置き換え
      • POOL_ID を、直前の手順で特定したプール ID に置き換えます。
    5. デフォルトのソフトウェアリポジトリーを無効にし、各バージョンの Red Hat Enterprise Linux でサーバーおよび追加のリポジトリーを有効にします。

      Red Hat Enterprise Linux 7

      # subscription-manager repos --disable=*
      # subscription-manager repos --enable=rhel-7-server-rpms
      # subscription-manager repos --enable=rhel-7-server-extras-rpms

      Red Hat Enterprise Linux 8

      # subscription-manager repos --disable=*
      # subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms
      # subscription-manager repos --enable=rhel-8-for-x86_64-appstream-rpms

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

    1. Red Hat Enterprise Linux 7 の場合:

      # yum update
    2. Red Hat Enterprise Linux 8 の場合:

      # dnf update

関連情報

要件のチェックリストに戻ります

2.5. Red Hat Ceph Storage リポジトリーの有効化

Red Hat Ceph Storage をインストールする前に、インストール方法を選択する必要があります。Red Hat Ceph Storage では、以下の 2 つのインストール方法がサポートされます。

  • コンテンツ配信ネットワーク (CDN)

    インターネットに直接接続可能な Ceph ノードを持つ Ceph Storage クラスターの場合は、Red Hat Subscription Manager を使用して必要な Ceph リポジトリーを有効にします。

  • ローカルリポジトリー

    セキュリティー対策がインターネットにアクセスできない Ceph Storage クラスターでは、ISO イメージとして配信される単一のソフトウェアビルドから Red Hat Ceph Storage 4 をインストールします。これにより、ローカルリポジトリーをインストールできます。

前提条件

  • 有効なカスタマーサブスクリプション
  • CDN インストールの場合:

  • 有効にする場合は、Exttra Packages for Enterprise Linux (EPEL) ソフトウェアリポジトリーを無効にします。

    [root@monitor ~]# yum install yum-utils vim -y
    [root@monitor ~]# yum-config-manager --disable epel

手順

  • CDN インストールの場合:

    Ansible 管理ノード で、Red Hat Ceph Storage 4 Tools リポジトリーおよび Ansible リポジトリーを有効にします。

    Red Hat Enterprise Linux 7

    [root@admin ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-tools-rpms --enable=rhel-7-server-ansible-2.8-rpms

    Red Hat Enterprise Linux 8

    [root@admin ~]# subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms --enable=ansible-2.8-for-rhel-8-x86_64-rpms

  • デフォルトでは、Red Hat Ceph Storage リポジトリーは対応するノードの ceph-ansible により有効になります。リポジトリーを手動で有効にするには、以下を実行します。

    注記

    これらのリポジトリーは不要なため、コンテナー化されたデプロイメントでは有効にしないでください。

    Ceph Monitor ノード で、Red Hat Ceph Storage 4 Monitor リポジトリーを有効にします。

    Red Hat Enterprise Linux 7

    [root@monitor ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-mon-rpms

    Red Hat Enterprise Linux 8

    [root@monitor ~]# subscription-manager repos  --enable=rhceph-4-mon-for-rhel-8-x86_64-rpms

    Ceph OSD ノード で、Red Hat Ceph Storage 4 OSD リポジトリーを有効にします。

    Red Hat Enterprise Linux 7

    [root@osd ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-osd-rpms

    Red Hat Enterprise Linux 8

    [root@osd ~]# subscription-manager repos --enable=rhceph-4-osd-for-rhel-8-x86_64-rpms

    RBD ミラーリングCeph クライアントCeph Object GatewaysMetadata ServersNFSiSCSI ゲートウェイDashboard サーバー などのノード種別で Red Hat Ceph Storage 4 Tools リポジトリーを有効にします。

    Red Hat Enterprise Linux 7

    [root@client ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-tools-rpms

    Red Hat Enterprise Linux 8

    [root@client ~]# subscription-manager repos  --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms

  • ISO インストールの場合:

    1. Red Hat カスタマーポータルにログインします。
    2. Downloads をクリックして、Software & Download センターに移動します。
    3. Red Hat Ceph Storage エリアで Download Software をクリックして、最新バージョンのソフトウェアをダウンロードします。

関連情報

要件のチェックリストに戻ります

2.6. OSD ノードで RAID コントローラーを使用する際の考慮事項

必要に応じて、OSD ノードで RAID コントローラーを使用することを検討してください。考慮すべき事項を以下に示します。

  • OSD ノードに 1 ~ 2 GB のキャッシュがインストールされている RAID コントローラーがある場合は、ライトバックキャッシュを有効にすると、I/O 書き込みスループットが向上する可能性があります。ただし、キャッシュは不揮発性である必要があります。
  • 最新の RAID コントローラーにはスーパーキャパシエーターがあり、電力損失イベント中に不揮発性 NAND メモリーに揮発性メモリーを流すのに十分な電力が提供されます。電源の復旧後に、特定のコントローラーとそのファームウェアがどのように動作するかを理解することが重要です。
  • RAID コントローラーによっては、手動の介入が必要になります。ハードドライブは、ディスクキャッシュをデフォルトで有効または無効にすべきかどうかに関わらず、オペレーティングシステムにアドバタイズします。ただし、特定の RAID コントローラーとファームウェアは、このような情報を提供しません。ファイルシステムが破損しないように、ディスクレベルのキャッシュが無効になっていることを確認します。
  • ライトバックキャッシュを有効にして、各 Ceph OSD データドライブにライトバックを設定して、単一の RAID 0 ボリュームを作成します。
  • Serial Attached SCSI (SAS) または SATA 接続の Solid-state Drive (SSD) ディスクも RAID コントローラーに存在する場合は、コントローラーとファームウェアが pass-through モードをサポートしているかどうかを確認します。pass-through モードを有効にすると、キャッシュロジックが回避され、通常は高速メディアの待ち時間が大幅に低くなります。

要件のチェックリストに戻ります

2.7. Object Gateway で NVMe を使用する際の考慮事項

必要に応じて、Ceph Object Gateway に NVMe を使用することを検討してください。

Red Hat Ceph Storage のオブジェクトゲートウェイ機能を使用する予定で、OSD ノードが NVMe ベースの SSD を使用している場合は、『実稼働向け Ceph オブジェクトゲートウェイ』「LVM での NVMe の最適な使用」に記載される手順に従ってください。これらの手順では、ジャーナルとバケットインデックスを SSD に一緒に配置する特別に設計された Ansible Playbook の使用方法を説明します。これにより、すべてのジャーナルを 1 つのデバイスに配置する場合に比べてパフォーマンスを向上させることができます。

要件のチェックリストに戻ります

2.8. Red Hat Ceph Storage のネットワーク設定の確認

すべての Red Hat Ceph Storage ノードにはパブリックネットワークが必要です。Ceph クライアントが Ceph monitor ノードおよび Ceph OSD ノードに到達できるパブリックネットワークにネットワークインターフェースカードが設定されている必要があります。

Ceph がパブリックネットワークとは別のネットワークでハートビート、ピアリング、レプリケーション、および復元を実行できるように、クラスターネットワーク用のネットワークインターフェイスカードがある場合があります。

ネットワークインターフェースを設定し、変更を永続化します。

重要

Red Hat では、パブリックネットワークとプライベートネットワークの両方に単一のネットワークインターフェースカードを使用することは推奨していません。

前提条件

  • ネットワークに接続されたネットワークインターフェースカード。

手順

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

  1. 以下の設定が、公開されているネットワークインターフェースカードに対応する /etc/sysconfig/network-scripts/ifcfg-* ファイルにあることを確認します。

    1. 静的 IP アドレスについて BOOTPROTO パラメーターは none に設定されます。
    2. ONBOOT パラメーターは yes に設定する必要があります。

      これが no に設定されていると、Ceph ストレージクラスターがリブート時にピアに機能しなくなる可能性があります。

    3. IPv6 アドレス指定を使用する場合には、IPV6_FAILURE_FATAL パラメーターを除き、IPV6INIT などの IPV6 パラメーターを yes に設定する必要があります。

      また、Ceph 設定ファイル /etc/ceph/ceph.conf を編集して Ceph に IPv6 を使用するように指示します。指定しないと、Ceph は IPv4 を使用します。

関連情報

要件のチェックリストに戻ります

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

Red Hat CephStorage は、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 を開きます。

firewalld が有効な場合には、以下の手順は任意です。デフォルトでは、ceph-ansible には group_vars/all.yml に以下の設定が含まれ、これにより適切なポートが自動的に開きます。

configure_firewall: True

前提条件

  • ネットワークハードウェアが接続されている。
  • ストレージクラスター内のすべてのノードへの root または sudo アクセスがある。

手順

  1. ストレージクラスター内のすべてのノードで firewalld サービスを起動します。これを有効にして、システムの起動時に実行し、実行していることを確認します。

    # systemctl enable firewalld
    # systemctl start firewalld
    # systemctl status firewalld
  2. すべての監視ノードで、パブリックネットワークでポート 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
  3. すべての 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

    別のクラスターネットワークがある場合には、適切なゾーンでコマンドを繰り返します。

  4. すべての Ceph Manager (ceph-mgr) ノードで、パブリックネットワークでポート 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

    別のクラスターネットワークがある場合には、適切なゾーンでコマンドを繰り返します。

  5. すべての Ceph Metadata Server (ceph-mds) ノードにおいて、パブリックネットワークでポート 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

    別のクラスターネットワークがある場合には、適切なゾーンでコマンドを繰り返します。

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

    1. デフォルトの 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 は、Monitor ノードのネットワークアドレスに置き換えます。
      • 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
    2. 必要に応じて、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 は、Monitor ノードのネットワークアドレスに置き換えます。
      • 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
    3. 任意です。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 は、Monitor ノードのネットワークアドレスに置き換えます。
      • 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

関連情報

要件のチェックリストに戻ります

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

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

前提条件

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

手順

  1. root ユーザーとしてノードにログインします。

    ssh root@HOST_NAME
    置き換え
    • HOST_NAME は、Ceph ノードのホスト名に置き換えます。

      # ssh root@mon01

      プロンプトに従い root パスワードを入力します。

  2. 新しい Ansible ユーザーを作成します。

    adduser USER_NAME
    置き換え
    • USER_NAME は、Ansible ユーザーの新しいユーザー名に置き換えます。

      # adduser admin

      重要

      ceph をユーザー名として使用しないでください。ceph ユーザー名は、Ceph デーモン用に予約されます。クラスター全体で統一されたユーザー名を使用すると、使いやすさが向上しますが、侵入者は通常、そのユーザー名をブルートフォース攻撃に使用するため、明白なユーザー名の使用は避けてください。

  3. このユーザーに新しいパスワードを設定します。

    # passwd USER_NAME
    置き換え
    • USER_NAME は、Ansible ユーザーの新しいユーザー名に置き換えます。

      # passwd admin

      プロンプトが表示されたら、新しいパスワードを 2 回入力します。

  4. 新規に作成されたユーザーの 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

  5. 正しいファイル権限を新しいファイルに割り当てます。

    chmod 0440 /etc/sudoers.d/USER_NAME
    置き換え
    • USER_NAME は、Ansible ユーザーの新しいユーザー名に置き換えます。

      # chmod 0440 /etc/sudoers.d/admin

関連情報

要件のチェックリストに戻ります

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

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

注記

Cockpit の Web ベースのインターフェースを使用して Red Hat Ceph Storage をインストールする場合は、この手順は必要ありません。これは、Cockpit Ceph Installer により独自の SSH キーが生成されるためです。「クラスターのすべてのノードに Cockpit SSH キーをコピー」の手順は、「Cockpit Web インターフェースを使用した Red Hat Ceph Storage のインストール」の章になります。

前提条件

手順

  1. SSH キーペアを生成し、デフォルトのファイル名を受け入れ、パスフレーズを空のままにします。

    [ansible@admin ~]$ ssh-keygen
  2. 公開鍵をストレージクラスター内のすべてのノードにコピーします。

    ssh-copy-id USER_NAME@HOST_NAME
    置き換え
    • USER_NAME は、Ansible ユーザーの新しいユーザー名に置き換えます。
    • HOST_NAME は、Ceph ノードのホスト名に置き換えます。

      [ansible@admin ~]$ ssh-copy-id ceph-admin@ceph-mon01

  3. ユーザーの SSH の config ファイルを作成します。

    [ansible@admin ~]$ touch ~/.ssh/config
  4. 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 ファイルを設定すると、ansible-playbook コマンドを実行するたびに -u USER_NAME オプションを指定する必要がありません。

  5. ~/.ssh/config ファイルに正しいファイルパーミッションを設定します。

    [admin@admin ~]$ chmod 600 ~/.ssh/config

関連情報

要件のチェックリストに戻ります

2.12. Ansible インベントリーの場所の設定

オプションとして、ceph-ansible ステージング環境および実稼働環境用のインベントリーの場所ファイルを設定することができます。

前提条件

  • Ansible 管理ノード。
  • Ansible 管理ノードへのルートレベルのアクセス。
  • ノードにインストールされた ceph-ansible パッケージ。

手順

  1. /usr/share/ceph-ansible ディレクトリーに移動します。

    [root@admin ~]# cd /usr/share/ceph-ansible
  2. ステージングおよび実稼働環境用のサブディレクトリーを作成します。

    [root@admin ~]# mkdir -p inventory/staging inventory/production
  3. ansible.cfg ファイルを編集し、以下の行を追加します。

    [defaults]
    + inventory = ./inventory/staging # Assign a default inventory directory
  4. 各環境用にインベントリーの「hosts」ファイルを作成します。

    [root@admin ~]# touch inventory/staging/hosts
    [root@admin ~]# touch inventory/production/hosts
    1. hosts ファイルを開いて編集し、[mons] セクションの下に Ceph Monitor ノードを追加します。

      [mons]
      MONITOR_NODE_NAME_1
      MONITOR_NODE_NAME_1
      MONITOR_NODE_NAME_1

      [mons]
      mon-stage-node1
      mon-stage-node2
      mon-stage-node3

      注記

      デフォルトでは、Playbook はステージング環境で実行されます。実稼働環境で Playbook を実行するには、以下を実行します。

      [root@admin ~]# ansible-playbook -i inventory/production playbook.yml

関連情報

第3章 Cockpit Web インターフェースを使用した Red Hat Ceph Storage のインストール

本章では、Cockpit Web ベースのインターフェースを使用して、Red Hat Ceph Storage クラスターおよびその他のコンポーネント (メタデータサーバー、Ceph クライアント、Ceph Object Gateway など) をインストールする方法を説明します。

このプロセスは、Cockpit Ceph インストーラーのインストール、Cockpit へのログイン、およびインストーラー内の異なるページを使用してクラスターのインストールの設定と開始で構成されます。

注記

Cockpit Ceph Installer は、実際のインストールを実行するために、ceph-ansible RPM によって提供される Ansible および Ansible Playbook を使用します。これらの Playbook を使用して、Cockpit を使用せずに Ceph をインストールすることは引き続き可能です。このプロセスは本章に関連し、直接の Ansible インストール tまたは Ansible Playbook を直接使用 と呼ばれています。

重要

Cockpit Ceph インストーラーは、現在 IPv6 ネットワークをサポートしていません。IPv6 ネットワークが必要な場合は、Ansible Playbook を使用して Ceph を直接 インストールします。

注記

Ceph の管理と監視に使用されるダッシュボード Web インターフェースは、Cockpit がバックエンドで使用する ceph-ansible RPM の Ansible Playbook によってデフォルトでインストールされます。したがって、Ansible Playbook を直接使用する場合や、Cockpit を使用して Ceph をインストールしたりしても、Dashboard の Web インターフェースもインストールされます。

3.1. 前提条件

  • Ansible Red Hat Ceph Storage の直接インストールに必要な 一般的な前提条件 を完了してください。
  • Firefox または Chrome の最新バージョン。
  • 複数のネットワークを使用してクラスター内トラフィック、クライアントからクラスターへのトラフィック、RADOS ゲートウェイトラフィック、または iSCSI トラフィックをセグメント化する場合は、関連するネットワークがホスト上で既に構成されていることを確認してください。詳細は、『ハードウェアガイド』「ネットワークの留意事項」と、「Cockpit Ceph Installer のネットワークページの完了」のこの章のこのセクションを参照してください。
  • Cockpit Web ベースのインターフェースのデフォルトポート 9090 にアクセスできることを確認します。

3.2. インストール要件

  • Ansible 管理ノードとして機能する 1 つのノード。
  • パフォーマンスメトリックおよびアラートプラットフォームを提供するノード。これは、Ansible 管理ノードと同じ場所に配置することができます。
  • Ceph クラスターを構成する 1 つ以上のノード。インストーラーは、Development/POC と呼ばれるオールインワンインストールをサポートします。このモードでは、全 Ceph サービスを同じノードから実行でき、データレプリケーションはデフォルトでホストレベルの保護ではなく、ディスクにデフォルト設定されます。

3.3. Cockpit Ceph Installer のインストールおよび設定

Cockpit Ceph Installer を使用して Red Hat Ceph Storage クラスターをインストールする前に、Cockpit Ceph Installer を Ansible 管理ノードにインストールする必要があります。

前提条件

  • Ansible 管理ノードへのルートレベルのアクセス。
  • Ansible アプリケーションで使用する ansible ユーザーアカウント。

手順

  1. Cockpit がインストールされていることを確認します。

    $ rpm -q cockpit

    以下に例を示します。

    [admin@jb-ceph4-admin ~]$ rpm -q cockpit
    cockpit-196.3-1.el8.x86_64

    上記の例と同様の出力が表示された場合は、確認用 Cockpit が実行している ステップに進みます。出力が package cockpit is not installed されていない場合は、Install Cockpit のステップに進みます。

  2. 必要に応じて Cockpit をインストールします。

    1. Red Hat Enterprise Linux 8 の場合:

      # dnf install cockpit
    2. Red Hat Enterprise Linux 7 の場合:

      # yum install cockpit
  3. Cockpit が実行中であることを確認します。

    # systemctl status cockpit.socket

    出力に Active: active (listening) が表示されている場合は、Red Hat Ceph Storage 用の Cockpit プラグインのインストール 手順に進みます。代わりに Active: inactive(dead) と表示される場合には、Cockpit の有効化 手順に進んでください。

  4. 必要に応じて、Cockpit を有効にします。

    1. systemctl コマンドを使用して、Cockpit を有効にします。

      # systemctl enable --now cockpit.socket

      以下のような行が表示されます。

      Created symlink /etc/systemd/system/sockets.target.wants/cockpit.socket → /usr/lib/systemd/system/cockpit.socket.
    2. Cockpit が実行中であることを確認します。

      # systemctl status cockpit.socket

      以下のような行が表示されます。

      Active: active (listening) since Tue 2020-01-07 18:49:07 EST; 7min ago
  5. Red Hat Ceph Storage 用の Cockpit Ceph Installer をインストールします。

    1. Red Hat Enterprise Linux 8 の場合:

      # dnf install cockpit-ceph-installer
    2. Red Hat Enterprise Linux 7 の場合:

      # yum install cockpit-ceph-installer
  6. Ansible ユーザーとして、sudo を使用してコンテナーカタログにログインします。

    注記

    デフォルトでは、Cockpit Ceph Installer は root ユーザーを使用して Ceph をインストールします。Ceph をインストールするための前提条件の一部として作成した Ansible ユーザーを使用するには、この手順の残りのコマンドを実行し、sudo を Ansible ユーザーとして実行します。

    Red Hat Enterprise Linux 7

    $ sudo docker login -u CUSTOMER_PORTAL_USERNAME https://registry.redhat.io

    [admin@jb-ceph4-admin ~]$ sudo docker login -u myusername https://registry.redhat.io
    Password:
    Login Succeeded!

    Red Hat Enterprise Linux 8

    $ sudo podman login -u CUSTOMER_PORTAL_USERNAME https://registry.redhat.io

    [admin@jb-ceph4-admin ~]$ sudo podman login -u myusername https://registry.redhat.io
    Password:
    Login Succeeded!

  7. registry.redhat.io がコンテナーレジストリーの検索パスにあることを確認します。

    1. 編集するために、/etc/containers/registries.conf ファイルを開きます。

      [registries.search]
      registries = [ 'registry.access.redhat.com', 'registry.fedoraproject.org', 'registry.centos.org', 'docker.io']

      registry.redhat.io がファイルに含まれていない場合は、これを追加します。

      [registries.search]
      registries = ['registry.redhat.io', 'registry.access.redhat.com', 'registry.fedoraproject.org', 'registry.centos.org', 'docker.io']
  8. Ansible ユーザーとして、sudo を使用して ansible-runner-service を起動します。

    $ sudo ansible-runner-service.sh -s

    [admin@jb-ceph4-admin ~]$ sudo ansible-runner-service.sh -s
    Checking environment is ready
    Checking/creating directories
    Checking SSL certificate configuration
    Generating RSA private key, 4096 bit long modulus (2 primes)
    ..................................................................................................................................................................................................................................++++
    ......................................................++++
    e is 65537 (0x010001)
    Generating RSA private key, 4096 bit long modulus (2 primes)
    ........................................++++
    ..............................................................................................................................................................................++++
    e is 65537 (0x010001)
    writing RSA key
    Signature ok
    subject=C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU = RunnerServer, CN = jb-ceph4-admin
    Getting CA Private Key
    Generating RSA private key, 4096 bit long modulus (2 primes)
    .....................................................................................................++++
    ..++++
    e is 65537 (0x010001)
    writing RSA key
    Signature ok
    subject=C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU = RunnerClient, CN = jb-ceph4-admin
    Getting CA Private Key
    Setting ownership of the certs to your user account(admin)
    Setting target user for ansible connections to admin
    Applying SELINUX container_file_t context to '/etc/ansible-runner-service'
    Applying SELINUX container_file_t context to '/usr/share/ceph-ansible'
    Ansible API (runner-service) container set to rhceph/ansible-runner-rhel8:latest
    Fetching Ansible API container (runner-service). Please wait...
    Trying to pull registry.redhat.io/rhceph/ansible-runner-rhel8:latest...Getting image source signatures
    Copying blob c585fd5093c6 done
    Copying blob 217d30c36265 done
    Copying blob e61d8721e62e done
    Copying config b96067ea93 done
    Writing manifest to image destination
    Storing signatures
    b96067ea93c8d6769eaea86854617c63c61ea10c4ff01ecf71d488d5727cb577
    Starting Ansible API container (runner-service)
    Started runner-service container
    Waiting for Ansible API container (runner-service) to respond
    The Ansible API container (runner-service) is available and responding to requests
    
    Login to the cockpit UI at https://jb-ceph4-admin:9090/cockpit-ceph-installer to start the install

    出力の最後の行には、Cockpit Ceph Installer の URL が含まれます。上記の例では、URL は https://jb-ceph4-admin:9090/cockpit-ceph-installer です。お使いの環境で出力される URL を書き留めておきます。

3.4. Cockpit Ceph Installer SSH 鍵をクラスター内のすべてのノードにコピーします。

Cockpit Ceph Installer は、SSH を使用してクラスター内のノードに接続し、設定します。これを実行するために、インストーラーは SSH キーペアを生成し、パスワードを求められることなくノードにアクセスできるようにします。SSH 公開鍵はクラスター内のすべてのノードに転送される必要があります。

前提条件

手順

  1. Ansible 管理ノードに Ansible ユーザーとしてログインします。

    ssh ANSIBLE_USER@HOST_NAME

    以下に例を示します。

    $ ssh admin@jb-ceph4-admin
  2. SSH 公開鍵を最初のノードにコピーします。

    sudo ssh-copy-id -f -i /usr/share/ansible-runner-service/env/ssh_key.pub _ANSIBLE_USER_@_HOST_NAME_

    以下に例を示します。

    $ sudo ssh-copy-id -f -i /usr/share/ansible-runner-service/env/ssh_key.pub admin@jb-ceph4-mon
    /bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/usr/share/ansible-runner-service/env/ssh_key.pub"
    admin@192.168.122.182's password:
    
    Number of key(s) added: 1
    
    Now try logging into the machine, with:   "ssh 'admin@jb-ceph4-mon'"
    and check to make sure that only the key(s) you wanted were added.

    クラスターのすべてのノードに対してこの手順を繰り返します。

3.5. Cockpit へのログイン

Cockpit Ceph Installer の Web インターフェースは、Cockpit にログインして確認することができます。

前提条件

手順

  1. Web ブラウザーで URL を開きます。

    cockpit でのログインの空のフィールド
  2. Ansible ユーザー名およびそのパスワードを入力します。

    cockpit でのログインユーザーのパス入力
  3. 特権タスクにパスワードを再使用 するラジオボタンをクリックします。

    cockpit ログイン再利用パスワードが有効
  4. ログイン をクリックします。

    cockpit ログイン再利用クリックログイン
  5. Welcome ページをチェックして、インストーラーの動作方法とインストールプロセスの全体的なフローを確認します。

    cockpit でウェルカムページ

    Welcome ページで情報を確認したら、Web ページの右下隅にある Environment ボタンをクリックします。

3.6. Cockpit Ceph インストーラーの環境ページの完了

Environment ページでは、使用するインストールソースや、ストレージにハードディスクドライブ (HDD) とソリッドステートドライブ (SSD) を使用する方法など、クラスターの全体的な側面を構成できます。

前提条件

注記

続いて表示されるダイアログには、一部の設定の右側にあるツールチップがあります。これを表示するには、そのあたりに i のようなアイコンにマウスカーソルを合わせたカーソルをかざすようにカーソルを合わせます。

手順

  1. インストールソース を選択します。Red Hat カスタマーポータルからダウンロードした CD イメージを使用するには、Red Hat Subscription Manager からリポジトリーを使用するか、ISO を選択します。

    cockpit インストールソース

    Red Hat を選択した場合は、他のオプションを指定せずに Target VersionRHCS 4 に設定されます。ISO を選択すると、Target Version が ISO イメージファイルに設定されます。

    重要

    ISO を選択する場合、イメージファイルは /usr/share/ansible-runner-service/iso ディレクトリーにあり、その SELinux コンテキストは container_file_t に設定する必要があります。

    重要

    インストールソースコミュニティー オプションおよび ディストリビューション オプションには対応していません。

  2. Cluster Type を選択します。実稼働 の選択では、CPU 番号やメモリーサイズなどの特定のリソース要件を満たしていないと、インストールが続行できなくなります。リソース要件を満たしている場合でもクラスターのインストールを続行できるようにするには、Development/POC を選択します。

    cockpit でのクラスタータイプ
    重要

    Development/POC モードは、実稼働環境で使用する Ceph クラスターをインストールしないでください。

  3. Service Account Login および Service Account Token を設定します。Red Hat レジストリーサービスアカウントがない場合は、レジストリーサービスアカウントの Web ページ を使用して作成します。

    cockpit でのサービスアカウント
  4. Configure FirewallON に設定して、Ceph サービスのポートを開くルールを firewalld に適用します。firewalld を使用していない場合は、OFF 設定を使用します。

    cockpit でのファイアウォール
  5. 現在、Cockpit Ceph Installer は IPv4 のみをサポートしています。IPv6 サポートが必要な場合は、Cockpit Ceph Installer を使用を停止し、Ansible スクリプトを直接 使用して Ceph のインストールに進む必要があります。

    cockpit でのネットワーク接続
  6. OSD TypeBlueStore または FileStore に設定します。

    cockpit の osd タイプ
    重要

    BlueStore はデフォルトの OSD タイプです。以前のバージョンでは、Ceph は FileStore をオブジェクトストアとして使用していました。BlueStore はより多くの機能を提供し、パフォーマンスを向上させるため、この形式は Red Hat Ceph Storage 4.0 で非推奨になっています。FileStore は依然として使用できますが、サポート例外が必要です。BlueStore の詳細は、『アーキテクチャーガイド』「Ceph BlueStore」を参照してください。

  7. Flash ConfigurationJournal/Logs または OSD データ に設定します。ソリッドステートドライブ (SSD) を使用している場合は、NVMe または従来の SATA/SAS インターフェースのどちらを使用する場合でも、実際のデータがハードディスクドライブ (HDD) に保存されている間、ジャーナルとログの書き込みにのみ使用することを選択できます。ジャーナリング、ログ、およびデータに SSD を使用し、CephOSD 機能に HDD を使用しないでください。

    cockpit でのフラッシュの設定
  8. EncryptionNone または Encrypted に設定します。これは、LUKS1 形式を使用したストレージデバイスの残り暗号化を指します。

    cockpit で暗号化
  9. インストールタイプContainer または RPM に設定します。従来は、Red Hat Enterprise Linux にソフトウェアをインストールするのに Red Hat Package Manager (RPM) が使用されていました。これで、RPM またはコンテナーを使用して Ceph をインストールできます。コンテナーを使用して Ceph をインストールすると、サービスを分離して共存させることができるため、ハードウェアの使用率が向上します。

    cockpit installation type

  10. すべての環境設定を確認し、Web ページの右下隅にある Hosts ボタンをクリックします。

    cockpit ホストボタン

3.7. Cockpit Ceph インストーラーの Hosts ページの完了

Hosts のページでは、Ceph をインストールするホストと各ホストが使用するロールについて Cockpit Ceph Installer に通知することができます。ホストを追加すると、インストーラーは SSH と DNS 接続の有無をチェックします。

前提条件

手順

  1. Add Host(s) ボタンをクリックします。

    ホストの追加ボタン
  2. Ceph OSD ノードのホスト名を入力し、OSD のチェックボックスを選択して 追加 ボタンをクリックします。

    監視ノードの追加

    最初の Ceph OSD ノードが追加されます。

    最初の OSD ノードがインベントリーに表示

    実稼働クラスターの場合、少なくとも 3 つの Ceph OSD ノードを追加するまで、この手順を繰り返します。

  3. 必要に応じて、ホスト名のパターンを使用してノードの範囲を定義します。たとえば、jb-ceph4-osd2jb-ceph4-osd3 を同時に追加するには、jb-ceph4-osd[2-3] を入力します。

    パターン範囲を使用した OSD の追加

    jb-ceph4-osd2jb-ceph4-ods3 の両方が追加されます。

    Multiple OSDs are added to the inventory

  4. クラスター内の他のノードについて上記の手順を繰り返します。

    1. 実稼働クラスターの場合は、少なくとも 3 つの Ceph Monitor ノードを追加します。ダイアログでは、ロールは MON として一覧表示されます。
    2. Metrics の役割を持つノードを追加します。Metrics ロールは Grafana および Prometheus をインストールし、Ceph クラスターのパフォーマンスに関するリアルタイムの洞察を提供します。これらのメトリクスは Ceph Dashboard に提示されています。これにより、クラスターの監視および管理が可能になります。Dashboard、Grafana、および Prometheus のインストールが必要です。Ansible Administration ノードでメトリック関数を同じ場所に配置できます。これを実行する場合は、ノードのシステムリソースが スタンドアロンのメトリックノードに必要とされるもの よりも大きいことを確認します。
    3. 必要に応じて MDS ロールを持つノードを追加します。MDS ロールは Ceph Metadata Server (MDS) をインストールします。Ceph File System をデプロイするには、メタデータサーバーデーモンが必要です。
    4. 必要に応じて RGW ロールを持つノードを追加します。RGW ロールは、Ceph Object Gateway もインストールします。RADOS ゲートウェイは、librados API 上に構築されたオブジェクトストレージインターフェースで、Ceph ストレージクラスターに RESTful ゲートウェイを提供するアプリケーションを提供します。Amazon S3 および OpenStack Swift API をサポートします。
    5. 必要に応じて iSCSI ロールを持つノードを追加します。iSCSI ロールは iSCSI ゲートウェイをインストールするため、iSCSI で Ceph ブロックデバイスを共有することができます。Ceph で iSCSI を使用するには、マルチパス I/O 用に iSCSI ゲートウェイを少なくとも 2 つのノードにインストールする必要があります。
  5. 必要に応じて、ノードを追加する際に複数のロールを選択して、同じノードに複数のサービスを割り当てます。

    ノード上での複数サービスのコロケーション

    デーモンを同じ場所に配置するデーモンの詳細は、『インストールガイド』「コンテナー化された Ceph デーモンのコロケーション」を参照してください。

  6. 必要に応じて、テーブルのロールをオンまたはオフにして、ノードに割り当てられたロールを変更します。

    表のロールの変更
  7. 必要に応じて、ノードを削除するには、削除するノードの行の右端にあるケバブアイコンをクリックし、Delete をクリックします。

    ノードの削除
  8. クラスター内のすべてのノードを追加したら、ページの右下隅にある Validate ボタンをクリックして、必要なロールをすべて設定します。

    ノードの検証
注記

実稼働クラスターの場合は、3 つまたは 5 台のモニターがない場合に Cockpit Ceph インストーラーは続行されません。この例では、Cluster TypeDevelopment/POC に設定されているため、インストールは 1 つのモニターのみを続行できます。

3.8. Cockpit Ceph インストーラーの Validate ページの完了

Validate ページでは、Hosts ページで指定したノードをプローブし、使用するロールのハードウェア要件を満たしていることを確認してください。

前提条件

手順

  1. Probe Hosts ボタンをクリックします。

    プローブホストボタンのクリック

    続行するには、OK ステータス を持つホストを少なくとも 3 台選択する必要があります。

  2. 必要に応じて、ホストについて警告またはエラーが生成された場合は、ホストのチェックマークの左側にある矢印をクリックして、問題を表示します。

    エラーの検証
    エラーの詳細の検証
    重要

    Cluster TypeProduction に設定すると、生成されたエラーによって StatusNOTOK となり、インストール用に選択できなくなります。エラーを解決する方法は、次の手順を参照してください。

    重要

    Cluster TypeDevelopment/POC に設定すると、生成されたエラーは警告として一覧表示されるため、Status は常に OK になります。これにより、ホストが要件や提案を満たしているかどうかに関係なく、ホストを選択して Ceph をインストールできます。必要に応じて警告を解決できます。警告を解決する方法については、次の手順を参照してください。

  3. 必要に応じて、エラーと警告を解決するには、以下のメソッドを 1 つ以上使用します。

    1. エラーや警告を解決する最も簡単な方法は、特定のロールを完全に無効にしたり、1 台のホストでロールを無効にして、必要なリソースがある別のホストで有効にすることです。

      Development/POC クラスターをインストールしている場合は、警告が残っていても安心して進めることができ、実稼働 クラスターをインストールする場合は、少なくとも 3 台のホストに割り当てられたロールに必要なリソースがすべて揃っていて、警告が残っていても安心して進めることができる組み合わせが見つかるまで、ロールの有効化と無効化を試してみてください。

    2. 必要なロールの要件を満たす新規ホストを使用することもできます。まず、ホスト ページに戻り、問題のあるホストを削除します。

      ホストの削除

      次に、新規ホストを追加 します。

    3. ホストのハードウェアをアップグレードするか、または何らかの方法で要件または提案を満たすには、最初にホストに変更を加えてから、再度 ホストのプローブ をクリックします。オペレーティングシステムを再インストールする必要がある場合は、再度 SSH キーをコピーする 必要があります。
  4. ホストの横にあるチェックボックスを選択して、Red Hat Ceph Storage をインストールするホストを選択します。

    インストール用のホストの選択
    重要

    実稼働クラスターをインストールする場合は、インストール用にエラーを選択する前にエラーを解決する必要があります。

  5. ページの右下隅の Network ボタンをクリックして、クラスターのネットワークを確認し、設定します。

    ネットワークボタンをクリックします。

3.9. Cockpit Ceph インストーラーのネットワークページの完了

Network ページでは、特定のクラスター通信タイプを特定のネットワークに分離することができます。これには、クラスターのホスト全体に複数の異なるネットワークを設定する必要があります。

重要

Network ページは、Validate ページで実行されたプローブから収集された情報を使用して、ホストがアクセスできるネットワークを表示します。現在、Network ページにすでに進む場合は、新規ネットワークをホストに追加したり、Validate ページに戻り、ホストを再プローブしてから、再度 Network ページに移動して新しいネットワークを使用することができません。選択のためには表示されません。Network ページに移動してからホストに追加したネットワークを使用するには、Web ページを完全に更新し、最初からインストールを再起動する必要があります。

重要

実稼働クラスターの場合は、クラスター内トラフィックをクライアントからクラスターへのトラフィックから別々の NIC に分離する必要があります。クラスタートラフィックの種別を分離する他に、Ceph クラスターの設定時に、ネットワークについて考慮すべき他の考慮点があります。詳細は、『ハードウェアガイド』「ネットワークの考慮事項」を参照してください。

前提条件

手順

  1. ネットワークページで設定できるネットワーク種別を書き留めておきます。各タイプには独自の列があります。クラスターネットワーク および パブリックネットワーク の列は常に表示されます。RADOS Gateway ロールでホストをインストールする場合は、S3 Network 列が表示されます。iSCSI ロールでホストをインストールする場合は、iSCSI ネットワーク の列が表示されます。以下の例では、Cluster NetworkPublic Network、および S3 Network の列が表示されます。

    ネットワークページおよびネットワーク種別
  2. 各ネットワーク種別に選択できるネットワークを書き留めておきます。特定のネットワーク種別を構成する全ホストで利用可能なネットワークのみが表示されます。以下の例では、クラスター内の全ホストで利用可能なネットワークが 3 つあります。3 つのネットワークはすべて、ネットワーク種別を構成する全ホストセットで利用可能であるため、各ネットワーク種別には同じ 3 つのネットワークが一覧表示されます。

    選択可能なネットワーク

    利用可能な 3 つのネットワークは、192.168.122.0/24192.168.123.0/24、および 192.168.124.0/24 です。

  3. 各ネットワークが操作する速度を書き留めておきます。これは、特定のネットワークに使用される NIC の速度です。以下の例では、192.168.123.0/24 および 192.168.124.0/24 は 1,000 mbps になります。Cockpit Ceph Installer は 192.168.122.0/24 ネットワークの速度を把握できませんでした。

    ネットワーク速度
  4. 各ネットワークタイプに使用するネットワークを選択します。実稼働クラスターの場合は、Cluster Network および Public Network 用に別個のネットワークを選択する必要があります。Development/POC クラスターでは、両方のタイプに同じネットワークを選択するか、すべてのホストにネットワークが 1 つのみ設定されている場合は、そのネットワークのみが表示され、他のネットワークを選択できなくなります。

    ネットワークの選択

    192.168.122.0/24 ネットワークは パブリックネットワーク に使用され、192.168.123.0/24 ネットワークが クラスターネットワーク に使用されます。また、192.168.124.0/24 ネットワークは S3 ネットワーク に使用されます。

  5. ページの右下隅にある Review ボタンをクリックして、インストール前にクラスター設定全体を確認します。

    Review ボタンをクリックします

3.10. インストール設定の確認

Review ページを使用すると、前のページで設定した Ceph クラスターのインストール設定の詳細と、以前のページに含まれていなかったホストに関する詳細を表示できます。

前提条件

手順

  1. レビューページを表示します。

    Review ページの表示
  2. Review ページに表示されるように、各ページの情報が予想どおりに表示されていることを確認します。Environment ページの情報の概要が 1Hosts ページが 2Validate ページが 3Network ページが 4、ホストの詳細 (前のページには含まれていなかったいくつかの追加の詳細を含む) が 5 にあります。

    確認ページのハイライト
  3. ページの右下隅にある Deploy ボタンをクリックして、実際のインストールプロセスを確定および開始できる Deploy ページに移動します。

    デプロイボタンをクリックします

3.11. Ceph クラスターのデプロイ

Deploy ページを使用すると、インストール設定をネイティブの Ansible 形式で保存し、必要に応じてそれらの設定の確認または変更、インストールの開始、その進捗の監視、インストールが正常に完了した後にクラスターのステータスを表示することができます。

前提条件

手順

  1. ページの右下隅にある Save ボタンをクリックして、実際にインストールを実行するために Ansible が使用する Ansible Playbook にインストール設定を保存します。

    Save ボタンをクリックします
  2. 必要に応じて、Ansible 管理ノードにある Ansible Playbook の設定を表示するか、またはカスタマイズします。Playbook は /usr/share/ceph-ansible にあります。Ansible Playbook の詳細と、これらを使用してインストールをカスタマイズする方法については、「Red Hat Ceph Storage クラスターのインストール」を参照してください。
  3. Grafana およびダッシュボードのデフォルトユーザー名およびパスワードを保護します。Red Hat Ceph Storage 4.1 以降、/usr/share/ceph-ansible/group_vars/all.ymldashboard_admin_password および grafana_admin_password をコメント解除するか設定する必要があります。それぞれに安全なパスワードを設定します。dashboard_admin_user および grafana_admin_user のカスタムユーザー名も設定します。
  4. ページの右下隅にある Deploy ボタンをクリックして、インストールを開始します。

    デプロイボタンをクリックします
  5. 実行中のインストールの進捗を確認します。

    1 にある情報は、インストールが実行しているかどうか、開始時間、および経過時間を示します。2 にある情報は、試行された Ansible タスクの概要を示しています。3 にある情報は、インストールされているロールまたはインストールしているロールを示しています。緑色は、そのロールに割り当てられたすべてのホストにそのロールがインストールされているロールを表します。青色は、ロールが割り当てられているホストが依然としてインストールされているロールを表します。4 の場合は、現在のタスクの詳細を表示したり、失敗したタスクを表示できます。Filter by メニューを使用して、現在のタスクと失敗したタスクを切り換えます。

    インストールの進捗

    ロール名は、Ansible インベントリーファイルから取得されます。mons は Monitors で、mgrs は Managers で、osd は Object Storage Devices で、mdss はメタデータサーバーで、rgws は RADOS ゲートウェイで、metrics はダッシュボードメトリクスの Grafana および Prometheus サービスです。スクリーンショットの例には表示されません。iscsigws は iSCSI ゲートウェイです。

  6. インストールが完了したら、ページの右下隅にある Complete ボタンをクリックします。これにより、ceph status コマンドの出力と Dashboard のアクセス情報を表示するウィンドウが開きます。

    完了ボタン
  7. 以下の例のクラスターステータス情報を、クラスターのクラスターステータス情報と比較します。この例では、すべての OSD が稼働中、およびすべてのサービスがアクティブな正常なクラスターを示しています。PG は、active+clean 状態です。クラスターの一部の要素が同一ではない場合は、『トラブルシューティングガイド』で問題の解決方法に関する情報を参照してください。

    Ceph Cluster Status ウィンドウ
  8. Ceph Cluster Status ウィンドウ下部に、URL、ユーザー名、パスワードなど、Dashboard のアクセス情報が表示されます。この情報を書き留めておいてください。

    ダッシュボードのアクセス情報
  9. ダッシュボードにアクセス するには、ダッシュボードガイド と共に前のステップの情報を使用します。

    ダッシュボード

    ダッシュボードは Web インターフェースを提供するので、Red Hat Ceph Storage クラスターを管理および監視することができます。詳細は、『ダッシュボードガイド』を参照してください。

  10. オプション: cockpit-ceph-installer.log ファイルを表示します。このファイルは、作成された選択のログを記録し、生成されたプローブプロセスに関連する警告を記録します。これは、インストーラースクリプトを実行したユーザーのホームディレクトリー ansible-runner-service.sh にあります。

第4章 Ansible を使用した Red Hat Ceph Storage のインストール

本章では、Ansible アプリケーションを使用して Red Hat Ceph Storage クラスターおよびその他のコンポーネントをデプロイする方法を説明します (メタデータサーバーや Ceph Object Gateway など)。

4.1. 前提条件

4.2. Red Hat Ceph Storage クラスターのインストール

Playbook ceph-ansible で Ansible アプリケーションを使用して、ベアメタルまたはコンテナーに Red Hat Ceph Storage をインストールします。実稼働環境で Ceph ストレージクラスターを使用するには、最小で 3 つの監視ノードと、複数の OSD デーモンが含まれる OSD ノードが必要です。通常、実稼働環境で実行されている一般的な Ceph ストレージクラスターは、10 台以上のノードで構成されます。

以下の手順では、特に指示しない限り、Ansible 管理ノードからコマンドを実行します。この手順は、指定しない限り、ベアメタルおよびコンテナーのデプロイメントの両方に適用されます。

Ceph Storage クラスターの更新
重要

Ceph は 1 台のモニターで実行できますが、実稼働クラスターで高可用性を確保するために、Red Hat は少なくとも 3 つの監視ノードを持つデプロイメントのみをサポートします。

重要

Red Hat Ceph Storage 4 を Red Hat Enterprise Linux 7.7 のコンテナーにデプロイすると、Red Hat Ceph Storage 4 が Red Hat Enterprise Linux 8 コンテナーイメージにデプロイされます。

前提条件

  • 有効なカスタマーサブスクリプションです。
  • Ansible 管理ノードへのルートレベルのアクセス。
  • Ansible アプリケーションで使用する ansible ユーザーアカウント。
  • Red Hat Ceph Storage Tools および Ansible リポジトリーの有効化
  • ISO インストールの場合は、Ansible ノードに最新の ISO イメージをダウンロードします。『Red Hat Ceph Storage インストールガイド』「Red Hat Ceph Storage リポジトリーの有効化」の章の 「ISO のインストール」セクションを参照してください。

手順

  1. Ansible 管理ノードで root ユーザーアカウントとしてログインします。
  2. すべてのデプロイメント (ベアメタル または コンテナー 内) については、ceph-ansible パッケージをインストールします。

    Red Hat Enterprise Linux 7

    [root@admin ~]# yum install ceph-ansible

    Red Hat Enterprise Linux 8

    [root@admin ~]# dnf install ceph-ansible

  3. /usr/share/ceph-ansible ディレクトリーに移動します。

    [root@admin ~]$ cd /usr/share/ceph-ansible
  4. 新しい yml ファイルを作成します。

    [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
    1. ベアメタル デプロイメント:

      [root@admin ceph-ansible]# cp site.yml.sample site.yml
    2. コンテナー デプロイメント:

      [root@admin ceph-ansible]# cp site-container.yml.sample site-container.yml
  5. 新しいファイルを編集します。

    1. group_vars/all.yml ファイルを編集するために開きます。

      重要

      カスタムストレージクラスター名の使用はサポートされていません。cluster パラメーターには ceph 以外の値を設定しないでください。カスタムストレージクラスター名は、librados、Ceph Object Gateway、RADOS ブロックデバイスミラーリングなどの Ceph クライアントでのみサポートされます。

      警告

      デフォルトでは、Ansible はインストール済みの再起動を試みますが、マスクされた firewalld サービスにより、Red Hat Ceph Storage デプロイメントが失敗する可能性があります。この問題を回避するには、all.yml ファイルで configure_firewall オプションを false に設定します。firewalld サービスを実行している場合は、all.yml ファイルで configure_firewall オプションを使用する必要はありません。

      注記

      ceph_rhcs_version オプションを 4 に設定すると、最新バージョンの Red Hat Ceph Storage 4 がプルされます。

      注記

      Red Hat は、group_vars/all.yml ファイルで dashboard_enabled オプションを True に設定し、これを False に変更しないことを推奨します。Dashboard を無効にする場合には、「Disabling the Ceph Dashboard」を参照してください。

      注記

      Dashboard 関連のコンポーネントはコンテナー化されています。したがって、ベアメタル または コンテナー のデプロイメントでは、「ceph_docker_registry_username」および「ceph_docker_registry_password」のパラメーターを追加して、ceph-ansible が、ダッシュボードに必要なコンテナーイメージを取得できるようにする必要があります。

      注記

      Red Hat レジストリーサービスアカウントがない場合は、レジストリーサービスアカウントの Web ページ を使用して作成します。トークンの作成および管理方法に関する詳細は、ナレッジベースアーティクル「Red Hat Container Registry Authentication」を参照してください。

      1. CDN インストール用の all.yml ファイルの ベアメタル の例:

        fetch_directory: ~/ceph-ansible-keys
        ceph_origin: repository
        ceph_repository: rhcs
        ceph_repository_type: cdn
        ceph_rhcs_version: 4
        bootstrap_dirs_owner: "167"
        bootstrap_dirs_group: "167"
        monitor_interface: eth0
        public_network: 192.168.0.0/24
        ceph_docker_registry: registry.redhat.io
        ceph_docker_registry_auth: true
        ceph_docker_registry_username: SERVICE_ACCOUNT_USER_NAME
        ceph_docker_registry_password: TOKEN
        dashboard_admin_user:
        dashboard_admin_password:
        node_exporter_container_image: registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.1
        grafana_admin_user:
        grafana_admin_password:
        grafana_container_image: registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8
        prometheus_container_image: registry.redhat.io/openshift4/ose-prometheus:4.1
        alertmanager_container_image: registry.redhat.io/openshift4/ose-prometheus-alertmanager:4.1
        重要

        Red Hat Ceph Storage 4.1 以降、/usr/share/ceph-ansible/group_vars/all.ymldashboard_admin_password および grafana_admin_password をコメント解除するか設定する必要があります。それぞれに安全なパスワードを設定します。dashboard_admin_user および grafana_admin_user のカスタムユーザー名も設定します。

      2. ISO インストール all.yml ファイルの ベアメタル の例:

        fetch_directory: ~/ceph-ansible-keys
        ceph_origin: repository
        ceph_repository: rhcs
        ceph_repository_type: iso
        ceph_rhcs_iso_path: /home/rhceph-4-rhel-8-x86_64.iso
        ceph_rhcs_version: 4
        bootstrap_dirs_owner: "167"
        bootstrap_dirs_group: "167"
        monitor_interface: eth0 1
        public_network: 192.168.0.0/24
        ceph_docker_registry: registry.redhat.io
        ceph_docker_registry_auth: true
        ceph_docker_registry_username: SERVICE_ACCOUNT_USER_NAME
        ceph_docker_registry_password: TOKEN
        dashboard_admin_user:
        dashboard_admin_password:
        node_exporter_container_image: registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.1
        grafana_admin_user:
        grafana_admin_password:
        grafana_container_image: registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8
        prometheus_container_image: registry.redhat.io/openshift4/ose-prometheus:4.1
        alertmanager_container_image: registry.redhat.io/openshift4/ose-prometheus-alertmanager:4.1
        1
        これは、パブリックネットワーク上のインターフェースです。
      3. all.yml ファイルの Containers の例:

        fetch_directory: ~/ceph-ansible-keys
        monitor_interface: eth0 1
        public_network: 192.168.0.0/24
        ceph_docker_image: rhceph/rhceph-4-rhel8
        containerized_deployment: true
        ceph_docker_registry: registry.redhat.io
        ceph_docker_registry_auth: true
        ceph_docker_registry_username: SERVICE_ACCOUNT_USER_NAME
        ceph_docker_registry_password: TOKEN
        ceph_origin: repository
        ceph_repository: rhcs
        ceph_repository_type: cdn
        ceph_rhcs_version: 4
        bootstrap_dirs_owner: "167"
        bootstrap_dirs_group: "167"
        dashboard_admin_user:
        dashboard_admin_password:
        node_exporter_container_image: registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.1
        grafana_admin_user:
        grafana_admin_password:
        grafana_container_image: registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8
        prometheus_container_image: registry.redhat.io/openshift4/ose-prometheus:4.1
        alertmanager_container_image: registry.redhat.io/openshift4/ose-prometheus-alertmanager:4.1
        1
        これは、パブリックネットワーク上のインターフェースです。
        重要

        Red Hat Ecosystem Catalog で最新のコンテナーイメージタグを検索し、最新のパッチが適用された最新のコンテナーイメージをインストールします。

      4. デプロイメント中に Red Hat Ceph Storage ノードがインターネットにアクセスできない場合の、all.yml ファイルの Containers の例:

        fetch_directory: ~/ceph-ansible-keys
        monitor_interface: eth0 1
        public_network: 192.168.0.0/24
        ceph_docker_image: rhceph/rhceph-4-rhel8
        containerized_deployment: true
        ceph_docker_registry: LOCAL_NODE_FQDN:5000
        ceph_docker_registry_auth: false
        ceph_origin: repository
        ceph_repository: rhcs
        ceph_repository_type: cdn
        ceph_rhcs_version: 4
        bootstrap_dirs_owner: "167"
        bootstrap_dirs_group: "167"
        dashboard_admin_user:
        dashboard_admin_password:
        node_exporter_container_image: LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-node-exporter:v4.1
        grafana_admin_user:
        grafana_admin_password:
        grafana_container_image: LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-dashboard-rhel8
        prometheus_container_image: LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus:4.1
        alertmanager_container_image: LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-alertmanager:4.1
        1
        これは、パブリックネットワーク上のインターフェースです。
        置き換え
        • LOCAL_NODE_FQDN を、ローカルホストの FQDN に置き換えます。
    2. すべてのデプロイメント (ベアメタル または コンテナー) の場合は、編集するために group_vars/osds.yml ファイルを開きます。

      重要

      オペレーティングシステムがインストールされているデバイスに OSD をインストールしないでください。オペレーティングシステムと OSD 間で同じデバイスを共有すると、パフォーマンスの問題が発生することになります。

      ceph-ansible は ceph-volume ツールを使用して、Ceph の使用に向けてストレージデバイスを準備します。ストレージデバイスを使用するように osds.yml を設定し、特定のワークロードのパフォーマンスを最適化することができます。

      重要

      以下の例では、BlueStore オブジェクトストアを使用します。これは、Ceph がデバイスにデータを保存するのに使用する形式です。以前のバージョンでは、Ceph は FileStore をオブジェクトストアとして使用していました。BlueStore はより多くの機能を提供し、パフォーマンスを向上させるため、この形式は Red Hat Ceph Storage 4.0 で非推奨になっています。FileStore は依然として使用できますが、Red Hat サポート例外が必要です。BlueStore の詳細は、『Red Hat Ceph Storage アーキテクチャーガイド』「Ceph BlueStore」を参照してください。

      1. 自動検出

        osd_auto_discovery: true

        上記の例では、システム上の空のストレージデバイスをすべて使用して OSD を作成するため、明示的に指定する必要はありません。この ceph-volume ツールは、空のデバイスを確認するため、空ではないデバイスは使用されません。

      2. 簡易設定

        初回のシナリオ

        devices:
          - /dev/sda
          - /dev/sdb

        または

        2 つ目のシナリオ

        devices:
          - /dev/sda
          - /dev/sdb
          - /dev/nvme0n1
          - /dev/sdc
          - /dev/sdd
          - /dev/nvme1n1

        または

        3 つ目のシナリオ

        lvm_volumes:
           - data: /dev/sdb
           - data: /dev/sdc

        または

        4 つ目のシナリオ

        lvm_volumes:
            - data: /dev/sdb
            - data:/dev/nvme0n1

        devices オプションのみを使用する場合には、ceph-volume lvm batch モードは OSD 設定を自動的に最適化します。

        最初のシナリオでは、devices を従来のハードドライブまたは SSD の場合には、デバイスごとに OSD が 1 つ作成されます。

        2 つ目のシナリオでは、従来のハードドライブと SSD が混在している場合、データは従来のハードドライブ (sdasdb) に配置され、BlueStore データベースは SSD (nvme0n1) にできる限り大きく作成されます。同様に、データは従来のハードドライブ (sdcsdd) に配置され、デバイスの順序に関係なく、SSD nvme1n1 に BlueStore データベースが作成されます。

        3 つ目のシナリオでは、データは従来のハードドライブ (sdbsdc) に置かれ、BlueStore データベースは同じデバイスに置かれます。

        4 番目のシナリオでは、従来のハードドライブ (sdb) および SSD (nvme1n1) にデータが配置され、BlueStore データベースが同じデバイスに配置されます。これは、BlueStore データベースが SSD に配置される devices ディレクティブの使用とは異なります。

        重要

        ceph-volume lvm batch mode コマンドは、従来のハードドライブおよび BlueStore データベースに SSD にデータを配置することで、OSD 最適化設定を作成します。使用する論理ボリュームとボリュームグループを指定する場合は、以下の 高度な設定 シナリオに従って、論理ボリュームとボリュームグループを直接作成できます。

      3. 高度な設定

        初回のシナリオ

        devices:
          - /dev/sda
          - /dev/sdb
        dedicated_devices:
          - /dev/sdx
          - /dev/sdy

        または

        2 つ目のシナリオ

        devices:
          - /dev/sda
          - /dev/sdb
        dedicated_devices:
          - /dev/sdx
          - /dev/sdy
        bluestore_wal_devices:
          - /dev/nvme0n1
          - /dev/nvme0n2

        最初のシナリオでは、OSD が 2 つあります。sda デバイスおよび sdb デバイスには、独自のデータセグメントと先行書き込みログがあります。追加のディクショナリー dedicated_devices を使用して、sdxsdy のデータベース (block.db とも呼ばれる) を分離します。

        2 つ目のシナリオでは、別のディクショナリー bluestore_wal_devices を使用して、NVMe デバイス nvme0n1 および nvme0n2 のログ先行書き込みを分離します。devices オプション、dedicated_devices オプション、bluestore_wal_devices, オプションを一緒に使用すると、OSD のすべてのコンポーネントを別々のデバイスに分離できます。このように OSD を配置すると、全体的なパフォーマンスが向上する場合があります。

      4. 事前作成された論理ボリューム

        初回のシナリオ

        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

        または

        2 つ目のシナリオ

        lvm_volumes:
          - data: /dev/sdb
            db:    db-lv1
            db_vg: db-vg1
            wal: wal-lv1
            wal_vg: wal-vg1

        デフォルトでは、Ceph は論理ボリュームマネージャーを使用して OSD デバイスに論理ボリュームを作成します。上記の 単純な設定 および 高度な設定 例では、Ceph はデバイス上に論理ボリュームを自動的に作成します。lvm_volumes ディクショナリーを指定すると、Ceph で以前に作成した論理ボリュームを使用できます。

        最初のシナリオでは、データは専用の論理ボリューム、データベース、および WAL に置かれます。データ、データおよび WAL、またはデータおよびデータベースのみを指定することもできます。data: 行は、データの保存先の論理ボリューム名を指定し、data_vg: データの論理ボリュームが含まれるボリュームグループの名前を指定する必要があります。同様に、db: は、データベースが保存されている論理ボリュームを指定するために使用されます。db_vg: は、論理ボリュームが存在するボリュームグループを指定するために使用されます。wal: 行は、WAL が格納する論理ボリュームを指定し、wal_vg: 行は、それを含むボリュームグループを指定します。

        2 つ目のシナリオでは、実際のデバイス名が data: オプションに設定されているため、data_vg: オプションを指定する必要はありません。BlueStore データベースおよび WAL デバイスに、論理ボリューム名とボリュームグループの詳細を指定する必要があります。

        重要

        lvm_volumes: では、ボリュームグループと論理ボリュームを、事前に作成する必要があります。ボリュームグループと論理ボリュームは、ceph-ansible では作成されません。

        注記

        すべての NVMe SSD を使用する場合は、osds_per_device: 2 を設定します。詳細は、『Red Hat Ceph Storage インストールガイド』「すべての NVMe ストレージに OSD Ansible 設定の構成」を参照してください。

        注記

        Ceph OSD ノードのリブート後には、ブロックデバイスの割り当てが変更される可能性があります。たとえば、sdc は、sdd になる場合があります。従来のブロックデバイス名ではなく、/dev/disk/by-path/ デバイスパスなどの永続的な命名デバイスを使用できます。

  6. すべてのデプロイメント (ベアメタル または コンテナー) について、Ansible インベントリーファイルを作成してから、そのファイルを開いて編集します。

    [root@admin ~]# cd /usr/share/ceph-ansible/
    [root@admin ceph-ansible]# touch hosts

    それに応じて hosts ファイルを編集します。

    注記

    Ansible インベントリーの場所の編集に関する詳細は、「Ansible インベントリーの場所の設定」を参照してください。

    1. [grafana-server] の下にノードを追加します。このロールは Grafana および Prometheus をインストールし、Ceph クラスターのパフォーマンスに関するリアルタイムの洞察を提供します。これらのメトリクスは Ceph Dashboard に提示されています。これにより、クラスターの監視および管理が可能になります。Dashboard、Grafana、および Prometheus のインストールが必要です。Ansible Administration ノードでメトリック関数を同じ場所に配置できます。これを実行する場合は、ノードのシステムリソースが スタンドアロンのメトリックノードに必要とされるもの よりも大きいことを確認します。

      [grafana-server]
      GRAFANA-SERVER_NODE_NAME
    2. [mons] セクションに monitor ノードを追加します。

      [mons]
      MONITOR_NODE_NAME_1
      MONITOR_NODE_NAME_2
      MONITOR_NODE_NAME_3
    3. [osds] セクションに OSD ノードを追加します。

      [osds]
      OSD_NODE_NAME_1
      OSD_NODE_NAME_2
      OSD_NODE_NAME_3
      注記

      ノード名が数値的に連続している場合は、ノード名の末尾に範囲指定子 ([1:10]) を追加できます。以下に例を示します。

      [osds]
      example-node[1:10]
      注記

      新規インストールの OSD の場合、デフォルトのオブジェクトストア形式は BlueStore です。

    4. 必要に応じて、コンテナー デプロイメントで、[mon] セクションおよび [osd] セクションに同じノードを追加して、Ceph Monitor デーモンを 1 つのノードの Ceph OSD デーモンと同じ場所に配置します。詳細は、Additional Resources セクションで、Ceph デーモンの配置に関するリンクを参照してください。
    5. [mgrs] セクションに Ceph Manager (ceph-mgr) ノードを追加します。これは、Ceph Manager デーモンと Ceph Monitor デーモンを共存させます。

      [mgrs]
      MONITOR_NODE_NAME_1
      MONITOR_NODE_NAME_2
      MONITOR_NODE_NAME_3
  7. 必要に応じて、すべてのデプロイメント (ベアメタル または コンテナー 内) ホスト固有のパラメーターを使用する場合は、ホストに固有のパラメーターが含まれるホストファイルで host_vars ディレクトリーを作成します。

    1. host_vars ディレクトリーを作成します。

      [ansible@admin ~]$ mkdir /usr/share/ceph-ansible/host_vars
    2. host_vars ディレクトリーに、ホストファイルを作成します。ファイル名に、host-name-short-name 形式を使用します。以下に例を示します。

      [ansible@admin ~]$ touch tower-osd6
    3. 以下のように、ホスト固有のパラメーターでファイルを更新します。

      1. bare-metal デプロイメントでは、devices パラメーターを使用して OSD ノードが使用するデバイスを指定します。OSD が異なる名前のデバイスを使用する場合や、いずれかの OSD でデバイスのいずれかに障害が発生した場合に devices の使用が役に立ちます。

        devices:
            DEVICE_1
            DEVICE_2
        devices:
            /dev/sdb
            /dev/sdc
        注記

        デバイスを指定しない場合は、osds.yml ファイルで osd_auto_discovery パラメーターを true に設定します。

      2. すべてのデプロイメント (ベアメタル または コンテナー 内) で、Ansible でカスタム CRUSH 階層を作成する場合は、特定のホストファイルで osd_crush_location パラメーターを使用して、CRUSH マップの階層に OSD ホストがある場所を指定します。OSD の場所を指定するために、2 つ以上の CRUSH バケットタイプを指定し、1 つのバケットの typehost に指定する必要があります。デフォルトでは、これには、rootdatacenterroomrowpodpdurackchassis および host が含まれます。

        osd_crush_location:
            root: ROOT_BUCKET
            rack: RACK_BUCKET
            pod: POD_BUCKET
            host: CEPH_NODE_NAME
        osd_crush_location:
            root: my-root
            rack: my-rack
            pod: my-pod
            host: tower-osd6
  8. すべてのデプロイメント (ベアメタル または コンテナー 内) では、ログインするか、ansible ユーザーに切り替えます。

    1. Ansible が ceph-ansible Playbook で生成される一時的な値を保存する ceph-ansible-keys ディレクトリーを作成します。

      [ansible@admin ~]$ mkdir ~/ceph-ansible-keys
    2. Ansible が Ceph ノードに到達できることを確認します。

      [ansible@admin ~]$ ansible all -m ping -i hosts
    3. /usr/share/ceph-ansible/ ディレクトリーに移動します。

      [ansible@admin ~]$ cd /usr/share/ceph-ansible/
  9. ceph-ansible Playbook を実行します。

    1. ベアメタル デプロイメント:

      [ansible@admin ceph-ansible]$ ansible-playbook site.yml -i hosts
    2. コンテナー デプロイメント:

      [ansible@admin ceph-ansible]$ ansible-playbook site-container.yml -i hosts
      注記

      Red Hat Ceph Storage を Red Hat Enterprise Linux Atomic Host ホストにデプロイする場合は、--skip-tags=with_pkg オプションを使用します。

      [user@admin ceph-ansible]$ ansible-playbook site-container.yml --skip-tags=with_pkg -i hosts
      注記

      デプロイメントの速度を増やすには、--forks オプションを ansible-playbook に指定します。デフォルトでは、ceph-ansible はフォークを 20 に設定します。この設定では、ノードを同時にインストールします。一度に最大 30 台までインストールするには、ansible-playbook --forks 30 PLAYBOOK FILE -i hosts を実行します。管理ノードのリソースが過剰に使用されていないことを確認するために、監視する必要があります。そうである場合は、--forks に渡される数を減らします。

  10. Ceph デプロイメントが完了するまで待ちます。
  11. Ceph Storage クラスターのステータスを確認します。

    1. ベアメタル デプロイメント:

      [root@mon ~]# ceph health
      HEALTH_OK
    2. コンテナー デプロイメント:

      Red Hat Enterprise Linux 7

      [root@mon ~]# docker exec ceph-mon-ID ceph health

      Red Hat Enterprise Linux 8

      [root@mon ~]# podman exec ceph-mon-ID ceph health

      置き換え
      • ID は、Ceph Monitor ノードのホスト名に置き換えます。

        [root@mon ~]# podman exec ceph-mon-mon0 ceph health
        HEALTH_OK

  12. ベアメタル または コンテナー 内のすべてのデプロイメントについて、ストレージクラスターが rados を使用して機能していることを確認します。

    1. Ceph Monitor ノードから、8 つの配置グループ (PG) でテストプールを作成します。

      構文

      [root@mon ~]# ceph osd pool create POOL_NAME PG_NUMBER

      [root@mon ~]# ceph osd pool create test 8

    2. hello-world.txt というファイルを作成します。

      構文

      [root@mon ~]# vim FILE_NAME

      [root@mon ~]# vim hello-world.txt

    3. オブジェクト名 hello-world を使用して、hello-world.txt をテストプールにアップロードします。

      構文

      [root@mon ~]# rados --pool POOL_NAME put OBJECT_NAME OBJECT_FILE_NAME

      [root@mon ~]# rados --pool test put hello-world hello-world.txt

    4. テストプールからファイル名 fetch.txt として hello-world をダウンロードします。

      構文

      [root@mon ~]# rados --pool POOL_NAME get OBJECT_NAME OBJECT_FILE_NAME

      [root@mon ~]# rados --pool test get hello-world fetch.txt

    5. fetch.txt の内容を確認してください。

      [root@mon ~]# cat fetch.txt
      "Hello World!"
      注記

      ストレージクラスターのステータスを確認する他に、ceph-medic ユーティリティーを使用して Ceph Storage クラスター全体の診断を行うことができます。Red Hat Ceph Storage 4 の『トラブルシューティングガイド』ceph-medic をインストールおよび使用して Ceph Storage クラスターの検証」の章を参照してください。

関連情報

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

全体的なパフォーマンスを向上させるには、Ansible がストレージ用に不揮発性メモリー表現 (NVMe) デバイスのみを使用するように設定することができます。通常、デバイスごとに 1 つの OSD のみが構成されているため、NVMe デバイスの潜在的なスループットが十分に活用されていません。

注記

SSD と HDD を混在する場合、SSD は OSD のデータに使用されず、データベース (block.db) に使用されます。

注記

テストでは、各 NVMe デバイスに 2 つの OSD を設定すると、最適なパフォーマンスが得られます。Red Hat は、osds_per_device オプションを 2 に設定することを推奨しますが、必須ではありません。その他の値により、お使いの環境でパフォーマンスが向上します。

前提条件

  • Ansible 管理ノードへのアクセス
  • ceph-ansible パッケージのインストール。

手順

  1. group_vars/osds.ymlosds_per_device: 2 を設定します。

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

    devices:
      - /dev/nvme0n1
      - /dev/nvme1n1
      - /dev/nvme2n1
      - /dev/nvme3n1
  3. group_vars/osds.yml の設定は以下のようになります。

    osds_per_device: 2
    devices:
      - /dev/nvme0n1
      - /dev/nvme1n1
      - /dev/nvme2n1
      - /dev/nvme3n1
注記

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

関連情報

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

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

前提条件

手順

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

  1. 新しいセクション [mdss]/etc/ansible/hosts ファイルに追加します。

    [mdss]
    NODE_NAME
    NODE_NAME
    NODE_NAME

    NODE_NAME は、Ceph メタデータサーバーをインストールするノードのホスト名に置き換えてください。

    [osds] セクションおよび [mdss] セクションに同じノードを追加して、1 つのノードにメタデータサーバーと OSD デーモンを同じ場所に置く事ができます。

  2. /usr/share/ceph-ansible ディレクトリーに移動します。

    [root@admin ~]# cd /usr/share/ceph-ansible
  3. 必要に応じて、デフォルトの変数を変更できます。

    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 を参照してください。
  4. ansible ユーザーとして、Ansible Playbook を実行します。

    • ベアメタル デプロイメント:

      [user@admin ceph-ansible]$ ansible-playbook site.yml --limit mdss -i hosts
    • コンテナー デプロイメント:

      [ansible@admin ceph-ansible]$ ansible-playbook site-container.yml --limit mdss -i hosts
  5. メタデータサーバーをインストールした後に、それらを設定できるようになりました。詳細は、『Ceph ファイルシステムガイド』の「メタデータサーバーデーモンの設定」の章を参照してください。

関連情報

4.5. Ceph クライアントロールのインストール

ceph-ansible ユーティリティーは、Ceph 設定ファイルと管理キーリングをノードにコピーする ceph-client ロールを提供します。さらに、このロールを使用してカスタムプールおよびクライアントを作成することができます。

前提条件

手順

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

  1. 新しいセクション [clients]/etc/ansible/hosts ファイルに追加します。

    [clients]
    CLIENT_NODE_NAME

    CLIENT_NODE_NAME は、ceph-client ロールをインストールするノードのホスト名に置き換えます。

  2. /usr/share/ceph-ansible ディレクトリーに移動します。

    [root@admin ~]# cd /usr/share/ceph-ansible
  3. clients.yml という名前の clients.yml.sample ファイルの新しいコピーを作成します。

    [root@admin ceph-ansible ~]# cp group_vars/clients.yml.sample group_vars/clients.yml
  4. 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-authtool --gen-print-key コマンドは、新しいクライアントキーを生成することができます。

  5. 必要に応じて、プールおよびクライアントを作成するように ceph-client に指示します。

    1. clients.yml を更新します。

      • user_config 設定のコメントを解除して、true に設定します。
      • pools セクションおよび keys セクションのコメントを解除し、必要に応じて更新します。cephx 機能を使用して、カスタムプールとクライアント名をまとめて定義できます。
    2. osd_pool_default_pg_num 設定を all.yml ファイルの ceph_conf_overrides セクションに追加します。

      ceph_conf_overrides:
         global:
            osd_pool_default_pg_num: NUMBER

      NUMBER は、デフォルトの配置グループ数に置き換えます。

  6. ansible ユーザーとして、Ansible Playbook を実行します。

    1. ベアメタル デプロイメント:

      [ansible@admin ceph-ansible]$ ansible-playbook site.yml --limit clients -i hosts
    2. コンテナー デプロイメント:

      [ansible@admin ceph-ansible]$ ansible-playbook site-container.yml --limit clients -i hosts

関連情報

4.6. Ceph Object Gateway のインストール

Ceph Object Gateway は、RADOS ゲートウェイとも呼ばれ、librados API 上に構築されたオブジェクトストレージインターフェースであり、アプリケーションに Ceph ストレージクラスターへの RESTful ゲートウェイを提供します。

前提条件

警告

マルチサイト設定で Ceph Object Gateway を使用する場合は、ステップ 1 から 7 のみを完了します。マルチサイトを設定する前に Ansible Playbook を実行しないでください。単一のサイト設定で Object Gateway が起動します。Ansible は、ゲートウェイがシングルサイト構成で開始した後に、マルチサイトセットアップにゲートウェイを再構成することはできません。ステップ 1 ~ 7 を完了したら、「マルチサイト Ceph Object Gateways の設定」セクションに進み、マルチサイトを設定します。

手順

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

  1. [rgws] セクションの下の /etc/ansible/hosts ファイルにゲートウェイホストを追加して、それらのロールを Ansible に識別します。ホストに連続する命名がある場合は、以下のように範囲を使用します。

    [rgws]
    <rgw_host_name_1>
    <rgw_host_name_2>
    <rgw_host_name[3..10]>
  2. Ansible 設定ディレクトリーに移動します。

    [root@ansible ~]# cd /usr/share/ceph-ansible
  3. サンプルファイルから rgws.yml ファイルを作成します。

    [root@ansible ~]# cp group_vars/rgws.yml.sample group_vars/rgws.yml
  4. group_vars/rgws.yml ファイルを開いて編集します。管理者キーを Ceph Object Gateway ノードにコピーするには、copy_admin_key オプションのコメントを解除します。

    copy_admin_key: true
  5. all.yml ファイルで、radosgw_interface を指定する 必要 があります。

    radosgw_interface: <interface>

    以下を置き換えます。

    • Ceph Object Gateway がリッスンするインターフェースを使用する <interface>

    以下に例を示します。

    radosgw_interface: eth0

    インターフェースを指定すると、同じホストで複数のインスタンスを実行している場合に、Civetweb が別の Civetweb インスタンスと同じ IP アドレスにバインドされないようにします。

    詳細は、all.yml ファイルを参照してください。

  6. 通常、デフォルト設定を変更するには、rgws.yml ファイルの設定をコメント解除し、それに応じて変更を加えます。rgws.yml ファイルに含まれていない設定に追加の変更を行うには、all.yml ファイルで ceph_conf_overrides: を使用します。

    ceph_conf_overrides:
        client.rgw.rgw1:
          rgw_override_bucket_index_max_shards: 16
          rgw_bucket_default_quota_max_objects: 1638400

    詳細な設定の詳細は、Red Hat Ceph Storage 4 の『実稼働環境への Ceph Object Gateway ガイド』を参照してください。高度なトピックには以下が含まれます。

  7. Ansible Playbook を実行します。

    警告

    マルチサイトを設定する場合には、Ansible Playbook を実行しないでください。「マルチサイト Ceph Object Gateways の設定」セクションに進み、マルチサイトを設定します。

    1. ベアメタル デプロイメント:

      [user@admin ceph-ansible]$ ansible-playbook site.yml --limit rgws -i hosts
    2. コンテナー デプロイメント:

      [user@admin ceph-ansible]$ ansible-playbook site-container.yml --limit rgws -i hosts
注記

Ansible は、各 Ceph Object Gateway が確実に実行されていることを確認します。

単一サイトの構成の場合は、Ceph ObjectGateway を Ansible 構成に追加します。

マルチサイトデプロイメントでは、各ゾーンの Ansible 設定を行う必要があります。つまり、Ansible によって、そのゾーン用に Ceph Storage クラスターおよびゲートウェイインスタンスが作成されます。

マルチサイトクラスターのインストールが完了したら、マルチサイト用のクラスターの設定方法は、Red Hat Ceph Storage 4 の『オブジェクトゲートウェイガイド』「マルチサイト」 の章に進んでください。

4.7. マルチサイト Ceph Object Gateway の設定

システム管理者は、障害復旧目的で、マルチサイト Ceph Object Gateways をクラスター間でデータのミラーリングを実行するように設定できます。

1 つ以上の RGW レルムを使用してマルチサイトを設定できます。レルムは、その内部の RGW を独立した状態にし、レルム外の RGW から分離できるようにします。これにより、あるレルムの RGW に書き込まれたデータは、別のレルムの RGW からはアクセスできません。

警告

既存の単一サイト Ceph Object Gateway を持つクラスター上で、Ansible を使用してマルチサイト Ceph Object Gateway を設定しないでください。Ansible は、ゲートウェイがシングルサイト構成で開始した後に、マルチサイトセットアップにゲートウェイを再構成することはできません。

注記

Red Hat Ceph Storage 4.1 から、group_vars/all.yml ファイルで rgw_multisite_endpoints_list の値を設定する必要はありません。

4.7.1. 前提条件

4.7.2. 1 つのレルムを使用したマルチサイト Ceph Object Gateway の設定

Ansible は、複数のクラスター間で 1 つのレルムのデータをミラーリングするように Ceph Object Gateways を設定します。

警告

既存の単一サイト Ceph Object Gateway を持つクラスター上で、Ansible を使用してマルチサイト Ceph Object Gateway を設定しないでください。Ansible は、ゲートウェイがシングルサイト構成で開始した後に、マルチサイトセットアップにゲートウェイを再構成することはできません。

前提条件

手順

  1. プライマリーストレージクラスターの Ansible ノードで以下の手順を実行します。

    1. システムキーを生成し、multi-site-keys.txt ファイルで出力を取得します。

      [root@ansible ~]# echo system_access_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1) > multi-site-keys.txt
      [root@ansible ~]# echo system_secret_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1) >> multi-site-keys.txt
    2. Ansible 設定ディレクトリー /usr/share/ceph-ansible に移動します。

      [root@ansible ~]# cd /usr/share/ceph-ansible
    3. group_vars/all.yml ファイルを開いて編集します。それぞれ、ZONE_NAMEZONE_GROUP_NAMEZONE_USER_NAMEZONE_DISPLAY_NAME、および REALM_NAME の更新と共に以下の設定を行います。ACCESS_KEY および SECRET_KEYmulti-site-keys.txt ファイルに保存されるランダムな文字列を使用します。

      構文

      rgw_multisite: true
      rgw_zone: ZONE_NAME
      rgw_zonegroup: ZONE_GROUP_NAME
      rgw_realm: REALM_NAME
      rgw_zonemaster: true
      rgw_zonesecondary: false
      rgw_zonegroupmaster: true
      rgw_zone_user: ZONE_USER_NAME
      rgw_zone_user_display_name: ZONE_DISPLAY_NAME
      system_access_key: ACCESS_KEY
      system_secret_key: SECRET_KEY
      rgw_multisite_proto: "http"

      rgw_multisite: true
      rgw_zone: juneau
      rgw_zonegroup: alaska
      rgw_realm: usa
      rgw_zonemaster: true
      rgw_zonesecondary: false
      rgw_zonegroupmaster: true
      rgw_zone_user: synchronization-user
      rgw_zone_user_display_name: "Synchronization User"
      rgw_multisite_proto: "http"
      system_access_key: 86nBoQOGpQgKxh4BLMyq
      system_secret_key: NTnkbmkMuzPjgwsBpJ6o

    4. Ansible Playbook を実行します。

      [ansible@ansible ceph-ansible]$ ansible-playbook site.yml
  2. セカンダリーストレージクラスターの Ansible ノードで以下の手順を実行します。

    1. Ansible 設定ディレクトリー /usr/share/ceph-ansible に移動します。

      [root@ansible ~]# cd /usr/share/ceph-ansible
    2. group_vars/all.yml ファイルを開いて編集します。以下の設定を構成します。ZONE_USER_NAMEZONE_DISPLAY_NAMEACCESS_KEYSECRET_KEYREALM_NAME、および ZONE_GROUP_NAME の最初のクラスターで使用するものと同じ値を指定します。最初のクラスターとは異なる値を ZONE_NAME に使用します。マスターゾーンの Ceph Object Gateway ノードに MASTER_RGW_NODE_NAME を設定します。最初のクラスターと比較すると、rgw_zonemaster および rgw_zonesecondary の設定が逆になることに注意してください。

      構文

      rgw_multisite: true
      rgw_zone: ZONE_NAME
      rgw_zonegroup: ZONE_GROUP_NAME
      rgw_realm: REALM_NAME
      rgw_zonemaster: false
      rgw_zonesecondary: true
      rgw_zonegroupmaster: true
      rgw_zone_user: ZONE_USER_NAME
      rgw_zone_user_display_name: ZONE_DISPLAY_NAME
      system_access_key: ACCESS_KEY
      system_secret_key: SECRET_KEY
      rgw_multisite_proto: "http"
      rgw_pull_proto: http
      rgw_pull_port: 8080
      rgw_pullhost: MASTER_RGW_NODE_NAME

      rgw_multisite: true
      rgw_zone: fairbanks
      rgw_zonegroup: alaska
      rgw_realm: usa
      rgw_zonemaster: false
      rgw_zonesecondary: true
      rgw_zonegroupmaster: true
      rgw_zone_user: synchronization-user
      rgw_zone_user_display_name: "Synchronization User"
      system_access_key: 86nBoQOGpQgKxh4BLMyq
      system_secret_key: NTnkbmkMuzPjgwsBpJ6o
      rgw_multisite_proto: "http"
      rgw_pull_proto: http
      rgw_pull_port: 8080
      rgw_pullhost: cluster0-rgw-000

  3. プライマリークラスターでの Ansible Playbook の実行

    1. ベアメタル デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site.yml -i hosts
    2. コンテナー デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site-container.yml -i hosts
  4. セカンダリークラスターがプライマリークラスターの API にアクセスできることを確認します。

    セカンダリークラスターの Object Gateway ノードから、curl または別の HTTP クライアントを使用して、プライマリークラスターの API に接続します。all.ymlrgw_pull_protorgw_pullhost、および rgw_pull_port の設定に使用する情報を使用して URL を作成します。上記の例では、URL は http://cluster0-rgw-000:8080です。API にアクセスできない場合は、URL が正しいことを確認し、必要な場合は all.yml を更新します。URL が有効になり、ネットワークの問題が解決したら、次の手順に進み、セカンダリークラスターで Ansible Playbook を実行します。

  5. セカンダリークラスターでの Ansible Playbook の実行

    1. ベアメタル デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site.yml -i hosts
    2. コンテナー デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site-container.yml -i hosts

      マスターストレージクラスターおよびセカンダリーストレージクラスターで Ansible Playbook を実行した後に、Ceph Object Gateway はアクティブ/アクティブ状態で実行されます。

  6. マルチサイト Ceph Object Gateway の設定を確認します。

    1. 各サイト (プライマリーおよびセカンダリー) の Ceph Monitor ノードおよび Object Gateway ノードから、curl または別の HTTP クライアントを使用して、API が他のサイトからアクセスできることを確認します。
    2. 両方のサイトで radosgw-admin sync status コマンドを実行します。

4.7.3. 複数のレルムを使用したマルチサイト Ceph Object Gateway の設定

Ansible は、複数のクラスター間で複数のレルムのデータをミラーリングするように Ceph Object Gateways を設定します。

警告

既存の単一サイト Ceph Object Gateway を持つクラスター上で、Ansible を使用してマルチサイト Ceph Object Gateway を設定しないでください。Ansible は、ゲートウェイがシングルサイト構成で開始した後に、マルチサイトセットアップにゲートウェイを再構成することはできません。

前提条件

手順

  1. いずれのノードでも、レルム 1 と 2 のシステムアクセスキーとシークレットキーを生成し、それぞれ multi-site-keys-realm-1.txt および multi-site-keys-realm-2.txt という名前のファイルに保存します。

    # echo system_access_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1) > multi-site-keys-realm-1.txt
    [root@ansible ~]# echo system_secret_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1) >> multi-site-keys-realm-1.txt
    
    # echo system_access_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1) > multi-site-keys-realm-2.txt
    [root@ansible ~]# echo system_secret_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1) >> multi-site-keys-realm-2.txt
  2. プライマリーストレージクラスターの Ansible ノードで以下の手順を実行します。

    1. Ansible 設定ディレクトリー /usr/share/ceph-ansible に移動します。

      [root@ansible ~]# cd /usr/share/ceph-ansible
    2. /usr/share/ceph-ansiblehost_vars ディレクトリーを作成します。

      [root@ansible ceph-ansible]# mkdir host_vars
    3. group_vars/all.yml ファイルを開いて編集します。rgw_multisite 行のコメントを解除して、true に設定します。

      rgw_multisite: true
    4. host_vars に、プライマリークラスターの最初の Object Gateway ノードのファイルを作成します。ファイル名は、Ansible インベントリーファイルで使用される名前と同じである必要があります。たとえば、最初の Object Gateway ノードの名前が rgw-001 の場合には、host_vars/rgw-001 ファイルを作成します。

      touch host_vars/NODE_NAME

      以下に例を示します。

      [root@ansible ceph-ansible]# touch host_vars/rgw-001
    5. ファイルを開いて編集します (例: host_vars/rgw-001 ファイル)。それぞれ、ZONE_NAME_1ZONE_GROUP_NAME_1ZONE_USER_NAME_1ZONE_DISPLAY_NAME_1、および REALM_NAME_1 の更新と共に以下の設定を行います。ACCESS_KEY_1 および SECRET_KEY_1multi-site-keys-realm-1.txt ファイルに保存されるランダムな文字列を使用します。

      構文

      rgw_zone: ZONE_NAME_1
      rgw_zonegroup: ZONE_GROUP_NAME_1
      rgw_realm: REALM_NAME_1
      rgw_zonemaster: true
      rgw_zonesecondary: false
      rgw_zonegroupmaster: true
      rgw_zone_user: ZONE_USER_NAME_1
      rgw_zone_user_display_name: "ZONE_DISPLAY_NAME_1"
      system_access_key: ACCESS_KEY_1
      system_secret_key: SECRET_KEY_1
      rgw_multisite_proto: "http"
      radosgw_address: "{{ _radosgw_address }}"
      radosgw_frontend_port: 8080

      rgw_zone: paris
      rgw_zonegroup: idf
      rgw_realm: france
      rgw_zonemaster: true
      rgw_zonesecondary: false
      rgw_zonegroupmaster: true
      rgw_zone_user: jacques.chirac
      rgw_zone_user_display_name: "Jacques Chirac"
      system_access_key: P9Eb6S8XNyo4dtZZUUMy
      system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfB
      rgw_multisite_proto: "http"
      radosgw_address: "{{ _radosgw_address }}"
      radosgw_frontend_port: 8080

    6. host_vars で、2 番目の Object Gateway ノードにファイルを作成します。このファイルは、Ansible インベントリーファイルで使用される名前と同じである必要があります。たとえば、最初の Object Gateway ノードの名前が rgw-002 の場合には、host_vars/rgw-002 ファイルを作成します。

      touch host_vars/NODE_NAME

      以下に例を示します。

      [root@ansible ceph-ansible]# touch host_vars/rgw-002
    7. ファイルを開いて編集します (例: host_vars/rgw-002 ファイル)。それぞれ、ZONE_NAME_2ZONE_GROUP_NAME_2ZONE_USER_NAME_2ZONE_DISPLAY_NAME_2、および REALM_NAME_2 の更新と共に以下の設定を行います。ACCESS_KEY_2 および SECRET_KEY_2multi-site-keys-realm-2.txt ファイルに保存されるランダムな文字列を使用します。

      構文

      rgw_zone: ZONE_NAME_2
      rgw_zonegroup: ZONE_GROUP_NAME_2
      rgw_realm: REALM_NAME_2
      rgw_zonemaster: true
      rgw_zonesecondary: false
      rgw_zonegroupmaster: true
      rgw_zone_user: ZONE_USER_NAME_2
      rgw_zone_user_display_name: ZONE_DISPLAY_NAME_2
      system_access_key: ACCESS_KEY_2
      system_secret_key: SECRET_KEY_2
      rgw_multisite_proto: "http"
      radosgw_address: "{{ _radosgw_address }}"
      radosgw_frontend_port: 8080

      rgw_zone: juneau
      rgw_zonegroup: alaska
      rgw_realm: usa
      rgw_zonemaster: true
      rgw_zonesecondary: false
      rgw_zonegroupmaster: true
      rgw_zone_user: edward.lewis
      rgw_zone_user_display_name: "Edward Lewis"
      system_access_key: yu17wkvAx3B8Wyn08XoF
      system_secret_key: 5YZfaSUPqxSNIkZQQA3lBZ495hnIV6k2HAz710BY=
      rgw_multisite_proto: "http"
      radosgw_address: "{{ _radosgw_address }}"
      radosgw_frontend_port: 8080

  3. プライマリークラスターで Ansible Playbook を実行します。

    1. ベアメタル デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site.yml -i hosts
    2. コンテナー デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site-container.yml -i hosts
  4. セカンダリーストレージクラスターの Ansible ノードで以下の手順を実行します。

    1. Ansible 設定ディレクトリー /usr/share/ceph-ansible に移動します。

      [root@ansible ~]# cd /usr/share/ceph-ansible
    2. /usr/share/ceph-ansiblehost_vars ディレクトリーを作成します。

      [root@ansible ceph-ansible]# mkdir host_vars
    3. group_vars/all.yml ファイルを開いて編集します。rgw_multisite 行のコメントを解除して、true に設定します。

      rgw_multisite: true
    4. セカンダリークラスターの最初の Object Gateway ノードに host_vars ファイルを作成します。ファイル名は、Ansible インベントリーファイルで使用される名前と同じである必要があります。たとえば、セカンダリークラスターの最初の Object Gateway ノードの名前が rgw-003 の場合は、host_vars/rgw-003 ファイルを作成します。

      touch host_vars/NODE_NAME

      以下に例を示します。

      [root@ansible ceph-ansible]# touch host_vars/rgw-003
    5. ファイルを開いて編集します (例: host_vars/rgw-003 ファイル)。それぞれ、ZONE_NAME_1ZONE_GROUP_NAME_1ZONE_USER_NAME_1ZONE_DISPLAY_NAME_1、および REALM_NAME_1 の更新と共に以下の設定を行います。PULLHOST_1 変数は、プライマリークラスターの最初の Object Gateway ノードのホスト名に設定する必要があります。ACCESS_KEY_1 および SECRET_KEY_1multi-site-keys-realm-1.txt ファイルに保存されるランダムな文字列を使用します。最初のクラスターと比較すると、rgw_zonemaster および rgw_zonesecondary の設定が逆になることに注意してください。

      構文

      rgw_zone: ZONE_NAME_1
      rgw_zonegroup: ZONE_GROUP_NAME_1
      rgw_realm: REALM_NAME_1
      rgw_zonemaster: false
      rgw_zonesecondary: true
      rgw_zonegroupmaster: true
      rgw_zone_user: ZONE_USER_NAME_1
      rgw_zone_user_display_name: "ZONE_DISPLAY_NAME_1"
      system_access_key: ACCESS_KEY_1
      system_secret_key: SECRET_KEY_1
      rgw_multisite_proto: "http"
      radosgw_address: "{{ _radosgw_address }}"
      radosgw_frontend_port: 8080
      rgw_pull_proto: http
      rgw_pull_port: 8080
      rgw_pullhost: PULLHOST_1

      rgw_zone: paris
      rgw_zonegroup: idf
      rgw_realm: france
      rgw_zonemaster: true
      rgw_zonesecondary: false
      rgw_zonegroupmaster: true
      rgw_zone_user: jacques.chirac
      rgw_zone_user_display_name: "Jacques Chirac"
      system_access_key: P9Eb6S8XNyo4dtZZUUMy
      system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfB
      rgw_multisite_proto: "http"
      radosgw_address: "{{ _radosgw_address }}"
      radosgw_frontend_port: 8080
      rgw_pull_proto: http
      rgw_pull_port: 8080
      rgw_pullhost: rgw-001

    6. host_vars で、2 番目の Object Gateway ノードにファイルを作成します。このファイルは、Ansible インベントリーファイルで使用される名前と同じである必要があります。たとえば、セカンダリークラスターの 2 番目の Object Gateway ノードの名前が rgw-004 の場合は、host_vars/rgw-004 ファイルを作成します。

      touch host_vars/NODE_NAME

      以下に例を示します。

      [root@ansible ceph-ansible]# touch host_vars/rgw-004
    7. ファイルを開いて編集します (例: host_vars/rgw-004 ファイル)。それぞれ、ZONE_NAME_2ZONE_GROUP_NAME_2ZONE_USER_NAME_2ZONE_DISPLAY_NAME_2、および REALM_NAME_2 の更新と共に以下の設定を行います。PULLHOST_2 変数は、プライマリークラスターの 2 番目の Object Gateway ノードのホスト名に設定する必要があります。ACCESS_KEY_2 および SECRET_KEY_2multi-site-keys-realm-2.txt ファイルに保存されるランダムな文字列を使用します。最初のクラスターと比較すると、rgw_zonemaster および rgw_zonesecondary の設定が逆になることに注意してください。

      構文

      rgw_zone: ZONE_NAME_2
      rgw_zonegroup: ZONE_GROUP_NAME_2
      rgw_realm: REALM_NAME_2
      rgw_zonemaster: false
      rgw_zonesecondary: true
      rgw_zonegroupmaster: true
      rgw_zone_user: ZONE_USER_NAME_2
      rgw_zone_user_display_name: ZONE_DISPLAY_NAME_2
      system_access_key: ACCESS_KEY_2
      system_secret_key: SECRET_KEY_2
      rgw_multisite_proto: "http"
      radosgw_address: "{{ _radosgw_address }}"
      radosgw_frontend_port: 8080
      rgw_pullhost: PULLHOST_2

      rgw_zone: juneau
      rgw_zonegroup: alaska
      rgw_realm: usa
      rgw_zonemaster: false
      rgw_zonesecondary: true
      rgw_zonegroupmaster: true
      rgw_zone_user: edward.lewis
      rgw_zone_user_display_name: "Edward Lewis"
      system_access_key: yu17wkvAx3B8Wyn08XoF
      system_secret_key: 5YZfaSUPqxSNIkZQQA3lBZ495hnIV6k2HAz710BY=
      rgw_multisite_proto: "http"
      radosgw_address: "{{ _radosgw_address }}"
      radosgw_frontend_port: 8080
      rgw_pull_port: 8080
      rgw_pullhost: rgw-002

  5. セカンダリークラスターで Ansible Playbook を実行します。

    1. ベアメタル デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site.yml -i hosts
    2. コンテナー デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site-container.yml -i hosts

      プライマリーストレージクラスターおよびセカンダリーストレージクラスターで Ansible Playbook を実行した後に、Ceph Object Gateway はアクティブ/アクティブ状態で実行されます。

  6. マルチサイト Ceph Object Gateway の設定を確認します。

    1. 各サイト (プライマリーおよびセカンダリー) の Ceph Monitor ノードおよび Object Gateway ノードから、curl または別の HTTP クライアントを使用して、API が他のサイトからアクセスできることを確認します。
    2. 両方のサイトで radosgw-admin sync status コマンドを実行します。

4.7.4. 複数のレルムと複数の RGW インスタンスを使用したマルチサイト CephObjectGateway の構成

Ansible は、複数の RGW インスタンスを持つ複数のクラスター全体の複数のレルムのデータをミラーリングするように Ceph Object Gateway を設定します。

警告

既存の単一サイト Ceph Object Gateway を持つクラスター上で、Ansible を使用してマルチサイト Ceph Object Gateway を設定しないでください。Ansible は、ゲートウェイがシングルサイト構成で開始した後に、マルチサイトセットアップにゲートウェイを再構成することはできません。

前提条件

手順

  1. いずれのノードでも、レルム 1 と 2 のシステムアクセスキーとシークレットキーを生成し、それぞれ multi-site-keys-realm-1.txt および multi-site-keys-realm-2.txt という名前のファイルに保存します。

    # echo system_access_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1) > multi-site-keys-realm-1.txt
    [root@ansible ~]# echo system_secret_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1) >> multi-site-keys-realm-1.txt
    
    # echo system_access_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1) > multi-site-keys-realm-2.txt
    [root@ansible ~]# echo system_secret_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1) >> multi-site-keys-realm-2.txt
  2. プライマリーストレージクラスターの Ansible ノードで以下の手順を実行します。

    1. Ansible 設定ディレクトリー /usr/share/ceph-ansible に移動します。

      [root@ansible ~]# cd /usr/share/ceph-ansible
    2. /usr/share/ceph-ansiblehost_vars ディレクトリーを作成します。

      [root@ansible ceph-ansible]# mkdir host_vars
    3. group_vars/all.yml ファイルを開いて編集します。rgw_multisite 行のコメントを解除して、true に設定します。

      rgw_multisite: true
    4. プライマリークラスター上の Object Gateway ノードの host_vars にファイルを作成します。ファイル名は、Ansible インベントリーファイルで使用される名前と同じである必要があります。たとえば、Object Gateway ノードの名前が rgw-primary の場合は、host_vars/rgw-primary ファイルを作成します。

      touch host_vars/NODE_NAME

      以下に例を示します。

      [root@ansible ceph-ansible]# touch host_vars/rgw-primary
    5. ファイルを開いて編集します (例: host_vars/rgw-primary ファイル)。プライマリークラスターのすべてのインスタンスに適用される設定を構成します。

      rgw_zonemaster: true
      rgw_zonesecondary: false
      rgw_zonegroupmaster: true
      rgw_multisite_proto: "http"
      rgw_instances:
    6. 最初のレルムの rgw_instances の下に項目を追加します。それぞれ、INSTANCE_NAME_1ZONE_NAME_1ZONE_GROUP_NAME_1ZONE_USER_NAME_1ZONE_DISPLAY_NAME_1、および REALM_NAME_1 の更新と共に以下の設定を行います。ACCESS_KEY_1 および SECRET_KEY_1multi-site-keys-realm-1.txt ファイルに保存されるランダムな文字列を使用します。

      構文

        - instance_name: INSTANCE_NAME_1
          rgw_zone: ZONE_NAME_1
          rgw_zonegroup: ZONE_GROUP_NAME_1
          rgw_realm: REALM_NAME_1
          rgw_zone_user: ZONE_USER_NAME_1
          rgw_zone_user_display_name: "ZONE_DISPLAY_NAME_1"
          system_access_key: ACCESS_KEY_1
          system_secret_key: SECRET_KEY_1
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8080

        - instance_name: rgw1
          rgw_zone: paris
          rgw_zonegroup: idf
          rgw_realm: france
          rgw_zone_user: jacques.chirac
          rgw_zone_user_display_name: "Jacques Chirac"
          system_access_key: P9Eb6S8XNyo4dtZZUUMy
          system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfB
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8080

    7. 2 つ目のレルムの rgw_instances の下に項目を追加します。それぞれ、INSTANCE_NAME_2、ZONE_NAME_2_、ZONE_GROUP_NAME_2ZONE_USER_NAME_2ZONE_DISPLAY_NAME_2、および REALM_NAME_2 の更新と共に以下の設定を行います。ACCESS_KEY_2 および SECRET_KEY_2multi-site-keys-realm-2.txt ファイルに保存されるランダムな文字列を使用します。

      構文

        - instance_name: INSTANCE_NAME_2
          rgw_zone: ZONE_NAME_2
          rgw_zonegroup: ZONE_GROUP_NAME_2
          rgw_realm: REALM_NAME_2
          rgw_zone_user: ZONE_USER_NAME_2
          rgw_zone_user_display_name: "ZONE_DISPLAY_NAME_2"
          system_access_key: ACCESS_KEY_2
          system_secret_key: SECRET_KEY_2
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8081

        - instance_name: rgw2
          rgw_zone: juneau
          rgw_zonegroup: alaska
          rgw_realm: usa
          rgw_zone_user: edward.lewis
          rgw_zone_user_display_name: "Edward Lewis"
          system_access_key: yu17wkvAx3B8Wyn08XoF
          system_secret_key: 5YZfaSUPqxSNIkZQQA3lBZ495hnIV6k2HAz710BY=
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8081

    8. プライマリーゲートウェイの完全な host_vars ファイルは次の例のようになっているのを確認します。

      rgw_zonemaster: true
      rgw_zonesecondary: false
      rgw_zonegroupmaster: true
      rgw_multisite_proto: "http"
      rgw_instances:
        - instance_name: rgw1
          rgw_zone: paris
          rgw_zonegroup: idf
          rgw_realm: france
          rgw_zone_user: jacques.chirac
          rgw_zone_user_display_name: "Jacques Chirac"
          system_access_key: P9Eb6S8XNyo4dtZZUUMy
          system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfB
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8080
        - instance_name: rgw2
          rgw_zone: juneau
          rgw_zonegroup: alaska
          rgw_realm: usa
          rgw_zone_user: edward.lewis
          rgw_zone_user_display_name: "Edward Lewis"
          system_access_key: yu17wkvAx3B8Wyn08XoF
          system_secret_key: 5YZfaSUPqxSNIkZQQA3lBZ495hnIV6k2HAz710BY=
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8081
  3. プライマリークラスターで Ansible Playbook を実行します。

    1. ベアメタル デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site.yml -i hosts
    2. コンテナー デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site-container.yml -i hosts
  4. セカンダリーストレージクラスターの Ansible ノードで以下の手順を実行します。

    1. Ansible 設定ディレクトリー /usr/share/ceph-ansible に移動します。

      [root@ansible ~]# cd /usr/share/ceph-ansible
    2. /usr/share/ceph-ansiblehost_vars ディレクトリーを作成します。

      [root@ansible ceph-ansible]# mkdir host_vars
    3. group_vars/all.yml ファイルを開いて編集します。rgw_multisite 行のコメントを解除して、true に設定します。

      rgw_multisite: true
    4. セカンダリークラスターの Object Gateway ノードにおいて、host_vars にファイルを作成します。ファイル名は、Ansible インベントリーファイルで使用される名前と同じである必要があります。たとえば、Object Gateway ノードの名前が rgw-secondary の場合は、host_vars/rgw-secondary ファイルを作成します。

      touch host_vars/NODE_NAME

      以下に例を示します。

      [root@ansible ceph-ansible]# touch host_vars/rgw-secondary
    5. ファイルを開いて編集します (例: host_vars/rgw-secondary ファイル)。セカンダリークラスターのすべてのインスタンスに適用される設定を構成します。

      rgw_zonemaster: false
      rgw_zonesecondary: true
      rgw_zonegroupmaster: true
      rgw_multisite_proto: "http"
      rgw_instances:
    6. 最初のレルムの rgw_instances の下に項目を追加します。それぞれ、INSTANCE_NAME_3ZONE_NAME_1ZONE_GROUP_NAME_1ZONE_USER_NAME_1ZONE_DISPLAY_NAME_1、および REALM_NAME_1 の更新と共に以下の設定を行います。ACCESS_KEY_1 および SECRET_KEY_1multi-site-keys-realm-1.txt ファイルに保存されるランダムな文字列を使用します。RGW_PRIMARY_HOSTNAME をプライマリークラスターの Object Gateway ノードに設定します。

      構文

        - instance_name: INSTANCE_NAME_3
          rgw_zone: ZONE_NAME_1
          rgw_zonegroup: ZONE_GROUP_NAME_1
          rgw_realm: REALM_NAME_1
          rgw_zone_user: ZONE_USER_NAME_1
          rgw_zone_user_display_name: "ZONE_DISPLAY_NAME_1"
          system_access_key: ACCESS_KEY_1
          system_secret_key: SECRET_KEY_1
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8080
          endpoint: http://RGW_PRIMARY_HOSTNAME:8080

        - instance_name: rgw3
          rgw_zone: paris
          rgw_zonegroup: idf
          rgw_realm: france
          rgw_zone_user: jacques.chirac
          rgw_zone_user_display_name: "Jacques Chirac"
          system_access_key: P9Eb6S8XNyo4dtZZUUMy
          system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfB
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8080
          endpoint: http://rgw-primary:8080

    7. 2 つ目のレルムの rgw_instances の下に項目を追加します。それぞれ、INSTANCE_NAME_4、ZONE_NAME_2_、ZONE_GROUP_NAME_2ZONE_USER_NAME_2ZONE_DISPLAY_NAME_2、および REALM_NAME_2 の更新と共に以下の設定を行います。ACCESS_KEY_2 および SECRET_KEY_2multi-site-keys-realm-2.txt ファイルに保存されるランダムな文字列を使用します。RGW_PRIMARY_HOSTNAME をプライマリークラスターの Object Gateway ノードに設定します。

      構文

        - instance_name: INSTANCE_NAME_4
          rgw_zone: ZONE_NAME_2
          rgw_zonegroup: ZONE_GROUP_NAME_2
          rgw_realm: REALM_NAME_2
          rgw_zone_user: ZONE_USER_NAME_2
          rgw_zone_user_display_name: "ZONE_DISPLAY_NAME_2"
          system_access_key: ACCESS_KEY_2
          system_secret_key: SECRET_KEY_2
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8081
          endpoint: http://RGW_PRIMARY_HOSTNAME:8081

        - instance_name: rgw4
          rgw_zone: juneau
          rgw_zonegroup: alaska
          rgw_realm: usa
          rgw_zone_user: edward.lewis
          rgw_zone_user_display_name: "Edward Lewis"
          system_access_key: yu17wkvAx3B8Wyn08XoF
          system_secret_key: 5YZfaSUPqxSNIkZQQA3lBZ495hnIV6k2HAz710BY=
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8081
          endpoint: http://rgw-primary:8081

    8. セカンダリーゲートウェイの完全な host_vars ファイルの例を確認します。

      rgw_zonemaster: true
      rgw_zonesecondary: false
      rgw_zonegroupmaster: true
      rgw_multisite_proto: "http"
      rgw_instances:
        - instance_name: rgw3
          rgw_zone: paris
          rgw_zonegroup: idf
          rgw_realm: france
          rgw_zone_user: jacques.chirac
          rgw_zone_user_display_name: "Jacques Chirac"
          system_access_key: P9Eb6S8XNyo4dtZZUUMy
          system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfB
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8080
          endpoint: http://rgw-primary:8080
        - instance_name: rgw4
          rgw_zone: juneau
          rgw_zonegroup: alaska
          rgw_realm: usa
          rgw_zone_user: edward.lewis
          rgw_zone_user_display_name: "Edward Lewis"
          system_access_key: yu17wkvAx3B8Wyn08XoF
          system_secret_key: 5YZfaSUPqxSNIkZQQA3lBZ495hnIV6k2HAz710BY=
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8081
          endpoint: http://rgw-primary:8081
  5. セカンダリークラスターで Ansible Playbook を実行します。

    1. ベアメタル デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site.yml -i hosts
    2. コンテナー デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site-container.yml -i hosts

      プライマリーストレージクラスターおよびセカンダリーストレージクラスターで Ansible Playbook を実行した後に、Ceph Object Gateway はアクティブ/アクティブ状態で実行されます。

  6. マルチサイト Ceph Object Gateway の設定を確認します。

    1. 各サイト (プライマリーおよびセカンダリー) の Ceph Monitor ノードおよび Object Gateway ノードから、curl または別の HTTP クライアントを使用して、API が他のサイトからアクセスできることを確認します。
    2. 両方のサイトで radosgw-admin sync status コマンドを実行します。

4.8. 同じホストに異なるハードウェアを持つ OSD のデプロイメント

Ansible の device_class 機能を使用して、同じホストに HDD や SSD などの複数の OSD をデプロイすることができます。

前提条件

  • 有効なカスタマーサブスクリプションです。
  • Ansible 管理ノードへのルートレベルのアクセス。
  • Red Hat Ceph Storage Tools および Ansible リポジトリーを有効にします。
  • Ansible アプリケーションで使用する Ansible ユーザーアカウント。
  • OSD がデプロイされている。

手順

  1. group_vars/mons.yml ファイルに crush_rules を作成します。

    crush_rule_config: true
    crush_rule_hdd:
        name: HDD
        root: default
        type: host
        class: hdd
        default: true
    crush_rule_ssd:
        name: SSD
        root: default
        type: host
        class: ssd
        default: true
    crush_rules:
          - "{{ crush_rule_hdd }}"
          - "{{ crush_rule_ssd }}"
    create_crush_tree: true
    注記

    クラスターで SSD デバイスまたは HDD デバイスを使用していない場合は、そのデバイスの crush_rules を定義しないでください。

  2. 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 }}"
  3. ルートを OSD に割り当てるためのインベントリーファイルをサンプリングします。

    [mons]
    mon1
    
    [osds]
    osd1 osd_crush_location="{ 'root': 'default', 'rack': 'rack1', 'host': 'osd1' }"
    osd2 osd_crush_location="{ 'root': 'default', 'rack': 'rack1', 'host': 'osd2' }"
    osd3 osd_crush_location="{ 'root': 'default', 'rack': 'rack2', 'host': 'osd3' }"
    osd4 osd_crush_location="{ 'root': 'default', 'rack': 'rack2', 'host': 'osd4' }"
    osd5 devices="['/dev/sda', '/dev/sdb']" osd_crush_location="{ 'root': 'default', 'rack': 'rack3', 'host': 'osd5' }"
    osd6 devices="['/dev/sda', '/dev/sdb']" osd_crush_location="{ 'root': 'default', 'rack': 'rack3', 'host': 'osd6' }"
    
    [mgrs]
    mgr1
    
    [clients]
    client1
  4. ツリーを表示します。

    構文

    [root@mon ~]# ceph osd tree

    TYPE NAME
    
    root default
         rack rack1
            host osd1
                 osd.0
                 osd.10
            host osd2
                 osd.3
                 osd.7
                 osd.12
         rack rack2
            host osd3
                 osd.1
                 osd.6
                 osd.11
            host osd4
                 osd.4
                 osd.9
                 osd.13
         rack rack3
             host osd5
                 osd.2
                 osd.8
             host osd6
                 osd.14
                 osd.15

  5. プールを検証します。

    # for i in $(rados lspools);do echo "pool: $i"; ceph osd pool get $i crush_rule;done
    
    pool: pool1
    crush_rule: HDD

関連情報

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

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

前提条件

  • 稼働中の Ceph ストレージクラスター (active + clean の状態が望ましい)。
  • Ceph Object Gateway を実行するノードを少なくとも 1 つ。
  • NFS-Ganesha を実行する前に、NFS-Ganesha を実行するホストで実行中のカーネル NFS サービスインスタンスをすべて無効にします。NFS-Ganesha は、別の NFS インスタンスが実行している場合は起動しません。

*パスワードなしの SSH アクセスの有効化

  • rpcbind サービスが実行していることを確認します。

    # systemctl start rpcbind
    注記

    rpcbind を提供する rpcbind パッケージは通常、デフォルトでインストールされます。そうでない場合は、最初にパッケージをインストールします。

  • nfs-service サービスが実行中である場合は、これを停止して無効にします。

    # systemctl stop nfs-server.service
    # systemctl disable nfs-server.service

手順

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

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

    [root@ansible ~]# cd /usr/share/ceph-ansible/group_vars
    [root@ansible ~]# cp nfss.yml.sample nfss.yml
  2. [nfss] グループの下にゲートウェイホストを /etc/ansible/hosts ファイルに追加して、Ansible へのグループメンバーシップを特定します。

    [nfss]
    NFS_HOST_NAME_1
    NFS_HOST_NAME_2
    NFS_HOST_NAME[3..10]

    ホストに連続する命名がある場合は、[3..10] のように範囲指定子を使用できます。

  3. Ansible 設定ディレクトリーに移動します。

    [root@ansible ~]# cd /usr/share/ceph-ansible
  4. 管理者キーを Ceph Object Gateway ノードにコピーするには、/usr/share/ceph-ansible/group_vars/nfss.yml ファイルの copy_admin_key 設定をコメント解除します。

    copy_admin_key: true
  5. /usr/share/ceph-ansible/group_vars/nfss.yml ファイルの FSAL (File System Abstraction Layer) セクションを設定します。エクスポート ID (NUMERIC_EXPORT_ID)、S3 ユーザー ID (S3_USER)、S3 アクセスキー (ACCESS_KEY)、およびシークレットキー (SECRET_KEY) を提供します。

    # FSAL RGW Config #
    
    ceph_nfs_rgw_export_id: NUMERIC_EXPORT_ID
    #ceph_nfs_rgw_pseudo_path: "/"
    #ceph_nfs_rgw_protocols: "3,4"
    #ceph_nfs_rgw_access_type: "RW"
    ceph_nfs_rgw_user: "S3_USER"
    ceph_nfs_rgw_access_key: "ACCESS_KEY"
    ceph_nfs_rgw_secret_key: "SECRET_KEY"
    警告

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

  6. Ansible Playbook を実行します。

    1. ベアメタル デプロイメント:

      [ansible@admin ceph-ansible]$ ansible-playbook site.yml --limit nfss -i hosts
    2. コンテナー デプロイメント:

      [ansible@admin ceph-ansible]$ ansible-playbook site-container.yml --limit nfss -i hosts

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

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

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

ansible-playbook site.yml|site-container.yml --limit osds|rgws|clients|mdss|nfss|iscsigws -i hosts

ベアメタル

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

[ansible@ansible ceph-ansible]$ ansible-playbook site.yml --limit osds -i hosts

コンテナー

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

[ansible@ansible ceph-ansible]$ ansible-playbook site-container.yml --limit osds -i hosts
重要

1 つのノードに Ceph コンポーネントを同じ場所に配置すると、limit オプションで指定されたコンポーネントタイプが 1 つだけであるにもかかわらず、Ansible はノード上の すべてのコンポーネント に Playbook を適用します。たとえば、インベントリーファイルの OSD およびメタデータサーバー (MDS) グループに一覧表示されているノードで --limit osds オプションを指定して Playbook site を実行すると、Ansible はノード上でコンポーネント、OSD、および MDS の両方のタスクを実行します。

4.11. 配置グループ autoscaler

配置グループ (PG) チューニングでは、PG の計算ツールを使用して、pg_num の数字のプラグを手動で処理します。Red Hat Ceph Storage 4.1 以降では、Ceph Manager モジュール pg_autoscaler を有効にすると、PG のチューニングを自動的に実行できます。PG autoscaler はプールごとに設定され、pg_num を 2 の累乗でスケーリングします。PG Autoscaler は、推奨される値が実際の値が 3 倍を超える場合に、pg_num への変更のみを提案します。

PG autoscaler には 3 つのモードがあります。

warn
新しいプールおよび既存のプールのデフォルトモード。推奨される pg_num の値が現在の pg_num 値と大きく異なる場合に、ヘルス警告が生成されます。
on
プールの pg_num は、自動的に調整されます。
off
プールでは Autoscaler をオフにすることができますが、ストレージ管理者はプールの pg_num 値を手動で設定する必要があります。

プールに対して PG autoscaler が有効になったら、ceph osd pool autoscale-status コマンドを実行して値の調整を表示できます。この autoscale-status コマンドは、プールの現在の状態を示します。autoscale-status 列の説明は次のとおりです。

SIZE
プールに保存されているデータの合計量をバイト単位で報告します。このサイズには、オブジェクトデータと OMAP データが含まれます。
TARGET SIZE
ストレージ管理者が提供するプールの予想されるサイズを報告します。この値は、プールの理想的な PG 数を計算するために使用されます。
RATE
レプリケートされたバケットのレプリケーション係数、またはイレイジャーコーディングされたプールの比率。
RAW CAPACITY
プールが CRUSH に基づいてマップされるストレージデバイスの raw ストレージ容量。
RATIO
プールによって消費されるストレージの合計比率。
TARGET RATIO
ストレージ管理者によって提供された、ストレージクラスター全体のスペースのどの部分がプールによって消費されるかを指定する比率。
PG_NUM
プールの現在の配置グループ数。
NEW PG_NUM
提案される値。この値は設定できません。
AUTOSCALE
プールに設定された PG Autoscaler モード。

4.11.1. 配置グループ autoscaler の設定

Ceph Ansible を設定して、Red Hat Ceph Storage クラスターの新規プールの PG Autoscaler を有効および設定することができます。デフォルトでは、配置グループ (PG) はオフになっています。

重要

現在、新しい Red Hat Ceph Storage デプロイメントでのみ配置グループ Autoscaler を設定でき、既存の Red Hat Ceph Storage インストールには設定できません。

前提条件

  • Ansible 管理ノードへのアクセス
  • Ceph Monitor ノードへのアクセス

手順

  1. Ansible 管理ノードで、編集のために group_vars/all.yml ファイルを開きます。
  2. pg_autoscale_mode オプションを True に設定し、新規または既存のプールの target_size_ratio の値を設定します。

    openstack_pools:
        - {"name": backups, "target_size_ratio": 0.1, "pg_autoscale_mode": True, "application": rbd}
        - {"name": volumes, "target_size_ratio": 0.5, "pg_autoscale_mode": True, "application": rbd}
        - {"name": vms,     "target_size_ratio": 0.2, "pg_autoscale_mode": True, "application": rbd}
        - {"name": images,  "target_size_ratio": 0.2, "pg_autoscale_mode": True, "application": rbd}

    注記

    target_size_ratio 値は、ストレージクラスター内の他のプールとの対比で、重みの値になります。

  3. group_vars/all.yml ファイルへの変更を保存します。
  4. 適切な Ansible Playbook を実行します。

    ベアメタル デプロイメント

    [ansible@admin ceph-ansible]$ ansible-playbook site.yml -i hosts

    コンテナー デプロイメント

    [ansible@admin ceph-ansible]$ ansible-playbook site-container.yml -i hosts

  5. Ansible Playbook が完了したら、Ceph Monitor ノードから Autoscaler のステータスを確認します。

    [user@mon ~]$ ceph osd pool autoscale-status

4.12. 関連情報

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

本セクションでは、以下を説明します。

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

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

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

コロケーションの仕組み

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

  • Ceph メタデータサーバー (ceph-mds)
  • Ceph Monitor (ceph-mon) および Ceph Manager (ceph-mgr) デーモン
  • NFS Ganesha (nfs-ganesha)
  • RBD ミラー (rbd-mirror)

さらに、Ceph Object Gateway (radosgw) または Grafana の場合は、OSD デーモンと上記のリストのデーモン (RBD ミラーを除く) のいずれかと同じ場所に配置できます。たとえば、以下は、有効な 5 ノードの同じ場所に配置された構成です。

ノードデーモンデーモンデーモン

node1

OSD

Monitor

Grafana

node2

OSD

Monitor

RADOS Gateway

node3

OSD

Monitor

RADOS Gateway

node4

OSD

メタデータサーバー

 

node5

OSD

メタデータサーバー

 

上記の設定のように 5 つのノードクラスターをデプロイするには、以下のように Ansible インベントリーファイルを設定します。

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

[grafana-server]
node1

[mons]
node[1:3]

[mgrs]
node[1:3]

[osds]
node[1:5]

[rgws]
node[2:3]

[mdss]
node[4:5]

注記

ceph-monceph-mgr は密接に連携するため、コロケーションのために、2 つの別のデーモンとしてカウントしません。

注記

Grafana の OSD および別のデーモンのコロケーションは、Red Hat Ceph Storage 4.1 以降でのみサポートされます。

注記

Red Hat は、Ceph Object Gateway を OSD コンテナーと併置してパフォーマンスを向上することを推奨します。追加コストを発生せずに最高のパフォーマンスを実現するには、group_vars/all.ymlradosgw_num_instances: 2 に設定して、2 つのゲートウェイを使用します。詳細は、「Red Hat Ceph Storage RGW deployment strategies and sizing guidance」を参照してください。

注記

Grafana を他の 2 つのコンテナーと同じ場所に配置するには、適切な CPU とネットワークリソースが必要です。リソースの枯渇が発生した場合は、Grafana と Monitor のみを同じ場所に配置し、それでもリソースの枯渇が発生した場合は、専用ノードで Grafana を実行します。

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

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

コンテナーの同じ場所に配置されたデーモンがカーディナリティー 2 を更新

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

コンテナーの同じ場所に配置されていないデーモンが更新

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

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

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

手順

  1. デーモンのデフォルト 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
  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) 設定では、osds.yml 設定ファイルの ceph_osd_docker_memory_limit パラメーターを使用して Docker メモリー CGroup 制限を変更することもできます。この場合、ceph_osd_docker_memory_limitosd_memory_target よりも 50% 高く設定し、CGroup の制限は、HCI 設定の場合のデフォルトよりも制限が高くなります。たとえば、osd_memory_target が 6 GB に設定されている場合は、ceph_osd_docker_memory_limit を 9 GB に設定します。

    ceph_osd_docker_memory_limit: 9g

関連情報

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

5.3. 関連情報

第6章 Red Hat Ceph Storage クラスターのアップグレード

ストレージ管理者は、Red Hat Ceph Storage クラスターを新しいメジャーバージョンまたは新しいマイナーバージョンにアップグレードしたり、現行バージョンに非同期更新を適用するだけで済みます。Ansible Playbook rolling_update.yml は、Red Hat Ceph Storage のベアメタルまたはコンテナー化されたデプロイメントのアップグレードを実行します。Ansible は Ceph ノードを以下の順序でアップグレードします。

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

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

重要

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

重要

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

重要

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

警告

マルチサイト設定を RedHat Ceph Storage 3 から RedHat Ceph Storage 4 にアップグレードする場合は、以下の推奨事項に注意してください。そうしないと、レプリケーションが破損する可能性があります。rolling_update.yml を実行する前に、all.ymlrgw_multisite: false を設定します。バージョン 3.3z5 以降の Red Hat Ceph Storage 3 クラスターのみを Red Hat Ceph Storage 4 にアップグレードします。3.3z5 以降に更新できない場合は、クラスターをアップグレードする前にサイト間の同期を無効にします。同期を無効にするには、rgw_run_sync_thread = false を設定して、RADOS Gateway デーモンを再起動します。最初にプライマリークラスターをアップグレードします。Red Hat Ceph Storage 4.1 以降にアップグレードします。3.3z5 に関連するパッケージバージョンを確認するには、「What are the Red Hat Ceph Storage releases and corresponding Ceph package versions?」を参照してください。

警告

Ceph Object Gateway を使用して Red Hat Ceph Storage 3.x から Red Hat Ceph Storage 4.x にアップグレードする場合、フロントエンドは自動的に CivetWeb から Beast (新しいデフォルト) に変更されます。詳細は、『オブジェクトのゲートウェイ設定および管理ガイド』「設定」を参照してください。

6.1. サポート対象の Red Hat Ceph Storage アップグレードシナリオ

Red Hat は、以下のアップグレードシナリオをサポートします。ベアメタルコンテナー化されたオペレーティングシステム (OS) アップグレードを使用したベアメタル の表を読み、特定のアップグレード後の状態に移行するためにクラスターがログインする必要のある状態を確認します。

ceph-ansible を使用して、ベアメタルまたはホストの OS がメジャーバージョンを変更しないベアメタルおよびコンテナー化されたアップグレードを実行します。Red Hat Ceph Storage (RHCS) の一部としてベアメタル OS を Red Hat Enterprise Linux 7.8 から Red Hat Enterprise Linux 8.2 に変更するには、「Red Hat Ceph Storage クラスターおよびオペレーティングシステムを手動でアップグレード」の章を参照してください。

表6.1 ベアメタル

アップグレード前の状態

アップグレード後の状態

サポート対象

OS バージョン

RHCS バージョン

OS バージョン

RHCS バージョン

Red Hat Enterprise Linux 7.7

Red Hat Ceph Storage 4.0

Red Hat Enterprise Linux 7.8

Red Hat Ceph Storage 4.1

はい

Red Hat Enterprise Linux 7.7

Red Hat Ceph Storage 3.3z4

Red Hat Enterprise Linux 7.8

Red Hat Ceph Storage 4.1

はい

Red Hat Enterprise Linux 8.1

Red Hat Ceph Storage 4.0

Red Hat Enterprise Linux 8.2

Red Hat Ceph Storage 4.1

はい

Red Hat Enterprise Linux 8.2

Red Hat Ceph Storage 4.0

Red Hat Enterprise Linux 8.2

Red Hat Ceph Storage 4.1

はい

表6.2 コンテナー化

アップグレード前の状態

アップグレード後の状態

サポート対象

ホストの OS バージョン

コンテナー OS バージョン

RHCS バージョン

ホストの OS バージョン

コンテナー OS バージョン

RHCS バージョン

Red Hat Enterprise Linux 7.7

Red Hat Enterprise Linux 7.7

Red Hat Ceph Storage 3.3z4

Red Hat Enterprise Linux 7.8

Red Hat Enterprise Linux 8.2

Red Hat Ceph Storage 4.1

はい

Red Hat Enterprise Linux 7.8

Red Hat Enterprise Linux 8.1

Red Hat Ceph Storage 4.0

Red Hat Enterprise Linux 7.8

Red Hat Enterprise Linux 8.2

Red Hat Ceph Storage 4.1

はい

Red Hat Enterprise Linux 8.1

Red Hat Enterprise Linux 8.1

Red Hat Ceph Storage 4.0

Red Hat Enterprise Linux 8.2

Red Hat Enterprise Linux 8.2

Red Hat Ceph Storage 4.1

はい

表6.3 OS アップグレードを使用したベアメタル

アップグレード前の状態

アップグレード後の状態

サポート対象

OS バージョン

RHCS バージョン

OS バージョン

RHCS バージョン

Red Hat Enterprise Linux 7.8

Red Hat Ceph Storage 4.0

Red Hat Enterprise Linux 8.2

Red Hat Ceph Storage 4.1

はい*

Red Hat Enterprise Linux 7.8

Red Hat Ceph Storage 3.3z4

Red Hat Enterprise Linux 8.2

Red Hat Ceph Storage 4.1

はい*

* Red Hat Enterprise Linux 7 から RedHat Enterprise Linux 8 へのアップグレードは、ceph-ansible ではサポートされていません。「Red Hat Ceph Storage クラスターおよびオペレーティングシステムの手動アップグレード」の手順でサポートされています。

6.2. アップグレードの準備

Red Hat Ceph Storage クラスターのアップグレードを開始する前に、いくつかの操作を完了する必要があります。これらのステップは、Red Hat Ceph Storage クラスターのベアメタルおよびコンテナーデプロイメントの両方に適用されます (指定がある場合)。

前提条件

重要

Red Hat Ceph Storage 4 の最新バージョンにのみアップグレードできます。たとえば、バージョン 4.1 が利用可能な場合、3 から 4.0 にアップグレードすることはできません。4.1 に直接移行する必要があります。

重要

FileStore オブジェクトストアを使用する場合は、Red Hat Ceph Storage 3 から Red Hat Ceph Storage 4 にアップグレードした後に BlueStore に移行する必要があります。

重要

Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのアップグレード中に、ceph-ansible を使用して Red Hat Ceph Storage をアップグレードすることはできません。Red Hat Enterprise Linux 7 を使用する必要があります。オペレーティングシステムもアップグレードするには、「Red Hat Ceph Storage の新規バージョンへの手動アップグレードと、Red Hat Enterprise Linux の新たなメジャーリリース」も併せて参照してください。

手順

  1. ストレージクラスター内のすべてのノードで root ユーザーとしてログインします。
  2. Ceph ノードが Red Hat コンテンツ配信ネットワーク (CDN) に接続されていない場合は、ISO イメージを使用して Red Hat Ceph Storage の最新バージョンでローカルリポジトリーを更新することで、Red Hat Ceph Storage をアップグレードできます。
  3. Red Hat Ceph Storage をバージョン 3 からバージョン 4 にアップグレードする場合は、既存の Ceph ダッシュボードのインストールを削除します。

    1. Ansible 管理ノードで、cephmetrics-ansible ディレクトリーに移動します。

      [root@admin ~]# cd /usr/share/cephmetrics-ansible
    2. purge.yml Playbook を実行して、既存の Ceph ダッシュボードのインストールを削除します。

      [root@admin cephmetrics-ansible]# ansible-playbook -v purge.yml
  4. Red Hat Ceph Storage をバージョン 3 からバージョン 4 にアップグレードする場合は、Ansible 管理ノードで Ceph リポジトリーおよび Ansible リポジトリーを有効にします。

    Red Hat Enterprise Linux 7

    [root@admin ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-tools-rpms --enable=rhel-7-server-ansible-2.8-rpms

    Red Hat Enterprise Linux 8

    [root@admin ~]# subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms --enable=ansible-2.8-for-rhel-8-x86_64-rpms

  5. Ansible 管理ノードで、ansible パッケージおよび ceph-ansible パッケージの最新バージョンがインストールされていることを確認します。

    Red Hat Enterprise Linux 7

    [root@admin ~]# yum update ansible ceph-ansible

    Red Hat Enterprise Linux 8

    [root@admin ~]# dnf update ansible ceph-ansible

  6. group_vars/osds.yml ファイルを編集します。以下のオプションを追加して設定します。

    nb_retry_wait_osd_up: 50
    delay_wait_osd_up: 30
  7. Playbook infrastructure-playbooks/rolling_update.yml 編集し、health_osd_check_retries および health_osd_check_delay の値をそれぞれ 50 および 30 に変更します。

    health_osd_check_retries: 50
    health_osd_check_delay: 30

    各 OSD ノードについて、この値により Ansible は最大 25 分待機し、アップグレードプロセスを続行する前に 30 秒ごとにストレージクラスターの正常性をチェックします。

    注記

    ストレージクラスターで使用されているストレージ容量に基づいて、health_osd_check_retries オプションの値をスケールアップまたはダウンします。たとえば、436 TB 未満の 218 TB (ストレージ容量の 50%) を使用している場合は、health_osd_check_retries オプションを 50 に設定します。

  8. アップグレードするストレージクラスターに exclusive-lock 機能を使用する Ceph Block Device イメージが含まれている場合には、全 Ceph Block Device ユーザーにクライアントをブラックリストに登録するパーミッションがあるようにしてください。

    ceph auth caps client.ID mon 'allow r, allow command "osd blacklist"' osd 'EXISTING_OSD_USER_CAPS'
  9. ストレージクラスターが Cockpit を使用して最初にインストールされている場合は、/usr/share/ceph-ansible ディレクトリーに、Cockpit が作成したインベントリーファイルへのシンボリックリンクを /usr/share/ansible-runner-service/inventory/hosts に作成します。

    1. /usr/share/ceph-ansible ディレクトリーに移動します。

      # cd /usr/share/ceph-ansible
    2. シンボリックリンクを作成します。

      # ln -s /usr/share/ansible-runner-service/inventory/hosts hosts
  10. ceph-ansible を使用してクラスターをアップグレードするには、hosts インベントリーファイルのシンボリックリンクを etc/ansible/hosts ディレクトリーに作成します。

    # ln -s /etc/ansible/hosts hosts
  11. ストレージクラスターが Cockpit を使用して最初にインストールされている場合は、Cockpit で生成された SSH 鍵を Ansible ユーザーの ~/.ssh ディレクトリーにコピーします。

    1. 鍵をコピーします。

      # cp /usr/share/ansible-runner-service/env/ssh_key.pub /home/ANSIBLE_USERNAME/.ssh/id_rsa.pub
      # cp /usr/share/ansible-runner-service/env/ssh_key /home/ANSIBLE_USERNAME/.ssh/id_rsa

      ANSIBLE_USERNAME は、Ansible のユーザー名に置き換えます (通常は admin)。

      # cp /usr/share/ansible-runner-service/env/ssh_key.pub /home/admin/.ssh/id_rsa.pub
      # cp /usr/share/ansible-runner-service/env/ssh_key /home/admin/.ssh/id_rsa

    2. キーファイルに適切な所有者、グループ、およびパーミッションを設定します。

      # chown ANSIBLE_USERNAME:_ANSIBLE_USERNAME_ /home/ANSIBLE_USERNAME/.ssh/id_rsa.pub
      # chown ANSIBLE_USERNAME:_ANSIBLE_USERNAME_ /home/ANSIBLE_USERNAME/.ssh/id_rsa
      # chmod 644 /home/ANSIBLE_USERNAME/.ssh/id_rsa.pub
      # chmod 600 /home/ANSIBLE_USERNAME/.ssh/id_rsa

      ANSIBLE_USERNAME は、Ansible のユーザー名に置き換えます (通常は admin)。

      # chown admin:admin /home/admin/.ssh/id_rsa.pub
      # chown admin:admin /home/admin/.ssh/id_rsa
      # chmod 644 /home/admin/.ssh/id_rsa.pub
      # chmod 600 /home/admin/.ssh/id_rsa

関連情報

6.3. Ansible を使用したストレージクラスターのアップグレード

Ansible デプロイメントツールを使用して、ローリングアップグレードを実行して Red Hat Ceph Storage クラスターをアップグレードできます。これらのステップは、特に特に記載がない限り、ベアメタルおよびコンテナーのデプロイメントの両方に適用されます。

前提条件

  • Ansible 管理ノードへのルートレベルのアクセス。
  • ansible ユーザーアカウント。

手順

  1. /usr/share/ceph-ansible ディレクトリーに移動します。

    [root@admin ~]# cd /usr/share/ceph-ansible/
  2. Red Hat Ceph Storage 3 から Red Hat Ceph Storage 4 にアップグレードする場合は、group_vars/all.yml ファイル、group_vars/osds.yml ファイル、および group_vars/clients.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
  3. Red Hat Ceph Storage 3 から Red Hat Ceph Storage 4 にアップグレードする場合は、group_vars/all.yml.samplegroup_vars/osds.yml.sample、および group_vars/clients.yml.sample ファイルの新しいコピーを作成し、名前を group_vars/all.ymlgroup_vars/osds.yml、および group_vars/clients.yml に変更します。以前にバックアップしたコピーに基づいて変更を開き、編集します。

    [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
  4. Red Hat Ceph Storage 4 の新規マイナーバージョンにアップグレードする場合は、group_vars/all.ymlgrafana_container_image の値が group_vars/all.yml.sample の値と同じであることを確認します。同じでない場合は、同じになるように編集します。

    grafana_container_image: registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8:4
    注記

    以下に示すイメージパスは、ceph-ansible バージョン 4.0.23-1 に含まれています。

  5. サンプルファイルから最新の site.yml ファイルまたは site-container.yml ファイルをコピーします。

    1. ベアメタル デプロイメントの場合:

      [root@admin ceph-ansible]# cp site.yml.sample site.yml
    2. コンテナー デプロイメントの場合:

      [root@admin ceph-ansible]# cp site-container.yml.sample site-container.yml
  6. group_vars/all.yml ファイルを開き、以下のオプションを編集します。

    1. fetch_directory オプションを追加します。

      fetch_directory: FULL_DIRECTORY_PATH
      置き換え
      • FULL_DIRECTORY_PATH を、書き込み可能な場所 (Ansible ユーザーのホームディレクトリーなど) に置き換えます。
    2. アップグレードするクラスターに Ceph Object Gateway ノードが含まれている場合には、radosgw_interface オプションを追加します。

      radosgw_interface: INTERFACE
      置き換え
      • Ceph Object Gateway がリッスンするインターフェースを使用する INTERFACE
    3. デフォルトの OSD オブジェクトストアは BlueStore です。従来の OSD オブジェクトストアを維持するには、osd_objectstore オプションを明示的に filestore に設定する必要があります。

      osd_objectstore: filestore
      注記

      osd_objectstore オプションを filestore に設定し、OSD を置き換えると BlueStore ではなく FileStore が使用されます。

      重要

      Red Hat Ceph Storage 4 以降、FileStore は非推奨の機能になりました。Red Hat は、FileStore OSD を BlueStore OSD に移行することを推奨します。

    4. Red Hat Ceph Storage 4.1 以降、/usr/share/ceph-ansible/group_vars/all.ymldashboard_admin_password および grafana_admin_password をコメント解除するか設定する必要があります。それぞれに安全なパスワードを設定します。dashboard_admin_user および grafana_admin_user のカスタムユーザー名も設定します。

      重要

      4.0 から 4.1 にアップグレードする場合は、バグにより、アップグレード中またはアップグレード後に grafana_admin_user または grafana_admin_password を変更することはできません。現時点では、grafana_admin_user および grafana_admin_password のコメントを解除し、アップグレード前に使用した元の値に設定するようにしてください。この問題は Bug 1848753 で追跡されています。

    5. ベアメタル および コンテナー の両方のデプロイメントの場合:

      1. upgrade_ceph_packages オプションをコメント解除して、True に設定します。

        upgrade_ceph_packages: True
      2. ceph_rhcs_version オプションを 4 に設定します。

        ceph_rhcs_version: 4
        注記

        ceph_rhcs_version オプションを 4 に設定すると、最新バージョンの Red Hat Ceph Storage 4 がプルされます。

      3. ceph_docker_registry 情報を all.yml に追加します。

        ceph_docker_registry: registry.redhat.io
        ceph_docker_registry_username: USER_NAME
        ceph_docker_registry_password: PASSWORD
    6. コンテナー のデプロイメントの場合:

      1. ceph_docker_image オプションを変更して、Ceph 4 コンテナーバージョンを指定します。

        ceph_docker_image: rhceph/rhceph-4-rhel8
  7. Red Hat Ceph Storage 3 から Red Hat Ceph Storage 4 にアップグレードする場合は、Ansible インベントリーファイルでデフォルトで /etc/ansible/hosts を開き、[grafana-server] セクションに Ceph ダッシュボードのノード名または IP アドレスを追加します。このセクションが存在しない場合は、ノード名または IP アドレスとともにこのセクションも追加します。
  8. Ansible ユーザーに切り替えるかログインしてから、rolling_update.yml Playbook を実行します。

    [ansible@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/rolling_update.yml -i hosts

    Ansible インベントリーファイルの特定のノードグループにのみ Playbook を使用するには、--limit オプションを使用します。

  9. RBD ミラーリングデーモンノードの root ユーザーとして、rbd-mirror パッケージを手動でアップグレードします。

    [root@rbd ~]# yum upgrade rbd-mirror
  10. rbd-mirror デーモンを再起動します。

    systemctl restart ceph-rbd-mirror@CLIENT_ID
  11. ストレージクラスターのヘルスステータスを確認します。

    1. ベアメタル デプロイメントの場合は、root ユーザーとして monitor ノードにログインし、Ceph status コマンドを実行します。

      [root@mon ~]# ceph -s
    2. container デプロイメントの場合は、Ceph Monitor ノードに root ユーザーとしてログインします。

      1. 実行中のコンテナーの一覧を表示します。

        Red Hat Enterprise Linux 7

        [root@mon ~]# docker ps

        Red Hat Enterprise Linux 8

        [root@mon ~]# podman ps

      2. ヘルスステータスを確認します。

        Red Hat Enterprise Linux 7

        [root@mon ~]# docker exec ceph-mon-MONITOR_NAME ceph -s

        Red Hat Enterprise Linux 8

        [root@mon ~]# podman exec ceph-mon-MONITOR_NAME ceph -s

        置き換え
        • MONITOR_NAME は、前のステップで見つかった Ceph Monitor コンテナーの名前にします。

          [root@mon ~]# podman exec ceph-mon-mon01 ceph -s

  12. アップグレードが完了したら、FileStore OSD を BlueStore OSDs に移行してから、以下の Ansible Playbook を実行します。

    構文

    ansible-playbook infrastructure-playbooks/filestore-to-bluestore.yml --limit OSD_NODE_TO_MIGRATE

    [ansible@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/filestore-to-bluestore.yml --limit osd01

    移行が完了したら、以下のサブ手順を実行します。

    1. group_vars/osds.yml ファイルを編集するために開き、osd_objectstore オプションを bluestore に設定します。以下に例を示します。

      osd_objectstore: bluestore
    2. lvm_volumes 変数を使用している場合は、journal オプションおよび journal_vg オプションをそれぞれ db および db_vg に変更します。以下に例を示します。

      lvm_volumes:
        - data: /dev/sdb
          journal: /dev/sdc1
        - data: /dev/sdd
          journal: journal1
          journal_vg: journals

      lvm_volumes:
        - data: /dev/sdb
          db: /dev/sdc1
        - data: /dev/sdd
          db: journal1
          db_vg: journals

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

    1. Glance ユーザー:

      構文

      ceph auth caps client.glance mon 'profile rbd' osd 'profile rbd pool=GLANCE_POOL_NAME'

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

    2. 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@mon ~]# ceph auth caps client.cinder mon 'profile rbd' osd 'profile rbd pool=volumes, profile rbd pool=vms, profile rbd-read-only pool=images'

    3. 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@mon ~]# 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 プロファイル設定が適用されるようになります。

  14. 必要に応じて、クライアントノードで、Ceph クライアント側ライブラリーに依存するアプリケーションを再起動します。

    注記

    QEMU または KVM インスタンスを実行している OpenStack Nova コンピュートノードをアップグレードする場合や、専用の QEMU または KVM クライアントを使用する場合には、インスタンスを再起動しても機能しないため、QEMU または KVM インスタンスを停止して起動してください。

関連情報

6.4. コマンドラインインターフェースを使用したストレージクラスターのアップグレード

ストレージクラスターの実行中に、Red Hat Ceph Storage 3.3 から Red Hat Ceph Storage 4 にアップグレードできます。これらのバージョンの重要な違いは、Red Hat Ceph Storage4 がデフォルトで msgr2 プロトコルを使用することです。これはポート 3300 を使用します。開いていない場合、クラスターは HEALTH_WARN エラーを発行します。

ストレージクラスターのアップグレード時に考慮すべき制約を以下に示します。

  • Red Hat Ceph Storage 4 では、デフォルトで msgr2 プロトコルが使用されます。Ceph Monitor ノードでポート 3300 が開いていることを確認します。
  • ceph-monitor デーモンを Red Hat Ceph Storage 3 から Red Hat Ceph Storage 4 にアップグレードしたら、Red Hat Ceph Storage 3 の ceph-osd デーモンは、Red Hat Ceph Storage 4 にアップグレードするまで、新しい OSD を作成 できません
  • アップグレードの進行中はプールを 作成しないでください

前提条件

  • Ceph Monitor ノード、OSD ノード、および Object Gateway ノードへのルートレベルのアクセス。

手順

  1. Red Hat Ceph Storage 3 の実行中に、クラスターがすべての PG の完全スクラブを 1 つ以上完了していることを確認します。これを実行しないと、モニターデーモンは起動時にクォーラムへの参加を拒否し、機能しなくなる可能性があります。クラスターがすべての PG の完全スクラブを 1 つ以上完了していることを確認するには、以下を実行します。

    # ceph osd dump | grep ^flags

    Red Hat Ceph Storage 3 から Red Hat Ceph Storage 4 へのアップグレードを続行するには、OSD マップに recovery_deletes フラグおよび purged_snapdirsフラグが含まれている必要があります。

  2. クラスターが正常な状態でクリーンな状態であることを確認します。

    # ceph health
    HEALTH_OK
  3. ceph-mon および ceph-manager を実行しているノードの場合は、以下のコマンドを実行します。

    # subscription-manager repos --enable=rhel-7-server-rhceph-4-mon-rpms

    Red Hat Ceph Storage 4 パッケージを有効にしたら、それぞれの ceph-mon ノードおよび ceph- manager ノードで以下のコマンドを実行します。

    # firewall-cmd --add-port=3300/tcp
    # firewall-cmd --add-port=3300/tcp --permanent
    # yum update -y
    # systemctl restart ceph-mon@<mon-hostname>
    # systemctl restart ceph-mgr@<mgr-hostname>

    <mon-hostname> および <mgr-hostname> をターゲットホストのホスト名に置き換えます。

  4. OSD をアップグレードする前に、アップグレード中の OSD のリバランスを防ぐために、Ceph Monitor ノードで norebalance フラグを設定します。

    # ceph osd unset norebalance
  5. 各 OSD ノードで、以下を実行します。

    # subscription-manager repos --enable=rhel-7-server-rhceph-4-osd-rpms

    Red Hat Ceph Storage 4 パッケージを有効にしたら、OSD ノードを更新します。

    # yum update -y

    ノードで実行している各 OSD デーモンについて、以下のコマンドを実行します。

    # systemctl restart ceph-osd@<osd-num>

    <osd-num> を、再起動する osd 番号に置き換えてください。次の OSD ノードに進む前に、ノード上の全 OSD が再起動したことを確認します。

  6. ceph-disk を使用してデプロイされたストレージクラスターに OSD がある場合には、ceph-volume にデーモンを起動するように指示します。

    # ceph-volume simple scan
    # ceph-volume simple activate --all
  7. Nautilus の機能のみを有効にします。

    # ceph osd require-osd-release nautilus
    重要

    このステップの実行に失敗すると、msgr2 が有効になってから OSD が通信できなくなります。

  8. すべての OSD ノードをアップグレードしたら、Ceph Monitor ノードで noout フラグの設定を解除します。

    # ceph osd unset noout
  9. 既存の CRUSH バケットを、最新のバケットタイプ straw2 に切り替えます。

    # ceph osd getcrushmap -o backup-crushmap
    # ceph osd crush set-all-straw-buckets-to-straw2
  10. Specify v2 プロトコル msgr2 を有効にします。

    # ceph mon enable-msgr2

    これにより、古いデフォルトポート 6789 にバインドされるすべての Ceph Monitor が新しいポート 3300 にバインドされるように指示します。

    1. monitor のステータスを確認します。

      #ceph mon dump
  11. Ceph Object Gateway ノードで、以下を実行します。

    # subscription-manager repos --enable=rhel-7-server-rhceph-4-tools-rpms

    Red Hat Ceph Storage 4 パッケージを有効にしたら、ノードを更新して、ceph-rgw デーモンを再起動します。

    # yum update -y
    # systemctl restart ceph-rgw@<rgw-target>

    <rgw-target> を、再起動する rgw ターゲットに置き換えてください。

  12. 管理ノードの場合には、以下のコマンドを実行します。

    # subscription-manager repos --enable=rhel-7-server-rhceph-4-tools-rpms
    # yum update -y
  13. クラスターが正常な状態でクリーンな状態であることを確認します。

    # ceph health
    HEALTH_OK
  14. 必要に応じて、クライアントノードで、Ceph クライアント側ライブラリーに依存するアプリケーションを再起動します。

    注記

    QEMU または KVM インスタンスを実行している OpenStack Nova コンピュートノードをアップグレードする場合や、専用の QEMU または KVM クライアントを使用する場合には、インスタンスを再起動しても機能しないため、QEMU または KVM インスタンスを停止して起動してください。

第7章 Red Hat Ceph Storage クラスターおよびオペレーティングシステムの手動によるアップグレード

通常、ceph-ansible を使用する場合には、Red Hat Ceph Storage および Red Hat Enterprise Linux を同時に新しいメジャーリリースにアップグレードすることはできません。たとえば、Red Hat Enterprise Linux 7を使用し、ceph-ansible を使用している場合は、そのバージョンを使用する必要があります。ただし、システム管理者は手動で実行できます。

本章では、Red Hat Enterprise Linux 7.8 で実行しているバージョン 4.0 または 3.3z4 の Red Hat Ceph Storage クラスターを、Red Hat Enterprise Linux 8.2 で実行するバージョン 4.1 の Red Hat Ceph Storage クラスターに手動でアップグレードします。

7.1. 前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードは Red Hat Enterprise Linux 7.8 を実行している。
  • ノードは Red Hat Ceph Storage バージョン 3.3z4 または 4.0 を使用している。
  • Red Hat Enterprise Linux 8.2 のインストールソースへのアクセス

7.2. Ceph Monitor ノードとそのオペレーティングシステムを手動でアップグレード

システム管理者は、Red Hat Ceph Storage クラスターノードおよび Red Hat Enterprise Linux オペレーティングシステム上の Ceph Monitor ソフトウェアを、同時に新しいメジャーリリースに手動でアップグレードできます。

重要

一度に 1 つのモニターノードのみで手順を実施します。クラスターアクセスの問題を防ぐために、次のノードに進む に、現在のアップグレードされた Monitor ノードが通常の操作に返されていることを確認してください。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードは Red Hat Enterprise Linux 7.8 を実行している。
  • ノードは Red Hat Ceph Storage バージョン 3.3z4 または 4.0 を使用している。
  • Red Hat Enterprise Linux 8.2 のインストールソースへのアクセス

手順

  1. monitor サービスを停止します。

    # systemctl stop ceph-mon@MONITOR_ID

    MONITOR_ID を Monitor の ID 番号に置き換えます。

  2. Red Hat Ceph Storage 3 を使用している場合は、Red Hat Ceph Storage 3 リポジトリーを無効にします。

    1. tools リポジトリーを無効にします。

      # subscription-manager repos --disable=rhel-7-server-rhceph-3-tools-rpms
    2. mon リポジトリーを無効にします。

      # subscription-manager repos --disable=rhel-7-server-rhceph-3-mon-rpms
  3. Red Hat Ceph Storage 4 を使用している場合は、Red Hat Ceph Storage 4 リポジトリーを無効にします。

    1. tools リポジトリーを無効にします。

      # subscription-manager repos --disable=rhel-7-server-rhceph-4-tools-rpms
    2. mon リポジトリーを無効にします。

      # subscription-manager repos --disable= rhel-7-server-rhceph-4-mon-rpms
  4. leapp ユーティリティーをインストールします。『Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのアップグレード』を参照してください。
  5. leapp のアップグレード前チェックを実行します。「コマンドラインからのアップグレード可能性の評価」を参照してください。
  6. /etc/ssh/sshd_configPermitRootLogin yes を設定します。
  7. OpenSSH SSH デーモンを再起動します。

    # systemctl restart sshd.service
  8. Linux カーネルから iSCSI モジュールを削除します。

    # modprobe -r iscsi
  9. 『RHEL 7 から RHEL 8 へのアップグレードの実行』に従って、アップグレードを実行します。
  10. ノードを再起動します。
  11. Red Hat Enterprise Linux 8 用の Red Hat Ceph Storage 4 用のリポジトリーを有効にします。

    1. tools リポジトリーを有効にします。

      # subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
    2. mon リポジトリーを有効にします。

      # subscription-manager repos --enable=rhceph-4-mon-for-rhel-8-x86_64-rpms
  12. ceph-mon パッケージをインストールします。

    # dnf install ceph-mon
  13. マネージャーサービスが monitor サービスと同じ場所にある場合は、ceph-mgr パッケージをインストールします。

    # dnf install ceph-mgr
  14. アップグレードされていない、またはそれらのファイルをすでに復元しているノードから、ceph-client-admin.keyring ファイルおよび ceph.conf ファイルを復元します。
  15. leveldb パッケージをインストールします。

    # dnf install leveldb
  16. monitor サービスを起動します。

    # systemctl start ceph-mon.target
  17. マネージャーサービスが monitor サービスと同じ場所にある場合は、マネージャーサービスも起動します。

    # systemctl start ceph-mgr.target
  18. モニターサービスが復旧し、クォーラムになっていることを確認します。

    # ceph -s

    services:mon: 行で、ノードが 定足数 の外ではなく 定足数 内に一覧表示されていることを確認します。

    mon: 3 daemons, quorum jb-ceph4-mon,jb-ceph4-mon2,jb-ceph4-mon3 (age 2h)
  19. マネージャーサービスが monitor サービスと同じ場所にある場合は、それも稼働していることを確認します。

    # ceph -s

    services の下にある mgr: 行でマネージャーのノード名を検索します。

    mgr: jb-ceph4-mon(active, since 2h), standbys: jb-ceph4-mon3, jb-ceph4-mon2
  20. すべてのアップグレードが完了するまで、すべての監視ノードで上記の手順を繰り返します。

7.3. Ceph OSD ノードとそのオペレーティングシステムの手動によるアップグレード

システム管理者は、Red Hat Ceph Storage クラスターノードおよび Red Hat Enterprise Linux オペレーティングシステム上の Ceph OSD ソフトウェアを、同時に新しいメジャーリリースに手動でアップグレードできます。

重要

この手順は、Ceph クラスターの各 OSD ノードに対して実行する必要がありますが、通常は一度に 1 つの OSD ノードに対してのみ実行してください。OSD ノードに相当する最大 1 つ障害ドメインを並行して実行することが可能です。たとえば、ラックごとのレプリケーションが使用されている場合は、ラックの OSD ノード全体を並行してアップグレードできます。データへのアクセスの問題を防ぐには、現在の OSD ノードの OSD が正常な動作に戻り、クラスターの PG が すべて次の OSD に進む active+clean 状態にあることを確認します。

重要

Leapp アップグレードユーティリティーは OSD 暗号化によるアップグレードをサポートしないため、この手順は暗号化された OSD パーティションでは機能しません。

重要

OSD が ceph-disk を使用して作成されていて、ceph-disk が管理している場合には、ceph-volume を使用してそれらの管理を引き継ぐ必要があります。これは、以下の任意の手順で説明されています。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードは Red Hat Enterprise Linux 7.8 を実行している。
  • ノードは Red Hat Ceph Storage バージョン 3.3z4 または 4.0 を使用している。
  • Red Hat Enterprise Linux 8.2 のインストールソースへのアクセス

手順

  1. OSD の noout フラグを設定して、移行中に OSD がダウンとマークされないようにします。

    # ceph osd set noout
  2. クラスター上で不要な負荷を回避するには、OSD nobackfill フラグ、norecover フラグ、norrebalance フラグ、noscrub フラグ、および nodeep-scrub フラグを設定し、ノードが移行のためにダウンした場合にデータの再起動を回避します。

    # ceph osd set nobackfill
    # ceph osd set norecover
    # ceph osd set norebalance
    # ceph osd set noscrub
    # ceph osd set nodeep-scrub
  3. ノード上のすべての OSD プロセスを正常にシャットダウンします。

    # systemctl stop ceph-osd.target
  4. Red Hat Ceph Storage 3 を使用している場合は、Red Hat Ceph Storage 3 リポジトリーを無効にします。

    1. tools リポジトリーを無効にします。

      # subscription-manager repos --disable=rhel-7-server-rhceph-3-tools-rpms
    2. osd リポジトリーを無効にします。

      # subscription-manager repos --disable=rhel-7-server-rhceph-3-osd-rpms
  5. Red Hat Ceph Storage 4 を使用している場合は、Red Hat Ceph Storage 4 リポジトリーを無効にします。

    1. tools リポジトリーを無効にします。

      # subscription-manager repos --disable=rhel-7-server-rhceph-4-tools-rpms
    2. osd リポジトリーを無効にします。

      # subscription-manager repos --disable= rhel-7-server-rhceph-4-osd-rpms
  6. leapp ユーティリティーをインストールします。『Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのアップグレード』を参照してください。
  7. leapp のアップグレード前チェックを実行します。「コマンドラインからのアップグレード可能性の評価」を参照してください。
  8. /etc/ssh/sshd_configPermitRootLogin yes を設定します。
  9. OpenSSH SSH デーモンを再起動します。

    # systemctl restart sshd.service
  10. Linux カーネルから iSCSI モジュールを削除します。

    # modprobe -r iscsi
  11. 『RHEL 7 から RHEL 8 へのアップグレードの実行』に従って、アップグレードを実行します。
  12. ノードを再起動します。
  13. Red Hat Enterprise Linux 8 用の Red Hat Ceph Storage 4 用のリポジトリーを有効にします。

    1. tools リポジトリーを有効にします。

      # subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
    2. osd リポジトリーを有効にします。

      # subscription-manager repos --enable=rhceph-4-osd-for-rhel-8-x86_64-rpms
  14. ceph-osd パッケージをインストールします。

    # dnf install ceph-osd
  15. leveldb パッケージをインストールします。

    # dnf install leveldb
  16. まだアップグレードされていないノードから、またはそれらのファイルがすでに復元されているノードから、ceph.conf ファイルを復元します。
  17. nooutnobackfillnorecovernorrebalancenoscrub、および nodeep-scrub フラグの設定を解除します。

    # ceph osd unset noout
    # ceph osd unset nobackfill
    # ceph osd unset norecover
    # ceph osd unset norebalance
    # ceph osd unset noscrub
    # ceph osd unset nodeep-scrub
  18. 必要に応じて、OSD が ceph-disk を使用して作成されていて、ceph-disk で引き続き管理されている場合には、ceph-volume を使用してそれらの管理を引き継ぐ必要があります。

    1. 各オブジェクトのストレージデバイスをマウントします。

      # /dev/DRIVE /var/lib/ceph/osd/ceph-OSD_ID

      DRIVE は、ストレージデバイス名とパーティション番号に置き換えます。

      OSD_ID を OSD ID に置き換えます。

      [root@magna023 ~]# mount /dev/sdb1 /var/lib/ceph/osd/ceph-0

      ID_NUMBER が正しいことを確認します。

      # cat /var/lib/ceph/osd/ceph-OSD_ID/whoami

      OSD_ID を OSD ID に置き換えます。

      [root@magna023 ~]# cat /var/lib/ceph/osd/ceph-0/whoami
      0

      追加のオブジェクトストアデバイスに対して上記の手順を繰り返します。

    2. 新たにマウントしたデバイスをスキャンします。

      # ceph-volume simple scan /var/lib/ceph/osd/ceph-OSD_ID

      OSD_ID を OSD ID に置き換えます。

      [root@magna023 ~]# ceph-volume simple scan /var/lib/ceph/osd/ceph-0
       stderr: lsblk: /var/lib/ceph/osd/ceph-0: not a block device
       stderr: lsblk: /var/lib/ceph/osd/ceph-0: not a block device
       stderr: Unknown device, --name=, --path=, or absolute path in /dev/ or /sys expected.
      Running command: /usr/sbin/cryptsetup status /dev/sdb1
      --> OSD 0 got scanned and metadata persisted to file: /etc/ceph/osd/0-0c9917f7-fce8-42aa-bdec-8c2cf2d536ba.json
      --> To take over management of this scanned OSD, and disable ceph-disk and udev, run:
      -->     ceph-volume simple activate 0 0c9917f7-fce8-42aa-bdec-8c2cf2d536ba

      追加のオブジェクトストアデバイスに対して上記の手順を繰り返します。

    3. デバイスをアクティベートします。

      # ceph-volume simple activate OSD_ID UUID

      OSD_ID を OSD ID に置き換え、UUID を、以前のスキャン出力で出力される UUID に置き換えます。

      [root@magna023 ~]# ceph-volume simple activate 0 0c9917f7-fce8-42aa-bdec-8c2cf2d536ba
      Running command: /usr/bin/ln -snf /dev/sdb2 /var/lib/ceph/osd/ceph-0/journal
      Running command: /usr/bin/chown -R ceph:ceph /dev/sdb2
      Running command: /usr/bin/systemctl enable ceph-volume@simple-0-0c9917f7-fce8-42aa-bdec-8c2cf2d536ba
       stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@simple-0-0c9917f7-fce8-42aa-bdec-8c2cf2d536ba.service → /usr/lib/systemd/system/ceph-volume@.service.
      Running command: /usr/bin/ln -sf /dev/null /etc/systemd/system/ceph-disk@.service
      --> All ceph-disk systemd units have been disabled to prevent OSDs getting triggered by UDEV events
      Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
       stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph-osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
      Running command: /usr/bin/systemctl start ceph-osd@0
      --> Successfully activated OSD 0 with FSID 0c9917f7-fce8-42aa-bdec-8c2cf2d536ba

      追加のオブジェクトストアデバイスに対して上記の手順を繰り返します。

  19. 必要に応じて、OSD が ceph-volume で作成され、直前の手順を完了していない場合は、ここで OSD サービスを起動します。

    # systemctl start ceph-osd.target
  20. OSD をアクティベートします。

    # ceph-volume lvm activate --all --filestore
    # ceph-volume lvm activate --all
  21. OSD がup および in になっていること、ならびに、active+clean 状態にあることを確認します。

    # ceph -s

    services: サービス下の osd: 行で、すべての OSD が up および in であることを確認します。

    osd: 3 osds: 3 up (since 8s), 3 in (since 3M)
  22. すべての OSD ノードがアップグレードされるまで、上記の手順をすべての OSD ノードで繰り返します。

7.4. Ceph Object Gateway ノードとそのオペレーティングシステムの手動によるアップグレード

システム管理者は、Red Hat Ceph Storage クラスターノードおよび Red Hat Enterprise Linux オペレーティングシステム上の Ceph Object Gateway (RGW) ソフトウェアを、同時に新しいメジャーリリースに手動でアップグレードできます。

重要

この手順は、Ceph クラスターの各 RGW ノードに対して実行する必要がありますが、一度に 1 つの RGW ノードに対してのみ実行してください。現在アップグレードした RGW が通常操作に戻るには、クライアントアクセスの問題を防ぐために、次のノードに進む に、通常の操作に戻ります。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードは Red Hat Enterprise Linux 7.8 を実行している。
  • ノードは Red Hat Ceph Storage バージョン 3.3z4 または 4.0 を使用している。
  • Red Hat Enterprise Linux 8.2 のインストールソースへのアクセス

手順

  1. Ceph Object Gateway サービスを停止します。

    # systemctl stop ceph-radosgw.target
  2. Red Hat Ceph Storage 3 を使用している場合は、Red Hat Ceph Storage 3 ツールリポジトリーを無効にします。

    # subscription-manager repos --disable=rhel-7-server-rhceph-3-tools-rpms
  3. Red Hat Ceph Storage 4 を使用している場合は、Red Hat Ceph Storage 4 ツールリポジトリーを無効にします。

    # subscription-manager repos --disable=rhel-7-server-rhceph-4-tools-rpms
  4. leapp ユーティリティーをインストールします。『Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのアップグレード』を参照してください。
  5. leapp のアップグレード前チェックを実行します。「コマンドラインからのアップグレード可能性の評価」を参照してください。
  6. /etc/ssh/sshd_configPermitRootLogin yes を設定します。
  7. OpenSSH SSH デーモンを再起動します。

    # systemctl restart sshd.service
  8. Linux カーネルから iSCSI モジュールを削除します。

    # modprobe -r iscsi
  9. 『RHEL 7 から RHEL 8 へのアップグレードの実行』に従って、アップグレードを実行します。
  10. ノードを再起動します。
  11. Red Hat Enterprise Linux 8 用の Red Hat Ceph Storage 4 用のツールリポジトリーを有効にします。

    # subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
  12. ceph-radosgw パッケージをインストールします。

    # dnf install ceph-radosgw
  13. 必要に応じて、このノードにコロケーションされる Ceph サービスのパッケージをインストールします。必要に応じて追加の Ceph リポジトリーを有効にします。
  14. 必要に応じて、他の Ceph サービスに必要な leveldb パッケージをインストールします。

    # dnf install leveldb
  15. アップグレードされていないノードまたはそれらのファイルを復元しているノードから ceph-client-admin.keyring ファイルおよび ceph.conf ファイルを復元します。
  16. RGW サービスを起動します。

    # systemctl start ceph-radosgw.target
  17. デーモンがアクティブであることを確認します。

    # ceph -s

    services: の下に rgw: 行があります。

    rgw: 1 daemon active (jb-ceph4-rgw.rgw0)
  18. すべてがアップグレードされるまで、すべての Ceph ObjectGateway ノードで上記の手順を繰り返します。

7.5. Ceph Dashboard ノードとそのオペレーティングシステムを手動でアップグレード

システム管理者は、Red Hat Ceph Storage クラスターノードおよび Red Hat Enterprise Linux オペレーティングシステム上の Ceph Dashboard ソフトウェアを同時に新しいメジャーリリースにアップグレードできます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードが Red Hat Enterprise Linux 7.8 を実行している。
  • ノードが Red Hat Ceph Storage バージョン 3.3z4 または 4.0 を実行している
  • Red Hat Enterprise Linux 8.2 のインストールソースへのアクセス

手順

  1. クラスターから既存のダッシュボードをアンインストールします。

    1. /usr/share/cephmetrics-ansible ディレクトリーに移動します。

      # cd /usr/share/cephmetrics-ansible
    2. Ansible Playbook の purge.yml を実行します。

      # ansible-playbook -v purge.yml
  2. Red Hat Ceph Storage 3 を使用している場合は、Red Hat Ceph Storage 3 ツールリポジトリーを無効にします。

    # subscription-manager repos --disable=rhel-7-server-rhceph-3-tools-rpms
  3. Red Hat Ceph Storage 4 を使用している場合は、Red Hat Ceph Storage 4 ツールリポジトリーを無効にします。

    # subscription-manager repos --disable=rhel-7-server-rhceph-4-tools-rpms
  4. leapp ユーティリティーをインストールします。『Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのアップグレード』を参照してください。
  5. leapp のアップグレード前チェックを実行します。「コマンドラインからのアップグレード可能性の評価」を参照してください。
  6. /etc/ssh/sshd_configPermitRootLogin yes を設定します。
  7. OpenSSH SSH デーモンを再起動します。

    # systemctl restart sshd.service
  8. Linux カーネルから iSCSI モジュールを削除します。

    # modprobe -r iscsi
  9. 『RHEL 7 から RHEL 8 へのアップグレードの実行』に従って、アップグレードを実行します。
  10. ノードを再起動します。
  11. Red Hat Enterprise Linux 8 用の Red Hat Ceph Storage 4 用のツールリポジトリーを有効にします。

    # subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
  12. Ansible リポジトリーを有効にします。

    # subscription-manager repos --enable=ansible-2.8-for-rhel-8-x86_64-rpms
  13. クラスターを管理するために ceph-ansible を構成します。ダッシュボードをインストールします。『インストールガイド』「Ansible を使用した Red Hat Ceph Storage のインストール」(前提条件を含む) の手順に従ってください。
  14. 上記の手順の一部として ansible-playbook site.yml を実行すると、ダッシュボードの URL が出力されます。URL の場所とダッシュボードへのアクセスに関する詳細は、『ダッシュボード』「Ansible を使用したダッシュボードのインストール」を参照してください。

7.6. OSD ノードでのオペレーティングシステムのアップグレード失敗からの復旧

システム管理者は、手動で Ceph OSD ノードとそのオペレーティングシステムをアップグレード する手順に障害が発生した場合に、以下の手順に従って障害から回復することができます。この手順では、ノードに Red Hat Enterprise Linux 8.2 を新規インストールし、OSD が停止している間にダウンしていた書き込み以外に、データを大幅に埋め戻すことなく OSD を回復できます。

重要

OSD をサポートするメディアや、それぞれの wal.db データベースまたは block.db データベースには影響を及ぼさないようにしてください。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • アップグレードに失敗した OSD ノード。
  • Red Hat Enterprise Linux 8.2 のインストールソースへのアクセス

手順

  1. 障害のあるノードで Red Hat Enterprise Linux 8.2 の標準的なインストールを実行し、Red Hat Enterprise Linux リポジトリーを有効にします。

  2. Red Hat Enterprise Linux 8 用の Red Hat Ceph Storage 4 用のリポジトリーを有効にします。

    1. tools リポジトリーを有効にします。

      # subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
    2. osd リポジトリーを有効にします。

      # subscription-manager repos --enable=rhceph-4-osd-for-rhel-8-x86_64-rpms
  3. ceph-osd パッケージをインストールします。

    # dnf install ceph-osd
  4. アップグレードされていないノードから、またはそれらのファイルがすでに復元されているノードから、ceph.conf ファイルを /etc/ceph に復元します。
  5. OSD サービスを起動します。

    # systemctl start ceph-osd.target
  6. オブジェクトストアデバイスをアクティブにします。

    ceph-volume lvm activate --all
  7. OSD のリカバリーおよびクラスターのバックフィルが、復旧した OSD への書き込みを確認します。

    # ceph -w

    すべての PG が active+clean の状態になるまで、出力を監視します。

7.7. 関連情報

第8章 次のステップ

これは、最新のデータセンターの困難なストレージ要求を満たすために Red Hat Ceph Storage が実行できることの開始点にすぎません。以下は、さまざまなトピックの情報へのリンクになります。

  • パフォーマンスのベンチマークとパフォーマンスカウンターへのアクセスは、Red Hat Ceph Storage 4 の『管理ガイド』の「パフォーマンスのベンチマーク」の章を参照してください。
  • スナップショットの作成および管理。Red Hat Ceph Storage 4 の『ブロックデバイスガイド』の「スナップショット」の章を参照してください。
  • Red Hat Ceph Storage クラスターの拡張については、Red Hat Ceph Storage 4 の『管理ガイド』の「クラスターサイズの管理」の章を参照してください。
  • Ceph Block Device のミラーリングは、Red Hat Ceph Storage 4 の『ブロックデバイスガイド』の「ブロックデバイスのミラーリング」の章を参照してください。
  • プロセス管理。Red Hat Ceph Storage 4 の『管理ガイド』の「プロセスの管理」の章を参照してください。
  • 調整可能なパラメーター。Red Hat Ceph Storage 4 の 「設定ガイド」を参照してください。
  • OpenStack のバックエンドストレージとして Ceph を使用する場合には、Red Hat OpenStack Platform の 『ストレージガイド』の「バックエンド」セクションを参照してください。
  • Ceph Dashboard を使用して、Red Hat Ceph Storage クラスターの正常性および容量を監視します。詳細は、『ダッシュボードガイド』を参照してください。

付録A トラブルシューティング

A.1. 予想したデバイスよりも少ないため、Ansible がインストールを停止します。

Ansible 自動化アプリケーションはインストールプロセスを停止し、以下のエラーを返します。

- name: fix partitions gpt header or labels of the osd disks (autodiscover disks)
  shell: "sgdisk --zap-all --clear --mbrtogpt -- '/dev/{{ item.0.item.key }}' || sgdisk --zap-all --clear --mbrtogpt -- '/dev/{{ item.0.item.key }}'"
  with_together:
    - "{{ osd_partition_status_results.results }}"
    - "{{ ansible_devices }}"
  changed_when: false
  when:
    - ansible_devices is defined
    - item.0.item.value.removable == "0"
    - item.0.item.value.partitions|count == 0
    - item.0.rc != 0

エラー内容:

/usr/share/ceph-ansible/group_vars/osds.yml ファイルで osd_auto_discovery パラメーターが true に設定されている場合、Ansible は利用可能なすべてのデバイスを自動的に検出して設定します。このプロセス中、Ansible はすべての OSD が同じデバイスを使用することを想定します。デバイスは、Ansible が名前を検出するのと同じ順序で名前を取得します。いずれかの OSD でデバイスのいずれかが失敗すると、Ansible は障害が発生したデバイスの検出に失敗し、インストールプロセス全体を停止します。

状況例:

  1. 3 つの OSD ノード (host1host2host3) は、/dev/sdb ディスク、/dev/sdc ディスク、および dev/sdd ディスクを使用します。
  2. host2 では、/dev/sdc ディスクに障害が発生し、削除されます。
  3. 次回の再起動時に、Ansible は削除した /dev/sdc ディスクの検出に失敗し、host2/dev/sdb および /dev/sdc (以前は /dev/sdd) には 2 つのディスクのみが使用されることを想定します。
  4. Ansible はインストールプロセスを停止し、上記のエラーメッセージを返します。

この問題を修正するには、以下を実行します。

/etc/ansible/hosts ファイルで、障害が発生したディスクを持つ OSD ノードが使用するデバイスを指定します (上記の例の host2 )。

[osds]
host1
host2 devices="[ '/dev/sdb', '/dev/sdc' ]"
host3

詳細は4章Ansible を使用した Red Hat Ceph Storage のインストールを参照してください。

付録B コマンドラインインターフェースを使用した Ceph ソフトウェアのインストール

ストレージ管理者は、Red Hat Ceph Storage ソフトウェアのさまざまなコンポーネントを手動でインストールすることを選択できます。

B.1. Ceph コマンドラインインターフェースのインストール

Ceph コマンドラインインターフェース (CLI) により、管理者は Ceph 管理コマンドを実行できます。CLI は ceph-common パッケージにより提供され、以下のユーティリティーが含まれます。

  • ceph
  • ceph-authtool
  • ceph-dencoder
  • rados

前提条件

  • 稼働中の Ceph ストレージクラスター (active + clean の状態が望ましい)。

手順

  1. クライアントノードで、Red Hat Ceph Storage 4 Tools リポジトリーを有効にします。

    [root@gateway ~]# subscription-manager repos --enable=rhceph-4-mon-for-rhel-8-x86_64-rpms
  2. クライアントノードで、ceph-common パッケージをインストールします。

    # yum install ceph-common
  3. 最初の監視ノードから、Ceph 設定ファイル (ここでは ceph.conf) と管理キーリングをクライアントノードにコピーします。

    構文

    # scp /etc/ceph/ceph.conf <user_name>@<client_host_name>:/etc/ceph/
    # scp /etc/ceph/ceph.client.admin.keyring <user_name>@<client_host_name:/etc/ceph/

    # scp /etc/ceph/ceph.conf root@node1:/etc/ceph/
    # scp /etc/ceph/ceph.client.admin.keyring root@node1:/etc/ceph/

    <client_host_name> を、クライアントノードのホスト名に置き換えてください。

B.2. Red Hat Ceph Storage の手動インストール

重要

Red Hat は、手動でデプロイしたクラスターのアップグレードをサポートしたり、テストしたりしません。したがって、Red Hat は、Ansible を使用して Red Hat Ceph Storage 4 で新規クラスターをデプロイすることを推奨します。詳細は4章Ansible を使用した Red Hat Ceph Storage のインストールを参照してください。

Yum などのコマンドラインユーティリティーを使用して、手動でデプロイされたクラスターをアップグレードすることができますが、Red Hat ではこのアプローチのサポートまたはテストを行いません。

すべての Ceph クラスターにはモニターが少なくとも 1 つ、最低でも OSD がクラスターに保存されているオブジェクトのコピーとして必要になります。Red Hat は、実稼働環境に 3 台のモニターを使用し、少なくとも 3 つのオブジェクトストレージデバイス (OSD) を使用することを推奨します。

初期モニターのブートストラップは、Ceph ストレージクラスターをデプロイする最初のステップです。Ceph monitor デプロイメントは、以下のようなクラスター全体の重要な基準も設定します。

  • プールのレプリカ数
  • OSD ごとの配置グループ数
  • ハートビートの間隔
  • 認証要件

これらの値の多くはデフォルトで設定されるため、実稼働環境用のクラスターを設定する際に便利です。

コマンドラインインターフェースを使用して Ceph Storage クラスターをインストールするには、以下の手順を行います。

ブートストラップの監視

Monitor のブートストラップおよび Ceph Storage クラスターの拡張には、以下のデータが必要です。

一意識別子
ファイルシステム識別子 (fsid) はクラスターの一意の識別子です。fsid は、Ceph ストレージクラスターが Ceph ファイルシステムに主に使用する場合に使用されていました。Ceph はネイティブのインターフェース、ブロックデバイス、およびオブジェクトストレージゲートウェイのインターフェースもサポートするようになり、fsid は一部の誤検出になります。
監視名
クラスター内の各 Monitor インスタンスには一意の名前があります。一般的には、Ceph Monitor 名はノード名です。Red Hat では、ノードごとに Ceph Monitor を 1 つ推奨していますが、Ceph OSD デーモンを Ceph Monitor デーモンと同じ場所に配置しないことを推奨します。短いノード名を取得するには、hostname -s コマンドを使用します。
マップの監視

初期モニターのブートストラップでは、モニターマップを生成する必要があります。Monitor マップには以下が必要です。

  • ファイルシステム識別子 (fsid)
  • クラスター名、または ceph のデフォルトのクラスター名が使用されます。
  • 1 つ以上のホスト名とその IP アドレス
キーリングの監視
モニターは、秘密鍵を使用して相互に通信します。Monitor 秘密鍵でキーリングを生成し、初期 Monitor のブートストラップ時にこれを提供する必要があります。
管理者キーリング
ceph コマンドラインインターフェースユーティリティーを使用するには、client.admin ユーザーを作成し、そのキーリングを生成します。また、client.admin ユーザーを Monitor キーリングに追加する必要があります。

前述の要件は、Ceph 設定ファイルの作成を意味するものではありません。ただし、Red Hat では、Ceph 設定ファイルを作成し、少なくとも fsidmon initial members、および mon host の設定で設定することを推奨します。

実行時にすべての Monitor 設定を取得および設定できます。ただし、Ceph 設定ファイルには、デフォルト値を上書きする設定のみが含まれる場合があります。Ceph 設定ファイルに設定を追加すると、デフォルト設定が上書きされます。Ceph 設定ファイルでこれらの設定を維持すると、クラスターを簡単に維持できます。

初期モニターをブートストラップするには、以下の手順を実行します。

  1. Red Hat Ceph Storage 4 Monitor リポジトリーを有効にします。

    [root@monitor ~]# subscription-manager repos --enable=rhceph-4-mon-for-rhel-8-x86_64-rpms
  2. 初期 Monitor ノードで、rootceph-mon パッケージをインストールします。

    # yum install ceph-mon
  3. root で、/etc/ceph/ ディレクトリーに Ceph 設定ファイルを作成します。

    # touch /etc/ceph/ceph.conf
  4. root でクラスターの一意の識別子を生成し、一意の ID を Ceph 設定ファイルの [global] セクションに追加します。

    # echo "[global]" > /etc/ceph/ceph.conf
    # echo "fsid = `uuidgen`" >> /etc/ceph/ceph.conf
  5. 現在の Ceph 設定ファイルを表示します。

    $ cat /etc/ceph/ceph.conf
    [global]
    fsid = a7f64266-0894-4f1e-a635-d0aeaca0e993
  6. root として、最初の Monitor を Ceph 設定ファイルに追加します。

    構文

    # echo "mon initial members = <monitor_host_name>[,<monitor_host_name>]" >> /etc/ceph/ceph.conf

    # echo "mon initial members = node1" >> /etc/ceph/ceph.conf

  7. root として、初期 Monitor の IP アドレスを Ceph 設定ファイルに追加します。

    構文

    # echo "mon host = <ip-address>[,<ip-address>]" >> /etc/ceph/ceph.conf

    # echo "mon host = 192.168.0.120" >> /etc/ceph/ceph.conf

    注記

    IPv6 アドレスを使用するには、ms bind ipv6 オプションを true に設定します。詳細は、Red Hat Ceph Storage 4 の『設定ガイド』の「バインド」セクションを参照してください。

  8. root として、クラスターのキーリングを作成し、Monitor シークレットキーを生成します。

    # ceph-authtool --create-keyring /tmp/ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'
    creating /tmp/ceph.mon.keyring
  9. root で管理者キーリングを生成し、ceph.client.admin.keyring ユーザーを生成し、ユーザーをキーリングに追加します。

    構文

    # ceph-authtool --create-keyring /etc/ceph/ceph.client.admin.keyring --gen-key -n client.admin --set-uid=0 --cap mon '<capabilites>' --cap osd '<capabilites>' --cap mds '<capabilites>'

    # ceph-authtool --create-keyring /etc/ceph/ceph.client.admin.keyring --gen-key -n client.admin --set-uid=0 --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow'
    creating /etc/ceph/ceph.client.admin.keyring

  10. rootceph.client.admin.keyring キーを ceph.mon.keyring に追加します。

    # ceph-authtool /tmp/ceph.mon.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring
    importing contents of /etc/ceph/ceph.client.admin.keyring into /tmp/ceph.mon.keyring
  11. Monitor マップを生成します。初期 Monitor のノード名、IP アドレス、および fsid を使用して指定し、/tmp/monmap として保存します。

    構文

    $ monmaptool --create --add <monitor_host_name> <ip-address> --fsid <uuid> /tmp/monmap

    $ monmaptool --create --add node1 192.168.0.120 --fsid a7f64266-0894-4f1e-a635-d0aeaca0e993 /tmp/monmap
    monmaptool: monmap file /tmp/monmap
    monmaptool: set fsid to a7f64266-0894-4f1e-a635-d0aeaca0e993
    monmaptool: writing epoch 0 to /tmp/monmap (1 monitors)

  12. 初期モニターノードで、root としてデフォルトのデータディレクトリーを作成します。

    構文

    # mkdir /var/lib/ceph/mon/ceph-<monitor_host_name>

    # mkdir /var/lib/ceph/mon/ceph-node1

  13. root として、最初の Monitor デーモンに Monitor マップとキーリングを設定します。

    構文

    # ceph-mon --mkfs -i <monitor_host_name> --monmap /tmp/monmap --keyring /tmp/ceph.mon.keyring

    # ceph-mon --mkfs -i node1 --monmap /tmp/monmap --keyring /tmp/ceph.mon.keyring
    ceph-mon: set fsid to a7f64266-0894-4f1e-a635-d0aeaca0e993
    ceph-mon: created monfs at /var/lib/ceph/mon/ceph-node1 for mon.node1

  14. 現在の Ceph 設定ファイルを表示します。

    # cat /etc/ceph/ceph.conf
    [global]
    fsid = a7f64266-0894-4f1e-a635-d0aeaca0e993
    mon_initial_members = node1
    mon_host = 192.168.0.120

    さまざまな Ceph 構成設定に関する詳細は、Red Hat Ceph Storage 4 の 『設定ガイド』 を参照してください。Ceph 設定ファイルの例では、最も一般的な構成設定の一部を示しています。

    [global]
    fsid = <cluster-id>
    mon initial members = <monitor_host_name>[, <monitor_host_name>]
    mon host = <ip-address>[, <ip-address>]
    public network = <network>[, <network>]
    cluster network = <network>[, <network>]
    auth cluster required = cephx
    auth service required = cephx
    auth client required = cephx
    osd journal size = <n>
    osd pool default size = <n>  # Write an object n times.
    osd pool default min size = <n> # Allow writing n copy in a degraded state.
    osd pool default pg num = <n>
    osd pool default pgp num = <n>
    osd crush chooseleaf type = <n>

  15. rootとして、done ファイルを作成します。

    構文

    # touch /var/lib/ceph/mon/ceph-<monitor_host_name>/done

    # touch /var/lib/ceph/mon/ceph-node1/done

  16. root として、新しく作成されたディレクトリーおよびファイルで所有者とグループのアクセス権を更新します。

    構文

    # chown -R <owner>:<group> <path_to_directory>

    # chown -R ceph:ceph /var/lib/ceph/mon
    # chown -R ceph:ceph /var/log/ceph
    # chown -R ceph:ceph /var/run/ceph
    # chown ceph:ceph /etc/ceph/ceph.client.admin.keyring
    # chown ceph:ceph /etc/ceph/ceph.conf
    # chown ceph:ceph /etc/ceph/rbdmap

    注記

    Ceph Monitor ノードが OpenStack Controller ノードと同じ場所にある場合、Glance および Cinder キーリングファイルは、それぞれ glance および cinder によって所有されている必要があります。以下に例を示します。

    # ls -l /etc/ceph/
    ...
    -rw-------.  1 glance glance      64 <date> ceph.client.glance.keyring
    -rw-------.  1 cinder cinder      64 <date> ceph.client.cinder.keyring
    ...
  17. root として、初期モニターノードで ceph-mon プロセスを開始して有効にします。

    構文

    # systemctl enable ceph-mon.target
    # systemctl enable ceph-mon@<monitor_host_name>
    # systemctl start ceph-mon@<monitor_host_name>

    # systemctl enable ceph-mon.target
    # systemctl enable ceph-mon@node1
    # systemctl start ceph-mon@node1

  18. root として、monitor デーモンが実行していることを確認します。

    構文

    # systemctl status ceph-mon@<monitor_host_name>

    # systemctl status ceph-mon@node1
    ● ceph-mon@node1.service - Ceph cluster monitor daemon
       Loaded: loaded (/usr/lib/systemd/system/ceph-mon@.service; enabled; vendor preset: disabled)
       Active: active (running) since Wed 2018-06-27 11:31:30 PDT; 5min ago
     Main PID: 1017 (ceph-mon)
       CGroup: /system.slice/system-ceph\x2dmon.slice/ceph-mon@node1.service
               └─1017 /usr/bin/ceph-mon -f --cluster ceph --id node1 --setuser ceph --setgroup ceph
    
    Jun 27 11:31:30 node1 systemd[1]: Started Ceph cluster monitor daemon.
    Jun 27 11:31:30 node1 systemd[1]: Starting Ceph cluster monitor daemon...

Red Hat Ceph Storage Monitor をストレージクラスターに追加するには、Red Hat Ceph Storage 4 の『管理ガイド』の「モニターの追加」セクションを参照してください。

OSD ブート制約

モニターを最初に実行したら、オブジェクトストレージデバイス (OSD) の追加を開始できます。オブジェクトのコピー数を処理するのに十分な OSD があるまで、クラスターは active + clean 状態に到達できません。

オブジェクトのデフォルトのコピー数は 3 です。少なくとも 3 つの OSD ノードが必要です。ただし、オブジェクトのコピーを 2 つだけ使用する場合には、OSD ノードを 2 つだけ追加してから、Ceph 設定ファイルの osd pool default size および osd pool default min size 設定を更新します。

詳細は、Red Hat Ceph Storage 4 の『設定』「OSD 設定参照」セクションを参照してください。

初期モニターのブートストラップ後に、クラスターにはデフォルトの CRUSH マップがあります。ただし、CRUSH マップには Ceph ノードにマッピングされた Ceph OSD デーモンがありません。

OSD をクラスターに追加し、デフォルトの CRUSH マップを更新するには、各 OSD ノードで以下のコマンドを実行します。

  1. Red Hat Ceph Storage 4 OSD リポジトリーを有効にします。

    [root@osd ~]# subscription-manager repos --enable=rhceph-4-osd-for-rhel-8-x86_64-rpms
  2. root で Ceph OSD ノードに ceph-osd パッケージをインストールします。

    # yum install ceph-osd
  3. Ceph 設定ファイルと管理キーリングファイルを初期 Monitor ノードから OSD ノードにコピーします。

    構文

    # scp <user_name>@<monitor_host_name>:<path_on_remote_system> <path_to_local_file>

    # scp root@node1:/etc/ceph/ceph.conf /etc/ceph
    # scp root@node1:/etc/ceph/ceph.client.admin.keyring /etc/ceph

  4. OSD 用の Universally Unique Identifier (UUID) を生成します。

    $ uuidgen
    b367c360-b364-4b1d-8fc6-09408a9cda7a
  5. root として、OSD インスタンスを作成します。

    構文

    # ceph osd create <uuid> [<osd_id>]

    # ceph osd create b367c360-b364-4b1d-8fc6-09408a9cda7a
    0

    注記

    このコマンドは、後続のステップに必要な OSD 番号識別子を出力します。

  6. root として、新規 OSD のデフォルトディレクトリーを作成します。

    構文

    # mkdir /var/lib/ceph/osd/ceph-<osd_id>

    # mkdir /var/lib/ceph/osd/ceph-0

  7. root として、OSD として使用するドライブを準備し、作成したディレクトリーにマウントします。Ceph データおよびジャーナル用にパーティションを作成します。ジャーナルとデータパーティションは同じディスクに配置できます。以下の例では、15 GB のディスクを使用しています。

    構文

    # parted <path_to_disk> mklabel gpt
    # parted <path_to_disk> mkpart primary 1 10000
    # mkfs -t <fstype> <path_to_partition>
    # mount -o noatime <path_to_partition> /var/lib/ceph/osd/ceph-<osd_id>
    # echo "<path_to_partition>  /var/lib/ceph/osd/ceph-<osd_id>   xfs defaults,noatime 1 2" >> /etc/fstab

    # parted /dev/sdb mklabel gpt
    # parted /dev/sdb mkpart primary 1 10000
    # parted /dev/sdb mkpart primary 10001 15000
    # mkfs -t xfs /dev/sdb1
    # mount -o noatime /dev/sdb1 /var/lib/ceph/osd/ceph-0
    # echo "/dev/sdb1 /var/lib/ceph/osd/ceph-0  xfs defaults,noatime 1 2" >> /etc/fstab

  8. root として、OSD データディレクトリーを初期化します。

    構文

    # ceph-osd -i <osd_id> --mkfs --mkkey --osd-uuid <uuid>

    # ceph-osd -i 0 --mkfs --mkkey --osd-uuid b367c360-b364-4b1d-8fc6-09408a9cda7a
    ... auth: error reading file: /var/lib/ceph/osd/ceph-0/keyring: can't open /var/lib/ceph/osd/ceph-0/keyring: (2) No such file or directory
    ... created new key in keyring /var/lib/ceph/osd/ceph-0/keyring

  9. root として、OSD 認証キーを登録します。

    構文

    # ceph auth add osd.<osd_id> osd 'allow *' mon 'allow profile osd' -i /var/lib/ceph/osd/ceph-<osd_id>/keyring

    # ceph auth add osd.0 osd 'allow *' mon 'allow profile osd' -i /var/lib/ceph/osd/ceph-0/keyring
    added key for osd.0

  10. root として、OSD ノードを CRUSH マップに追加します。

    構文

    # ceph osd crush add-bucket <host_name> host

    # ceph osd crush add-bucket node2 host

  11. root で OSD ノードを default の CRUSH ツリーに配置します。

    構文

    # ceph osd crush move <host_name> root=default

    # ceph osd crush move node2 root=default

  12. root として、OSD ディスクを CRUSH マップに追加します。

    構文

    # ceph osd crush add osd.<osd_id> <weight> [<bucket_type>=<bucket-name> ...]

    # ceph osd crush add osd.0 1.0 host=node2
    add item id 0 name 'osd.0' weight 1 at location {host=node2} to crush map

    注記

    CRUSH マップをデコンパイルし、OSD をデバイス一覧に追加することもできます。OSD ノードをバケットとして追加してから、デバイスを OSD ノードの項目として追加し、OSD に重みを割り当て、CRUSH マップを再コンパイルし、CRUSH マップを設定します。詳細は、Red Hat Ceph Storage 4 の『ストレージ戦略ガイド』のセクション「CRUSH マップの編集」を参照してください。

  13. root として、新しく作成されたディレクトリーおよびファイルで所有者とグループのアクセス権を更新します。

    構文

    # chown -R <owner>:<group> <path_to_directory>

    # chown -R ceph:ceph /var/lib/ceph/osd
    # chown -R ceph:ceph /var/log/ceph
    # chown -R ceph:ceph /var/run/ceph
    # chown -R ceph:ceph /etc/ceph

  14. OSD ノードは Ceph Storage クラスターの設定にあります。ただし、OSD デーモンは down および in です。新しい OSD は、データの受信開始前に up である必要があります。root として、OSD プロセスを有効にして開始します。

    構文

    # systemctl enable ceph-osd.target
    # systemctl enable ceph-osd@<osd_id>
    # systemctl start ceph-osd@<osd_id>

    # systemctl enable ceph-osd.target
    # systemctl enable ceph-osd@0
    # systemctl start ceph-osd@0

    OSD デーモンを起動すると、これが up および in になります。

モニターと一部の OSD が稼働しています。以下のコマンドを実行して、配置グループピアを監視できます。

$ ceph -w

OSD ツリーを表示するには、以下のコマンドを実行します。

$ ceph osd tree

ID  WEIGHT    TYPE NAME        UP/DOWN  REWEIGHT  PRIMARY-AFFINITY
-1       2    root default
-2       2        host node2
 0       1            osd.0         up         1                 1
-3       1        host node3
 1       1            osd.1         up         1                 1

OSD をストレージクラスターに追加してストレージ容量を拡張するには、Red Hat Ceph Storage 4 『管理ガイド』「OSD の追加」セクションを参照してください。

B.3. Ceph Manager の手動インストール

通常、Ansible 自動化ユーティリティーは、Red Hat Ceph Storage クラスターをデプロイする際に Ceph Manager デーモン (ceph-mgr) をインストールします。ただし、Ansible を使用して Red Hat Ceph Storage を管理しない場合は、Ceph Manager を手動でインストールすることができます。Red Hat は、Ceph Manager デーモンと Ceph Monitor デーモンを同じノードに配置することを推奨します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • root または sudo アクセス
  • rhceph-4-mon-for-rhel-8-x86_64-rpms リポジトリーが有効になっている
  • ファイアウォールを使用している場合は、パブリックネットワーク上でポート 6800-7300 を開く

手順

ceph-mgr がデプロイされるノードで、root ユーザーまたは sudo ユーティリティーで以下のコマンドを使用します。

  1. ceph-mgr パッケージをインストールします。

    [root@node1 ~]# yum install ceph-mgr
  2. /var/lib/ceph/mgr/ceph-hostname/ ディレクトリーを作成します。

    mkdir /var/lib/ceph/mgr/ceph-hostname

    hostname を、ceph-mgr デーモンがデプロイされるノードのホスト名に置き換えます。以下に例を示します。

    [root@node1 ~]# mkdir /var/lib/ceph/mgr/ceph-node1
  3. 新しく作成されたディレクトリーで、ceph-mgr デーモンの認証キーを作成します。

    [root@node1 ~]# ceph auth get-or-create mgr.`hostname -s` mon 'allow profile mgr' osd 'allow *' mds 'allow *' -o /var/lib/ceph/mgr/ceph-node1/keyring
  4. /var/lib/ceph/mgr/ ディレクトリーの所有者とグループを ceph:ceph に変更します。

    [root@node1 ~]# chown -R ceph:ceph /var/lib/ceph/mgr
  5. ceph-mgr ターゲットを有効にします。

    [root@node1 ~]# systemctl enable ceph-mgr.target
  6. ceph-mgr インスタンスを有効にして開始します。

    systemctl enable ceph-mgr@hostname
    systemctl start ceph-mgr@hostname

    hostname を、ceph-mgr をデプロイするノードのホスト名に置き換えます。以下に例を示します。

    [root@node1 ~]# systemctl enable ceph-mgr@node1
    [root@node1 ~]# systemctl start ceph-mgr@node1
  7. ceph-mgr デーモンが正常に起動していることを確認します。

    ceph -s

    出力には、services: セクションの下に以下の行と同様の行が含まれます。

        mgr: node1(active)
  8. 追加の ceph-mgr デーモンをインストールして、現在のアクティブなデーモンに障害が発生した場合にアクティブになるスタンバイデーモンとして機能します。

B.4. Ceph ブロックデバイスの手動インストール

以下の手順では、シンプロビジョニングされ、サイズが変更可能な Ceph ブロックデバイスをインストールおよびマウントする方法を説明します。

重要

Ceph ブロックデバイスは、Ceph Monitor ノードと OSD ノードとは別のノードにデプロイする必要があります。同じノードでカーネルクライアントとカーネルサーバーデーモンを実行すると、カーネルのデッドロックが発生する可能性があります。

前提条件

手順

  1. OSD ノード (osd 'allow rwx') 上のファイルへの完全なパーミッションを持つ client.rbd という名前の Ceph Block Device ユーザーを作成し、結果をキーリングファイルに出力します。

    ceph auth get-or-create client.rbd mon 'profile rbd' osd 'profile rbd pool=<pool_name>' \
    -o /etc/ceph/rbd.keyring

    <pool_name> を、client.rbd によるアクセスを許可するプールの名前 (例: rbd) に置き換えます。

    # ceph auth get-or-create \
    client.rbd mon 'allow r' osd 'allow rwx pool=rbd' \
    -o /etc/ceph/rbd.keyring

    ユーザーの作成に関する詳細は、Red Hat Ceph Storage 4 『管理ガイド』「ユーザー管理」セクションを参照してください。

  2. ブロックデバイスイメージを作成します。

    rbd create <image_name> --size <image_size> --pool <pool_name> \
    --name client.rbd --keyring /etc/ceph/rbd.keyring

    <image_name><image_size>、および <pool_name> を指定します。以下に例を示します。

    $ rbd create image1 --size 4G --pool rbd \
    --name client.rbd --keyring /etc/ceph/rbd.keyring
    警告

    デフォルトの Ceph 設定には、以下の Ceph ブロックデバイス機能が含まれます。

    • layering
    • exclusive-lock
    • object-map
    • deep-flatten
    • fast-diff

    カーネル RBD (krbd) クライアントを使用する場合は、ブロックデバイスイメージをマッピングできない可能性があります。

    この問題を回避するには、サポートされていない機能を無効にします。これを行うには、以下のいずれかのオプションを使用します。

    • サポートされていない機能を動的に無効にします。

      rbd feature disable <image_name> <feature_name>

      以下に例を示します。

      # rbd feature disable image1 object-map deep-flatten fast-diff
    • rbd create コマンドで --image-feature layering オプションを使用して、新たに作成されたブロックデバイスイメージで 階層化 のみを有効にします。
    • Ceph 設定ファイルで機能のデフォルトを無効にします。

      rbd_default_features = 1

    これは既知の問題です。詳細は、Red Hat Ceph Storage 4 の『リリースノート』「既知の問題」の章を参照してください。

    これらの機能はすべて、ユーザー空間の RBD クライアントを使用してブロックデバイスイメージにアクセスするユーザーに機能します。

  3. 新規に作成されたイメージをブロックデバイスにマッピングします。

    rbd map <image_name> --pool <pool_name>\
    --name client.rbd --keyring /etc/ceph/rbd.keyring

    以下に例を示します。

    # rbd map image1 --pool rbd --name client.rbd \
    --keyring /etc/ceph/rbd.keyring
  4. ファイルシステムを作成してブロックデバイスを使用します。

    mkfs.ext4 /dev/rbd/<pool_name>/<image_name>

    以下のように、プール名とイメージ名を指定します。

    # mkfs.ext4 /dev/rbd/rbd/image1

    このアクションには少し時間がかかる場合があります。

  5. 新しく作成されたファイルシステムをマウントします。

    mkdir <mount_directory>
    mount /dev/rbd/<pool_name>/<image_name> <mount_directory>

    以下に例を示します。

    # mkdir /mnt/ceph-block-device
    # mount /dev/rbd/rbd/image1 /mnt/ceph-block-device

関連情報

B.5. Ceph Object Gateway の手動インストール

Ceph オブジェクトゲートウェイは RADOS ゲートウェイとしても知られている librados API 上に構築されたオブジェクトストレージインターフェースで、RESTful ゲートウェイを Ceph ストレージクラスターに提供します。

前提条件

手順

  1. Red Hat Ceph Storage 4 Tools リポジトリーを有効にします。

    [root@gateway ~]# subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-debug-rpms
  2. Object Gateway ノードで、ceph-radosgw パッケージをインストールします。

    # yum install ceph-radosgw
  3. 初期モニターノードで、以下の手順を実施します。

    1. 以下のように Ceph 設定ファイルを更新します。

      [client.rgw.<obj_gw_hostname>]
      host = <obj_gw_hostname>
      rgw frontends = "civetweb port=80"
      rgw dns name = <obj_gw_hostname>.example.com

      ここで、<obj_gw_hostname> はゲートウェイノードの短縮ホスト名です。短縮ホスト名を表示するには、hostname -s コマンドを使用します。

    2. 更新された設定ファイルを新しい Object Gateway ノードおよび Ceph Storage クラスターのその他のノードにコピーします。

      構文

      # scp /etc/ceph/ceph.conf <user_name>@<target_host_name>:/etc/ceph

      # scp /etc/ceph/ceph.conf root@node1:/etc/ceph/

    3. ceph.client.admin.keyring ファイルを新しい Object Gateway ノードにコピーします。

      構文

      # scp /etc/ceph/ceph.client.admin.keyring <user_name>@<target_host_name>:/etc/ceph/

      # scp /etc/ceph/ceph.client.admin.keyring root@node1:/etc/ceph/

  4. Object Gateway ノードで、データディレクトリーを作成します。

    # mkdir -p /var/lib/ceph/radosgw/ceph-rgw.`hostname -s`
  5. Object Gateway ノードで、ユーザーとキーリングを追加して、オブジェクトゲートウェイをブートストラップします。

    構文

    # ceph auth get-or-create client.rgw.`hostname -s` osd 'allow rwx' mon 'allow rw' -o /var/lib/ceph/radosgw/ceph-rgw.`hostname -s`/keyring

    # ceph auth get-or-create client.rgw.`hostname -s` osd 'allow rwx' mon 'allow rw' -o /var/lib/ceph/radosgw/ceph-rgw.`hostname -s`/keyring

    重要

    ゲートウェイキーの機能を提供する場合は、読み取り機能を指定する必要があります。ただし、Monitor 書き込み機能を提供することはオプションです。指定した場合、Ceph Object Gateway はプールを自動的に作成できます。

    このような場合は、プール内の配置グループの数に適切な数を指定してください。そうでない場合には、ゲートウェイはデフォルトの番号を使用しますが、これはニーズに適しているとは 限りません。詳細は、「Ceph Placement Groups (PGs) per Pool Calculator」を参照してください。

  6. Object Gateway ノードで、done ファイルを作成します。

    # touch /var/lib/ceph/radosgw/ceph-rgw.`hostname -s`/done
  7. Object Gateway ノードで、所有者およびグループのパーミッションを変更します。

    # chown -R ceph:ceph /var/lib/ceph/radosgw
    # chown -R ceph:ceph /var/log/ceph
    # chown -R ceph:ceph /var/run/ceph
    # chown -R ceph:ceph /etc/ceph
  8. Object Gateway ノードで、TCP ポート 8080 を開きます。

    # firewall-cmd --zone=public --add-port=8080/tcp
    # firewall-cmd --zone=public --add-port=8080/tcp --permanent
  9. Object Gateway ノードで、ceph-radosgw プロセスを開始して有効にします。

    構文

    # systemctl enable ceph-radosgw.target
    # systemctl enable ceph-radosgw@rgw.<rgw_hostname>
    # systemctl start ceph-radosgw@rgw.<rgw_hostname>

    # systemctl enable ceph-radosgw.target
    # systemctl enable ceph-radosgw@rgw.node1
    # systemctl start ceph-radosgw@rgw.node1

インストールが完了すると、書き込み機能が Monitor に設定されると、Ceph Object Gateway はプールを自動的に作成します。プールの手動作成に関する詳細は、『ストラテジー戦略ガイド』の「プール」の章を参照してください。

関連情報

付録C Ceph のデフォルト設定の上書き

Ansible 設定ファイルに特に指定しない限り、Ceph はデフォルト設定を使用します。

Ansible は Ceph 設定ファイルを管理するため、/usr/share/ceph-ansible/group_vars/all.yml ファイルを編集して Ceph の設定を変更します。ceph_conf_overrides の設定を使用して、デフォルトの Ceph 設定を上書きします。

Ansible は、Ceph 設定ファイル ([global][mon][osd][mds][rgw] など) と同じセクションをサポートします。特定の Ceph Object Gateway インスタンスなどの特定のインスタンスをオーバーライドすることもできます。以下に例を示します。

###################
# CONFIG OVERRIDE #
###################

ceph_conf_overrides:
   client.rgw.rgw1:
      log_file: /var/log/ceph/ceph-rgw-rgw1.log
注記

Ansible には、Ceph 設定ファイルの特定セクションを参照する際に中かっこが含まれません。セクション名および設定名はコロンで終了します。

重要

CONFIG OVERRIDE セクションの cluster_network パラメーターを使用してクラスターネットワークを設定しないでください。競合する 2 つのクラスターネットワークが Ceph 設定ファイルに設定されている可能性があるためです。

クラスターネットワークを設定するには、CEPH CONFIGURATION セクションで cluster_network パラメーターを使用します。詳細は、『Red Hat Ceph Storage インストールガイド』「Red Hat Ceph Storage クラスターのインストール」を参照してください。

付録D 既存の Ceph クラスターの Ansible へのインポート

Ansible が Ansible なしでデプロイされたクラスターを使用するように設定することができます。たとえば、Red Hat Ceph Storage 1.3 クラスターを手動でバージョン 2 にアップグレードした場合は、以下の手順により Ansible を使用するように設定してください。

  1. バージョン 1.3 からバージョン 2 に手動でアップグレードした後、管理ノードに Ansible をインストールおよび設定します。
  2. Ansible 管理ノードに、クラスター内の全 Ceph ノードにパスワードレスの ssh アクセスがあることを確認します。詳細は 「Ansible のパスワードなし SSH の有効化」 を参照してください。
  3. root で、/etc/ansible/ ディレクトリーに Ansible の group_vars ディレクトリーへのシンボリックリンクを作成します。

    # ln -s /usr/share/ceph-ansible/group_vars /etc/ansible/group_vars
  4. rootall.yml.sample ファイルから all.yml ファイルを作成し、編集用に開きます。

    # cd /etc/ansible/group_vars
    # cp all.yml.sample all.yml
    # vim all.yml
  5. group_vars/all.ymlgenerate_fsid 設定を false に設定します。
  6. ceph fsid を実行して、現在のクラスター fsid を取得します。
  7. 取得した fsidgroup_vars/all.yml に設定します。
  8. Ceph ホストが含まれるように、/etc/ansible/hosts の Ansible インベントリーを変更します。[mons] セクションの下にモニター、[osds] セクションの下に OSD、および[rgws] セクションのゲートウェイを追加して、それらのロールをAnsible に特定します。
  9. ceph_conf_overrides セクションが、all.yml ファイルの [global] セクション、[osd] セクション、[mon] セクション、および [client] セクションに使用される元の ceph.conf オプションで更新されていることを確認します。

    osd ジャーナルpublic_networkcluster_network などのオプションはすでに all.yml に含まれているため、ceph_conf_overrides には追加しないでください。all.yml に含まれず、元の ceph.conf にあるオプションのみを ceph_conf_overrides に追加する必要があります。

  10. /usr/share/ceph-ansible/ ディレクトリーから Playbook を実行します。

    # cd /usr/share/ceph-ansible/
    # ansible-playbook infrastructure-playbooks/take-over-existing-cluster.yml -u <username> -i hosts

付録E Ansible によってデプロイされたストレージクラスターのパージ

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

警告

Ceph ストレージクラスターをパージすると、OSD のデータはすべて永続的に失われます。

前提条件

  • Ansible 管理ノードへのルートレベルのアクセス。
  • ansible ユーザーアカウントへのアクセス。
  • ベアメタル デプロイメントの場合:

    • /usr/share/ceph-ansible/group-vars/osds.yml ファイルの osd_auto_discovery オプションが true に設定されている場合、Ansible はストレージクラスターのパージに失敗します。したがって、osd_auto_discovery をコメントアウトし、osds.yml ファイルで OSD デバイスを宣言します。
  • /var/log/ansible/ansible.log ファイルが ansible ユーザーアカウントで書き込み可能であることを確認してください。

手順

  1. /usr/share/ceph-ansible ディレクトリーに移動します。

    [root@admin ~]# cd /usr/share/ceph-ansible
  2. ansible ユーザーとして、purge Playbook を実行します。

    1. ベアメタル デプロイメントの場合は、purge-cluster.yml Playbook を使用して Ceph ストレージクラスターをパージします。

      [ansible@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/purge-cluster.yml
    2. コンテナー デプロイメントの場合:

      1. Playbook purge-docker-cluster.yml を使用して Ceph ストレージクラスターをパージします。

        [ansible@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/purge-docker-cluster.yml
        注記

        この Playbook により、パッケージ、コンテナー、設定ファイル、および Ceph Ansible Playbook により作成されたすべてのデータが削除されます。

      2. デフォルトの (/etc/ansible/hosts )以外のインベントリーファイルを指定するには、-i パラメーターを使用します。

        構文

        [ansible@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/purge-docker-cluster.yml -i INVENTORY_FILE

        置き換え

        INVENTORY_FILE は、インベントリーファイルへのパスに置き換えます。

        [ansible@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/purge-docker-cluster.yml -i ~/ansible/hosts

      3. Ceph コンテナーイメージの削除を省略するには、--skip-tags=”remove_img” オプションを使用します。

        [ansible@admin ceph-ansible]$ ansible-playbook --skip-tags="remove_img" infrastructure-playbooks/purge-docker-cluster.yml
      4. インストール時にインストールしたパッケージの削除を省略するには、--skip-tags=”with_pkg” オプションを使用します。

        [ansible@admin ceph-ansible]$ ansible-playbook --skip-tags="with_pkg" infrastructure-playbooks/purge-docker-cluster.yml

関連情報

付録F Ansible の全般的な設定

これは最も一般的な設定可能な Ansible パラメーターです。ベアメタルまたはコンテナーのデプロイメント方法に応じて、2 つのパラメーターセットを使用できます。

注記

これは、利用可能なすべての Ansible パラメーターの完全なリストではありません。

ベアメタル および コンテナー の設定

monitor_interface

Ceph Monitor ノードがリッスンするインターフェース。

ユーザー定義
必須
はい
注記
1 つ以上の monitor_* パラメーターに値を割り当てる必要があります。
monitor_address

Ceph Monitor ノードもリッスンするアドレス。

ユーザー定義
必須
はい
注記
1 つ以上の monitor_* パラメーターに値を割り当てる必要があります。
monitor_address_block

Ceph パブリックネットワークのサブネット。

ユーザー定義
必須
はい
注記
ノードの IP アドレスが不明ではあるが、サブネットが既知である場合に使用します。1 つ以上の monitor_* パラメーターに値を割り当てる必要があります。
ip_version
ipv6
必須
IPv6 アドレス指定を使用している場合は必須です。
public_network

IPv6 を使用する場合には、Ceph パブリックネットワークの IP アドレスとネットマスク、または対応する IPv6 アドレス。

ユーザー定義
必須
はい
注記
詳細は、Red Hat Ceph Storage のネットワーク設定の確認を参照してください。
cluster_network

IPv6 を使用する場合には、Ceph クラスターネットワークの IP アドレスとネットマスク、または対応する IPv6 アドレス。

ユーザー定義
必須
いいえ
注記
詳細は、Red Hat Ceph Storage のネットワーク設定の確認を参照してください。
configure_firewall

Ansible は適切なファイアウォールルールの設定を試みます。

true または false
必須
いいえ

ベアメタル 固有の設定

ceph_origin
repository または distro または local
必須
はい
注記
repository 値は、新しいリポジトリーで Ceph をインストールすることを意味します。distro の値は、個別のリポジトリーファイルが追加されず、Linux ディストリビューションに含まれる Ceph のバージョンをすべて取得することを意味します。local の値は、Ceph バイナリーがローカルマシンからコピーされることを意味します。
ceph_repository_type
cdn または iso
必須
はい
ceph_rhcs_version
4
必須
はい
ceph_rhcs_iso_path

ISO イメージの完全パス。

ユーザー定義
必須
はい (ceph_repository_typeiso 設定されている場合)

コンテナー 固有の設定

ceph_docker_image
ローカルの Docker レジストリーを使用している場合には rhceph/rhceph-4-rhel8 または cephimageinlocalreg
必須
はい
containerized_deployment
true
必須
はい
ceph_docker_registry
ローカルの Docker レジストリーを使用している場合は、registry.redhat.io、または LOCAL_FQDN_NODE_NAME
必須
はい

付録G OSD Ansible の設定

これらは、設定可能な OSD Ansible パラメーターの最も一般的なものです。

devices

Ceph のデータが保存されるデバイスの一覧。

ユーザー定義
必須
デバイスの一覧を指定する場合は、はい。
注記
osd_auto_discovery 設定を使用する場合は使用できません。devices オプションを使用する場合は、ceph-volume lvm batch モードにより、最適化 OSD 設定が作成されます。
dmcrypt

OSD を暗号化するには。

true
必須
いいえ
注記
デフォルト値は false です。
lvm_volumes

FileStore または BlueStore ディクショナリーの一覧。

ユーザー定義
必須
はい (ストレージデバイスが devices パラメーターで定義されていない場合)。
注記
各ディクショナリーには、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
必須
いいえ
注記
デフォルト値は bluestore です。アップグレードに必要です。

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.