Menu Close

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

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

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

重要

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」を参照してください。

      注記

      ceph_docker_registry_username および ceph_docker_registry_password パラメータにサービスアカウントを使用するだけでなく、カスタマーポータルの認証情報を使用することもできますが、ceph_docker_registry_password パラメータを暗号化してセキュリティーを確保してください。詳細は、「ansible-vault で Ansible のパスワード変数を暗号化する」を参照してください。

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

        fetch_directory: ~/ceph-ansible-keys
        ceph_origin: repository
        ceph_repository: rhcs
        ceph_repository_type: cdn
        ceph_rhcs_version: 4
        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.6
        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.6
        alertmanager_container_image: registry.redhat.io/openshift4/ose-prometheus-alertmanager:4.6
        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 のカスタムユーザー名も設定します。

        注記

        Red Hat Ceph Storage 4.2 で、インストールにローカルレジストリーを使用している場合は、Prometheus のイメージタグとして 4.6 を使用します。

      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
        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.6
        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.6
        alertmanager_container_image: registry.redhat.io/openshift4/ose-prometheus-alertmanager:4.6
        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
        ceph_docker_image_tag: latest
        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
        dashboard_admin_user:
        dashboard_admin_password:
        node_exporter_container_image: registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.6
        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.6
        alertmanager_container_image: registry.redhat.io/openshift4/ose-prometheus-alertmanager:4.6
        1
        これは、パブリックネットワーク上のインターフェースです。
        重要

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

        注記

        http または https プロキシーで到達可能なコンテナーレジストリーを使用する場合は、group_vars/all.yml ファイルで ceph_docker_http_proxy または ceph_docker_https_proxy 変数を設定する必要があります。

        ceph_docker_http_proxy: http://192.168.42.100:8080
        ceph_docker_https_proxy: https://192.168.42.100:8080

        プロキシー設定で一部のホストを除外する必要がある場合は、group_vars/all.yml ファイルで ceph_docker_no_proxy 変数を使用できます。

        ceph_docker_no_proxy: "localhost,127.0.0.1"
      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
        ceph_docker_image_tag: latest
        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
        dashboard_admin_user:
        dashboard_admin_password:
        node_exporter_container_image: LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-node-exporter:v4.6
        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.6
        alertmanager_container_image: LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-alertmanager:4.6
        1
        これは、パブリックネットワーク上のインターフェースです。
        置き換え
        • LOCAL_NODE_FQDN を、ローカルホストの FQDN に置き換えます。
      5. Red Hat Ceph Storage 4.2からは、dashboard_protocolhttps に設定されており、Ansible でダッシュボードと grafana の鍵と証明書が生成されます。ベアメタル または コンテナー デプロイメントでカスタム証明書の場合には、all.yml ファイルで、dashboard_crtdashboard_keygrafana_crtgrafana_key のAnsible インストーラーホストのパスを更新します。

        構文

        dashboard_protocol: https
        dashboard_port: 8443
        dashboard_crt: 'DASHBOARD_CERTIFICATE_PATH'
        dashboard_key: 'DASHBOARD_KEY_PATH'
        dashboard_tls_external: false
        dashboard_grafana_api_no_ssl_verify: "{{ True if dashboard_protocol == 'https' and not grafana_crt and not grafana_key else False }}"
        grafana_crt: 'GRAFANA_CERTIFICATE_PATH'
        grafana_key: 'GRAFANA_KEY_PATH'

    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 ツールは、空のデバイスを確認するため、空ではないデバイスは使用されません。

        注記

        後で purge-docker-cluster.yml または purge-cluster.yml を使用してクラスターを削除する場合は、osd_auto_discovery をコメントアウトし、osds.yml ファイルで OSD デバイスを宣言する必要があります。詳細については、Ansible によってデプロイされたストレージクラスターのパージ を参照してください。

      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 ディレクトリーに変更します。

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

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

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

        devices:
            DEVICE_1
            DEVICE_2

        devices:
            /dev/sdb
            /dev/sdc

        注記

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

  8. オプションで、ベアメタルまたはコンテナー内のすべてのデプロイメントで、Ceph Ansible を使用してカスタム CRUSH 階層を作成できます。

    1. Ansible のインベントリーファイルを設定します。osd_crush_location パラメーターを使用して、OSD ホストを CRUSH マップの階層内のどこに配置するかを指定します。OSD の場所を指定するために、2 つ以上の CRUSH バケットタイプを指定し、1 つのバケットの type をホストに指定する必要があります。デフォルトでは、これには、rootdatacenterroomrowpodpdurackchassis および host が含まれます。

      構文

      [osds]
      CEPH_OSD_NAME osd_crush_location="{ 'root': ROOT_BUCKET_', 'rack': 'RACK_BUCKET', 'pod': 'POD_BUCKET', 'host': 'CEPH_HOST_NAME' }"

      [osds]
      ceph-osd-01 osd_crush_location="{ 'root': 'default', 'rack': 'rack1', 'pod': 'monpod', 'host': 'ceph-osd-01' }"

    2. group_vars/osds.yml ファイルを編集し、crush_rule_config パラメーターと create_crush_tree パラメーターを True に設定します。デフォルトの CRUSH ルールを使用しない場合は、少なくとも 1 つの CRUSH ルールを作成します。次に例を示します。

      crush_rule_config: True
      crush_rule_hdd:
          name: replicated_hdd_rule
          root: root-hdd
          type: host
          class: hdd
          default: True
      crush_rules:
        - "{{ crush_rule_hdd }}"
      create_crush_tree: True

      より高速な SSD デバイスを使用している場合は、次のようにパラメーターを編集します。

      crush_rule_config: True
      crush_rule_ssd:
          name: replicated_ssd_rule
          root: root-ssd
          type: host
          class: ssd
          default: True
      crush_rules:
        - "{{ crush_rule_ssd }}"
      create_crush_tree: True
      注記

      ssdhdd の両方の OSD がデプロイされていない場合、デフォルトの CRUSH ルールは失敗します。これは、デフォルトのルールに、定義する必要のある class パラメーターが含まれているためです。

    3. group_vars/clients.yml ファイルで作成した crush_rules を使用して pools を作成します。

      copy_admin_key: True
      user_config: True
      pool1:
        name: "pool1"
        pg_num: 128
        pgp_num: 128
        rule_name: "HDD"
        type: "replicated"
        device_class: "hdd"
      pools:
        - "{{ pool1 }}"

    4. ツリーを表示します。

      [root@mon ~]# ceph osd tree
    5. プールを検証します。

      [root@mon ~]# for i in $(rados lspools); do echo "pool: $i"; ceph osd pool get $i crush_rule; done
      
      pool: pool1
      crush_rule: HDD
  9. すべてのデプロイメント (ベアメタル または コンテナー 内) では、ログインするか、ansible ユーザーに切り替えます。

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

      [ansible@admin ~]$ mkdir ~/ceph-ansible-keys
    2. /usr/share/ceph-ansible/ ディレクトリーに移動します。

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

      [ansible@admin ceph-ansible]$ ansible all -m ping -i hosts
  10. 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 に渡される数を減らします。

  11. Ceph デプロイメントが完了するまで待ちます。

    出力例

    INSTALLER STATUS *******************************
    Install Ceph Monitor           : Complete (0:00:30)
    Install Ceph Manager           : Complete (0:00:47)
    Install Ceph OSD               : Complete (0:00:58)
    Install Ceph RGW               : Complete (0:00:34)
    Install Ceph Dashboard         : Complete (0:00:58)
    Install Ceph Grafana           : Complete (0:00:50)
    Install Ceph Node Exporter     : Complete (0:01:14)
  12. 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

  13. ベアメタル または コンテナー 内のすべてのデプロイメントについて、ストレージクラスターが 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 クラスターの検証」の章を参照してください。

関連情報