ブロックデバイスガイド

Red Hat Ceph Storage 4

Red Hat Ceph Storage Block Device の管理、作成、設定、および使用

Red Hat Ceph Storage Documentation Team

概要

本書では、Red Hat Ceph Storage Block Device を管理、作成、設定し、使用する方法を説明します。

第1章 Ceph ブロックデバイスの概要

ブロックは、データの 512 バイトブロックなど、順序で設定されたバイト数です。多くのブロックを 1 つのファイルに統合して、読み書きできるストレージデバイスとして使用できます。ブロックベースのストレージインターフェースは、次のようなローテートメディアでデータを格納する最も一般的な方法です。

  • ハードドライブ
  • CD/DVD ディスク
  • フロッピーディスク
  • 従来の 9 追跡テープ

ブロックデバイスインターフェースの ubiquity により、仮想ブロックデバイスは、Red Hat Ceph Storage などの大容量のデータストレージシステムと対話するのに理想的な要素となります。

Ceph ブロックデバイスは、シンプロビジョニングされ、再設定可能で、Ceph ストレージクラスター内の複数の Object Storage Devices(OSD)にストライプ化されたデータを保管します。Ceph ブロックデバイスは、Reliable Autonomic Distributed Object Store(RADOS)Block Devices(RBD)としても知られています。Ceph ブロックデバイスは、以下のような RADOS 機能を活用します。

  • snapshots
  • レプリケーション
  • データの一貫性

Ceph ブロックデバイスは、librbd ライブラリーを使用して OSD と対話します。

Ceph ブロックデバイスは、Quick Emulator(QEMU)などの Kernel Virtual Machines(KVM)や OpenStack などのクラウドベースのコンピューティングシステムに、libvirt ユーティリティーや QEMU ユーティリティーに依存して Ceph ブロックデバイスと統合する、カーネル仮想マシン(KVM)への無限のスケーラビリティーで高パフォーマンスを提供します。同じストレージクラスターを使用して、Ceph Object Gateway および Ceph ブロックデバイスを同時に操作することができます。

重要

Ceph ブロックデバイスを使用するには、実行中の Ceph Storage クラスターにアクセスできる必要があります。Red Hat Ceph Storage クラスターのインストールに関する詳細は、『 Red Hat Ceph Storage Installation Guide』を参照してください

第2章 Ceph ブロックデバイスコマンド

Ceph のブロックデバイスコマンドに精通しているストレージ管理者は、Red Hat Ceph Storage クラスターを効果的に管理することができます。Ceph ブロックデバイスのさまざまな機能を有効化/無効化すると共に、ブロックデバイスプールおよびイメージを作成して管理することができます。

2.1. 前提条件

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

2.2. コマンドヘルプの表示

コマンドラインインターフェースからコマンドおよびサブコマンドのオンラインヘルプを表示します。

注記

-h オプションを指定すると、すべてのコマンドのヘルプが表示されます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. rbd help コマンドを使用して、特定の rbd コマンドとそのサブコマンドのヘルプを表示します。

    rbd help COMMAND SUBCOMMAND
  2. snap list コマンドのヘルプを表示するには、次のコマンドを実行します。

    [root@rbd-client ~]# rbd help snap list

2.3. ブロックデバイスプールの作成

ブロックデバイスクライアントを使用する前に、rbd のプールが存在することを確認し、有効化して初期化します。

注記

MUST 、最初にプールを作成し、これをソースとして指定します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. rbd プールを作成するには、以下のコマンドを実行します。

    構文

    ceph osd pool create POOL_NAME PG_NUM PGP_NUM
    ceph osd pool application enable POOL_NAME rbd
    rbd pool init -p POOL_NAME

その他のリソース

  • 詳細は、『Red Hat Ceph Storage Storage Strategies Guide』の「 Pools 」の章を参照してください。

2.4. ブロックデバイスイメージの作成

ブロックデバイスをノードに追加する前に、Ceph ストレージクラスター内にそのブロックデバイスのイメージを作成します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. ブロックデバイスイメージを作成するには、以下のコマンドを実行します。

    構文

    rbd create IMAGE_NAME --size MEGABYTES --pool POOL_NAME

    [root@client ~]# rbd create data --size 1024 --pool stack

    この例では、stack という名前のプールに情報を格納する データ という名前の 1 GB イメージを作成します。

    注記

    イメージを作成する前に、プールが存在することを確認してください。

その他のリソース

  • 詳細は、『 Red Hat Ceph Storage Block Device Guide』 の「 Creating a block device pool 」セクションを参照してください。

2.5. ブロックデバイスイメージの一覧表示

ブロックデバイスイメージを一覧表示します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. rbd プールのブロックデバイスを一覧表示するには、以下のコマンドを実行します(rbd はデフォルトのプール名です)。

    [root@rbd-client ~]# rbd ls
  2. 特定のプールのブロックデバイスを一覧表示するには、以下のコマンドを実行しますが、POOL_NAME はプールの名前に置き換えます。

    構文

    rbd ls POOL_NAME

    [root@rbd-client ~]# rbd ls swimmingpool

2.6. ブロックデバイスイメージ情報の取得

ブロックデバイスイメージに関する情報を取得します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. 特定のイメージから情報を取得するには、以下を実行しますが、IMAGE_NAME をイメージの名前に置き換えます。

    構文

    rbd --image IMAGE_NAME info

    [root@rbd-client ~]# rbd --image foo info

  2. プール内のイメージから情報を取得するには、以下を実行しますが、IMAGE_NAME をイメージの名前に置き換え、POOL_NAME をプールの名前に置き換えます。

    構文

    rbd --image IMAGE_NAME -p POOL_NAME info

    [root@rbd-client ~]# rbd --image bar -p swimmingpool info

2.7. ブロックデバイスイメージのサイズ変更

Ceph ブロックデバイスイメージはシンプロビジョニングされています。データの保存を開始する前に、物理ストレージは実際には使用されません。ただし、--size オプションで設定する最大容量があります。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. Ceph ブロックデバイスイメージの最大サイズを増減するには、以下を実行します。

    構文

    [root@rbd-client ~]# rbd resize --image IMAGE_NAME --size SIZE

2.8. ブロックデバイスイメージの削除

ブロックデバイスイメージを削除します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. ブロックデバイスを削除するには、以下のコマンドを実行しますが、IMAGE_NAME を、削除するイメージの名前に置き換えます。

    構文

    rbd rm IMAGE_NAME

    [root@rbd-client ~]# rbd rm foo

  2. プールからブロックデバイスを削除するには、以下のコマンドを実行しますが、IMAGE_NAME を削除するイメージの名前に置き換え、POOL_NAME をプールの名前に置き換えます。

    構文

    rbd rm IMAGE_NAME -p POOL_NAME

    [root@rbd-client ~]# rbd rm bar -p swimmingpool

2.9. ブロックデバイスイメージのごみ箱への移動

RADOS Block Device(RBD)イメージは、rbd trash コマンドを使用してごみ箱に移動できます。このコマンドは、rbd rm コマンドよりも多くのオプションを提供します。

イメージをごみ箱に移動したら、後でごみ箱から削除できます。これは、誤って削除されないようにするのに役立ちます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. イメージをごみ箱に移動するには、以下を実行します。

    構文

    rbd trash move IMAGE_SPEC

    イメージがごみ箱にあると、一意のイメージ ID が割り当てられます。ごみ箱のオプションを使用する必要がある場合は、後でイメージを指定するために、このイメージ ID が必要です。

  2. ごみ箱内のイメージの ID 一覧に rbd trash リストを実行します。このコマンドは、イメージの事前削除名も返します。

    さらに、rbd info コマンドおよび rbd snap コマンドで使用できるオプションの --image-id 引数があります。rbd info コマンドで --image-id を使用して、ごみ箱内のイメージのプロパティーを表示し、rbd snap を使用して、ごみ箱からイメージのスナップショットを削除します。

  3. ごみ箱からイメージを削除するには、以下を実行します。

    構文

    rbd trash remove [POOL_NAME/] IMAGE_ID

    重要

    イメージをごみ箱から削除した後は復元できません。

  4. --delay オプションを使用して、ごみ箱からイメージを削除するまでの時間を設定します。イメージが削除されるまでの待機時間(デフォルトでは 0)に置き換える秒数で、TIME を置き換えずに実行します。

    構文

    rbd trash move [--delay TIME] IMAGE_SPEC

    --delay オプションを有効にすると、強制されていない限り、指定された期間内のごみ箱からイメージを削除することはできません。

    イメージがごみ箱から削除されていない限り、rbd trash restore コマンドを使用して復元 できます。

  5. rbd trash restore コマンドを実行してイメージを復元します。

    構文

    rbd trash restore [POOL_NAME/] IMAGE_ID

2.10. イメージ機能の有効化および無効化

既存のイメージで fast-diff、exclusive-lockobject- mapジャーナリング などのイメージ機能を有効または無効にすることができます。

注記

ディープフラット な機能は、既存のイメージでのみ無効にできますが、有効ではありません。ディープフラットを使用する には、イメージの作成時に有効にします。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. 機能を有効にするには、以下を実行します。

    構文

    rbd feature enable POOL_NAME/IMAGE_NAME FEATURE_NAME

    1. データ プールの image1 イメージ排他的ロック 機能を有効にするには、以下を実行します。

      [root@rbd-client ~]# rbd feature enable data/image1 exclusive-lock

      重要

      fast-diff および object- map 機能を有効にする場合は、オブジェクトマップを再構築します。

      + .Syntax

      rbd object-map rebuild POOL_NAME/IMAGE_NAME
  2. 機能を無効にするには、以下を実行します。

    構文

    rbd feature disable POOL_NAME/IMAGE_NAME FEATURE_NAME

    1. データ プールの image2 イメージfast-diff 機能を無効にするには、以下を実行します。

      [root@rbd-client ~]# rbd feature disable data/image2 fast-diff

2.11. イメージメタデータの使用

Ceph では、カスタムイメージメタデータをキーと値のペアとして追加することをサポートしています。ペアには厳密なフォーマットはありません。

また、メタデータを使用して、特定イメージの RBD 設定パラメーターを設定することもできます。

rbd image-meta コマンドを使用してメタデータを操作します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. 新しいメタデータキーと値のペアを設定するには、以下を実行します。

    構文

    rbd image-meta set POOL_NAME/IMAGE_NAME KEY VALUE

    [root@rbd-client ~]# rbd image-meta set data/dataset last_update 2016-06-06

    この例では、データ プール内の データセット イメージの last_update キーを 2016-06-06 値に設定します。

  2. メタデータキーと値のペアを削除するには、次のコマンドを実行します。

    構文

    rbd image-meta remove POOL_NAME/IMAGE_NAME KEY

    [root@rbd-client ~]# rbd image-meta remove data/dataset last_update

    この例では、データマッパーの データセット イメージから last_update キーと値のペアを削除し ます

  3. キーの値を表示するには、次のコマンドを実行します。

    構文

    rbd image-meta get POOL_NAME/IMAGE_NAME KEY

    [root@rbd-client ~]# rbd image-meta get data/dataset last_update

    この例では、last_update キーの値を表示します。

  4. イメージ上の全メタデータを表示するには、以下のコマンドを実行します。

    構文

    rbd image-meta list POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd data/dataset image-meta list

    この例では、データ プール内の データセット イメージのメタデータセットを一覧表示します。

  5. 特定のイメージ用に Ceph 設定ファイルに設定された RBD イメージの設定設定を上書きするには、conf_ 接頭辞でイメージメタデータとして設定パラメーターを設定します。

    構文

    rbd image-meta set POOL_NAME/IMAGE_NAME conf_ PARAMETER VALUE

    [root@rbd-client ~]# rbd image-meta set data/dataset conf_rbd_cache false

    この例では、データ プール内の データセット イメージの RBD キャッシュを無効にします。

その他のリソース

2.12. イメージのプール間の移動

RADOS Block Device(RBD)イメージは、同じクラスター内の異なるプール間で移動できます。

このプロセス中、ソースイメージはすべてのスナップショット履歴でターゲットイメージにコピーされます。また、オプションでソースイメージの親にリンクして、スパースを保持するのに役立つようにします。ソースイメージは読み取り専用で、ターゲットイメージは書き込み可能です。移行中、ターゲットイメージはソースイメージにリンクされています。

このプロセスは、新規ターゲットイメージが使用されている間は、バックグラウンドで安全に実行することができます。ただし、準備手順の前に、ターゲットイメージを使用するすべてのクライアントを停止し、イメージを使用するクライアントが新しいターゲットイメージを参照するように更新されるようにします。

重要

krbd カーネル モジュールは、現時点でライブマイグレーションに対応していません。

前提条件

  • ソースイメージを使用するすべてのクライアントを停止します。

手順

  1. ソースイメージとターゲットイメージをクロスリンクする新規ターゲットイメージを作成して移行を準備します。

    構文

    rbd migration prepare SOURCE_IMAGE TARGET_IMAGE

    以下に置き換えてください。

    • 移動するイメージの名前の Source_IMAGEPOOL/IMAGE_NAME 形式を使用します。
    • 新規イメージの名前が付いた target_IMAGEPOOL/IMAGE_NAME 形式を使用します。

    [root@rbd-client ~]# rbd migration prepare data/source stack/target

  2. 準備 する必要がある新規ターゲットイメージの状態を確認します。

    構文

    rbd status TARGET_IMAGE

    [root@rbd-client ~]# rbd status stack/target
    Watchers: none
    Migration:
                source: data/source (5e2cba2f62e)
                destination: stack/target (5e2ed95ed806)
                state: prepared

  3. 必要に応じて、新しいターゲットイメージ名を使用してクライアントを再起動します。
  4. ソースイメージをターゲットイメージにコピーします。

    構文

    rbd migration execute TARGET_IMAGE

    [root@rbd-client ~]# rbd migration execute stack/target

  5. 移行が完了していることを確認します。

    [root@rbd-client ~]# rbd status stack/target
    Watchers:
        watcher=1.2.3.4:0/3695551461 client.123 cookie=123
    Migration:
                source: data/source (5e2cba2f62e)
                destination: stack/target (5e2ed95ed806)
                state: executed

  6. ソースイメージとターゲットイメージ間のクロスリンクを削除して移行をコミットします。この場合、ソースイメージも削除されます。

    構文

    rbd migration commit TARGET_IMAGE

    [root@rbd-client ~]# rbd migration commit stack/target

    ソースイメージが 1 つ以上のクローンの親である場合は、クローンイメージが使用されていないことを確認する後に --force オプションを使用します。

    [root@rbd-client ~]# rbd migration commit stack/target --force

  7. 準備手順の後にクライアントを再起動しなかった場合は、新しいターゲットイメージ名を使用してクライアントを再起動します。

第3章 スナップショット管理

Ceph のスナップショット機能に精通しているストレージ管理者は、Red Hat Ceph Storage クラスターに保存されているイメージのスナップショットおよびクローンを管理するのに役立ちます。

3.1. 前提条件

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

3.2. Ceph ブロックデバイスのスナップショット

スナップショットは、特定時点におけるイメージの状態の読み取り専用コピーです。Ceph ブロックデバイスの高度な機能の 1 つは、イメージのスナップショットを作成して、イメージの状態の履歴を保持することができることです。Ceph はスナップショットの階層化もサポートします。これにより、仮想マシンイメージなどのイメージを迅速かつ簡単にクローン作成することができます。Ceph は、rbd コマンドを使用したブロックデバイスのスナップショットと、QEMUlibvirt、OpenStack、および CloudStack を含む多くの高レベルのインターフェースをサポートします。

注記

I/O の発生中にスナップショットが作成された場合、スナップショットはイメージの正確なデータまたは最新のデータを取得しない可能性があり、スナップショットをマウント可能な新規イメージにクローンする必要がある場合があります。Red Hat は、イメージのスナップショットを作成する前に I/O を停止することを推奨します。イメージにファイルシステムが含まれている場合は、スナップショットを作成する前にファイルシステムが一貫した状態でなければなりません。I/O を停止するには、fsfreeze コマンドを使用します。仮想マシンの場合、スナップショットの作成時に qemu-guest-agent を使用してファイルシステムを自動的にフリーズできます。

           +------------+         +-------------+
           | {s}        |         | {s} c999    |
           |   Active   |<-------*|   Snapshot  |
           |   Image    |         |   of Image  |
           | (stop i/o) |         | (read only) |
           +------------+         +-------------+

その他のリソース

  • 詳細は、man ページの fsfreeze(8) を参照してください。

3.3. Ceph ユーザーおよびキーリング

cephx が有効な場合には、ユーザー名または ID と、ユーザーの対応する鍵を含むキーリングへのパスを指定する必要があります。

注記

cephx はデフォルトで有効にされています。

以下のパラメーターを再入力しないように、CEPH _ARGS 環境変数を追加することもできます。

構文

rbd --id USER_ID --keyring=/path/to/secret [commands]
rbd --name USERNAME --keyring=/path/to/secret [commands]

[root@rbd-client ~]# rbd --id admin --keyring=/etc/ceph/ceph.keyring [commands]
[root@rbd-client ~]# rbd --name client.admin --keyring=/etc/ceph/ceph.keyring [commands]

ヒント

ユーザーとシークレットを CEPH _ARGS 環境変数に追加し、毎回入力する必要がなくなります。

3.4. ブロックデバイススナップショットの作成

Ceph ブロックデバイスのスナップショットを作成します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. snap create オプション、プール名、およびイメージ名を指定します。

    構文

    rbd --pool POOL_NAME snap create --snap SNAP_NAME IMAGE_NAME
    rbd snap create POOL_NAME/IMAGE_NAME@SNAP_NAME

    [root@rbd-client ~]# rbd --pool rbd snap create --snap snapname foo
    [root@rbd-client ~]# rbd snap create rbd/foo@snapname

3.5. ブロックデバイススナップショットの一覧表示

ブロックデバイススナップショットを一覧表示します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. プール名とイメージ名を指定します。

    構文

    rbd --pool POOL_NAME snap ls IMAGE_NAME
    rbd snap ls POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd --pool rbd snap ls foo
    [root@rbd-client ~]# rbd snap ls rbd/foo

3.6. ブロックデバイススナップショットのロールバック

ブロックデバイススナップショットをロールバックします。

注記

イメージをスナップショットにロールバックすると、イメージの現行バージョンがスナップショットのデータで上書きされます。ロールバックの実行にかかる時間は、イメージのサイズとともに増加します。イメージをスナップショット ロールバックするよりも、スナップショットからクローンを作成する方が高速 です。既存の状態に戻す方法として推奨されます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. snap rollback オプション、プール名、イメージ名、および snap 名を指定します。

    構文

    rbd --pool POOL_NAME snap rollback --snap SNAP_NAME IMAGE_NAME
    rbd snap rollback POOL_NAME/IMAGE_NAME@SNAP_NAME

    [root@rbd-client ~]# rbd --pool rbd snap rollback --snap snapname foo
    [root@rbd-client ~]# rbd snap rollback rbd/foo@snapname

3.7. ブロックデバイススナップショットの削除

Ceph ブロックデバイスのスナップショットを削除します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. snap rm オプション、プール名、イメージ名、スナップショット名を指定します。

    構文

    rbd --pool POOL_NAME snap rm --snap SNAP_NAME IMAGE_NAME
    rbd snap rm POOL_NAME-/IMAGE_NAME@SNAP_NAME

    [root@rbd-client ~]# rbd --pool rbd snap rm --snap snapname foo
    [root@rbd-client ~]# rbd snap rm rbd/foo@snapname

重要

イメージにクローンがある場合、クローン作成されたイメージは親イメージのスナップショットへの参照を維持します。親イメージのスナップショットを削除するには、最初に子イメージをフラット化する必要があります。

注記

Ceph OSD デーモンはデータを非同期的に削除するため、スナップショットを削除してもディスク領域はすぐに解放されません。

その他のリソース

3.8. ブロックデバイススナップショットの削除

ブロックデバイススナップショットをパージします。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. snap purge オプションとイメージ名を指定します。

    構文

    rbd --pool POOL_NAME snap purge IMAGE_NAME
    rbd snap purge POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd --pool rbd snap purge foo
    [root@rbd-client ~]# rbd snap purge rbd/foo

3.9. ブロックデバイススナップショットの名前変更

ブロックデバイススナップショットの名前を変更します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. スナップショットの名前を変更するには、以下を実行します。

    構文

    rbd snap rename POOL_NAME/IMAGE_NAME@ORIGINAL_SNAPSHOT_NAME POOL_NAME/IMAGE_NAME@NEW_SNAPSHOT_NAME

    [root@rbd-client ~]# rbd snap rename data/dataset@snap1 data/dataset@snap2

    これは、データ プール上の データセット イメージの snap1 スナップショットの名前を snap2 に変更します。

  2. スナップショットの名前変更に関する追加情報を表示するには、rbd help snap rename コマンドを実行します。

3.10. Ceph ブロックデバイスの階層化

Ceph は、ブロックデバイススナップショットのクローンを多数のコピーオンライト(COW)または Copy-on-read(COR)クローンを作成する機能をサポートしています。スナップショットの階層化により、Ceph ブロックデバイスクライアントはイメージを非常に迅速に作成できます。たとえば、そのイメージに書き込まれた Linux 仮想マシンでブロックデバイスイメージを作成できます。次に、イメージのスナップショットを作成し、スナップショットを保護し、任意の数のクローンを作成します。スナップショットは読み取り専用であるため、スナップショットをクローンしてセマンティクスが簡素化されます。クローンを迅速に作成できるようにします。

           +-------------+              +-------------+
           | {s} c999    |              | {s}         |
           |  Snapshot   | Child refers |  Clone of   |
           |  of Image   |<------------*|  Snapshot   |
           |             |  to Parent   |             |
           | (read only) |              | (writable)  |
           +-------------+              +-------------+

               Parent                        Child
注記

という用語は、Ceph ブロックデバイスのスナップショット、親、およびスナップショットからクローンされた対応するイメージ(子)を意味します。これらの用語は、以下のコマンドラインで重要になります。

クローンされた各イメージ(子)は親イメージへの参照を格納します。これにより、クローンされたイメージで親スナップショットを開いて読み取ることができます。この参照は、スナップショットからの情報が完全にクローンにコピーされると、クローンが フラット 化されると削除されます。

スナップショットのクローンは、他の Ceph ブロックデバイスイメージと同じように動作します。クローンイメージへの読み取り、書き込み、クローン作成、およびサイズ変更が可能です。クローンイメージには特別な制限はありません。ただし、スナップショットのクローンはスナップショットを参照するため、MUST はスナップショットをクローンする前に 保護 します。

スナップショットのクローンは、コピーオンライト(COW)または copy-on-read(COR)のクローンです。Copy-on-Write(COW)はクローンに対して常に有効になっていますが、COR(Copy-on-read)は明示的に有効にする必要があります。Copy-on-write(COW)は、クローン内の未割り当てのオブジェクトに書き込みを行う際に、データを親からクローンにコピーします。Copy-on-read(COR)は、クローン内の未割り当てのオブジェクトから読み取る際に、データを親からクローンにコピーします。クローンからデータの読み取りは、オブジェクトがクローンに存在しない場合にのみ、親からデータを読み取ります。RADOS ブロックデバイスは、大きなイメージを複数のオブジェクトに分割します。デフォルトは 4 MB に設定され、完全なオブジェクトでコピーオンライト(COR)および copy-on-read(COR)操作すべてが発生します。この場合、クローンに 1 バイトのオブジェクトを書き込むと、宛先オブジェクトが直前の COW/COR 操作のクローンにすでに存在しないと、4 MB のオブジェクトが親から読み取られ、クローンに書き込まれます。

COR(Copy-on-read)が有効かどうかに関わらず、クローンからの基礎となるオブジェクトを読み取ることで満たされない読み取りは、親に再度ルーティングされます。実際には、同時数の制限はありません。つまり、クローンのクローンを作成できるので、オブジェクトが見つかるか、ベース親イメージにヒットするまで、この再ルートは継続されます。Copy-on-read(COR)を有効にすると、クローンから直接満たされない読み取りは、親から読み取る完全なオブジェクトを作成し、そのデータをクローンに書き込みます。これにより、親から読み取ることなく、クローン自体から、同じエクステントの読み取りが満たされます。

これは基本的にオンデマンドのオブジェクトごとのフラットな操作です。これは、クローンが、別の地理的な場所にある別のプールの親(別のプールの親)から離れている高レイテンシー接続にある場合に特に便利です。Copy-on-read(COR)は、読み込みの amortized レイテンシーを減らします。最初の数回の読み取りでは、親から追加のデータが親から読み取られるため、レイテンシーが高まります。たとえば、クローンから 1 バイトずつ読み取りますが、4 MB は親からクローンに読み込む必要がありますが、今後の読み取りはすべてクローン自体から提供されます。

スナップショットから copy-on-read(COR)クローンを作成するには、ceph.conf ファイルの [global] または [client] セクションに rbd_clone_copy_on_read = true を追加してこの機能を明示的に有効にする必要があります。

3.11. ブロックデバイススナップショットの保護

親スナップショットへのアクセスのクローンを作成します。ユーザーが親スナップショットを誤って削除した場合、すべてのクローンは破損します。データ損失を防ぐために、MUST スナップショットをクローンする前に保護します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. 以下のコマンドで POOL_NAMEIMAGE_NAME、および SNAP_SHOT_NAME を指定します。

    構文

    rbd --pool POOL_NAME snap protect --image IMAGE_NAME --snap SNAPSHOT_NAME
    rbd snap protect POOL_NAME/IMAGE_NAME@SNAPSHOT_NAME

    [root@rbd-client ~]# rbd --pool rbd snap protect --image my-image --snap my-snapshot
    [root@rbd-client ~]# rbd snap protect rbd/my-image@my-snapshot

    注記

    保護されたスナップショットを削除することはできません。

3.12. ブロックデバイススナップショットのクローン

スナップショットをクローンする前に保護する必要があります。

注記

あるプールから別のプール内のイメージにスナップショットのクローンを作成できます。たとえば、読み取り専用イメージおよびスナップショットを 1 つのプールのテンプレートとして維持し、別のプールに書き込み可能なクローンを作成することもできます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. スナップショットのクローンを作成するには、親プール、スナップショット、子プール、およびイメージ名を指定する必要があります。

    構文

    rbd --pool POOL_NAME --image PARENT_IMAGE --snap SNAP_NAME --dest-pool POOL_NAME --dest CHILD_IMAGE_NAME
    rbd clone POOL_NAME/PARENT_IMAGE@SNAP_NAME  POOL_NAME/CHILD_IMAGE_NAME

    [root@rbd-client ~]# rbd --pool rbd --image my-image --snap my-snapshot --dest-pool rbd --dest new-image
    [root@rbd-client ~]# rbd clone rbd/my-image@my-snapshot rbd/new-image

3.13. ブロックデバイススナップショットの保護解除

スナップショットを削除する前に、そのスナップショットの保護を解除する必要があります。さらに、クローンから参照を持つスナップショットを削除し ない 場合があります。スナップショットを削除する前に、スナップショットの各クローンをフラット化する必要があります。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. 以下のコマンドを実行します。

    構文

    rbd --pool POOL_NAME snap unprotect --image IMAGE_NAME --snap SNAPSHOT_NAME
    rbd snap unprotect POOL_NAME/IMAGE_NAME@SNAPSHOT_NAME

    [root@rbd-client ~]# rbd --pool rbd snap unprotect --image my-image --snap my-snapshot
    [root@rbd-client ~]# rbd snap unprotect rbd/my-image@my-snapshot

3.14. スナップショットの子の一覧表示

スナップショットの子を一覧表示します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. スナップショットの子を一覧表示するには、以下のコマンドを実行します。

    構文

    rbd --pool POOL_NAME children --image IMAGE_NAME --snap SNAP_NAME
    rbd children POOL_NAME/IMAGE_NAME@SNAPSHOT_NAME

    rbd --pool rbd children --image my-image --snap my-snapshot
    rbd children rbd/my-image@my-snapshot

3.15. クローン作成されたイメージのフラット化

クローンされたイメージは、親スナップショットへの参照を維持します。子クローンから親スナップショットへの参照を削除する場合、スナップショットからクローンに情報をコピーしてイメージを効果的に「フラット化」します。スナップショットのサイズでクローンをフラット化するのにかかる時間が長くなります。フラットイメージにはスナップショットからのすべての情報が含まれるため、フラット化されたイメージはレイヤードクローンよりも多くのストレージ領域を使用します。

注記

イメージで 詳細なフラット 機能が有効になっている場合、イメージのクローンはデフォルトでその親から関連付けられます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. 子イメージに関連付けられた親イメージのスナップショットを削除するには、最初に子イメージをフラット化する必要があります。

    構文

    rbd --pool POOL_NAME flatten --image IMAGE_NAME
    rbd flatten POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd --pool rbd flatten --image my-image
    [root@rbd-client ~]# rbd flatten rbd/my-image

第4章 Ceph ブロックデバイスのミラーリング

ストレージ管理者は、Red Hat Ceph Storage クラスター間でデータイメージをミラーリングすることで、別の冗長性レイヤーを Ceph ブロックデバイスに追加できます。Ceph ブロックデバイスのミラーリングについて理解し、使用することで、サイト障害などのデータ損失から保護することができます。

注記

このセクションの例では、2 つのストレージクラスターを、ストレージクラスターをプライマリーイメージとしてサイト( サイト)クラスターとして参照し、イメージを サイト b ストレージクラスター として複製するストレージクラスターを区別します。

4.1. 前提条件

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

4.2. Ceph ブロックデバイスミラーリング

RADOS Block Device(RBD)ミラーリングは、2 つ以上の Ceph ストレージクラスター間の Ceph ブロックデバイスイメージの非同期レプリケーションのプロセスです。ミラーリングは、読み取りおよび書き込み、ブロックデバイスのサイズ変更、スナップショット、クローン、フラット化など、イメージに対するすべての変更のポイントインタイム一貫性のあるレプリカを確実にします。

ミラーリングは、必須の排他的ロックと RBD ジャーナリング機能を使用して、イメージに対するすべての変更を発生順に記録します。これにより、イメージのクラッシュ一貫性のあるミラーが利用可能になります。イメージをピアクラスターにミラーリングするには、ジャーナリングを有効にする必要があります。詳細は、「 ブロックデバイスジャーナリングの有効化」を 参照してください。

これはミラーリングされるブロックデバイスに関連付けられたプライマリープールおよびセカンダリープールに保存されているイメージであるため、プライマリープール およびセカンダリープールの CRUSH 階層は同じストレージ容量とパフォーマンスの特性を持つ必要があり ます。さらに、プライマリーサイトと セカンダリサイト間のネットワーク接続には、十分な帯域幅が 割り当てられて、ミラーリングのレイテンシーが長すぎることはありません。

重要

ブロックデバイスイメージをミラーリングするプライマリーおよびセカンダリープールをサポートする CRUSH 階層は、同じ容量とパフォーマンスの特性を持ち、追加のレイテンシーなしにミラーリングできるように十分な帯域幅を持っている必要があります。たとえば、プライマリークラスター内のイメージに対する X MB/秒の平均書き込みスループットがある場合、ネットワークはセカンダリサイトへのネットワーク接続の N * X スループットと、N イメージをミラーリングするための安全係数 Y% をサポートする必要があります。

ミラーリングは、主に障害からの復旧に使用されます。使用するミラーリングのタイプに応じて、「 一方向ミラーリングの障害からの復旧」または「双方向ミラーリング のある 障害からの復旧」を参照してください。

rbd-mirror デーモン

rbd-mirror デーモンは、ある Ceph クラスターから別のクラスターにイメージを同期します。

レプリケーションのタイプに応じて、rbd-mirror は単一クラスターまたはミラーリングに参加するすべてのクラスター上で実行されます。

  • 一方向レプリケーション

    • データがバックアップとして機能するセカンダリークラスターにミラーリングされる場合、rbd-mirror はセカンダリークラスターで ONLY を実行します。RBD ミラーリングには、複数のセカンダリサイトがある場合があります。
  • 双方向レプリケーション

    • 双方向レプリケーションは、プライマリークラスターに rbd-mirror デーモンを追加します。これにより、イメージを降格してセカンダリクラスターでプロモートすることができます。その後、セカンダリークラスターのイメージに変更が加えられ、セカンダリーからプライマリーまでの逆方向で複製されます。いずれのクラスターでイメージをプロモートおよび降格できるようにするには、両方のクラスターに rbd-mirror を実行する必要があります。現在、2 つのサイト間でのみ双方向レプリケーションがサポートされます。

      rbd-mirror パッケージは、rbd-mirror デーモンを提供します。

重要

双方向のレプリケーションでは、rbd-mirror の各インスタンスが、同時に他の Ceph クラスターに接続できる必要があります。また、ネットワークには、ミラーリングを処理するのに、2 つのデータセンターサイト間の帯域幅が十分になければなりません。

注記

Red Hat Ceph Storage 4 以降、単一クラスターで複数のアクティブな rbd-mirror デーモンを実行することがサポートされます。

ミラーリングモード

ミラーリングは、ピアクラスター内でプールごとに設定されます。Ceph は、プール内のミラーリングされるイメージに応じて 2 つのモードをサポートします。

プールモード
ジャーナリング機能が有効になっているプール内のイメージはすべてミラーリングされます。詳細は、「 プールの一方向ミラーリング の設定」を参照してください。
イメージモード
プール内の特定のサブセットのみがミラーリングされ、イメージごとにミラーリングを有効にする必要があります。詳細は、「 一方向ミラーリング の設定」を参照してください。

イメージの状態

イメージを変更できるかどうかは、その状態によって異なります。

  • プライマリー状態のイメージは変更可能
  • 非プライマリー状態のイメージを変更できない

イメージでミラーリングが最初に有効になっていると、イメージが自動的にプライマリーにプロモートされます。プロモーションは以下のことが可能です。

  • プールモードでミラーリングを有効にして暗黙的に行う。
  • 特定イメージのミラーリングによって明示的に有効化されます。

プライマリーイメージを降格し、プライマリー以外のイメージをプロモートすることが可能です。

その他のリソース

4.3. ブロックデバイスジャーナリングの有効化

Ceph ブロックデバイスジャーナリング機能を有効にすることができます。

  • イメージが作成されたとき。
  • 既存のイメージで動的に行うことができます。
重要

ジャーナリングは、排他的ロック 機能によって異なり、これも有効にする必要があります。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. イメージの作成時にジャーナリングを有効にするには、--image-feature オプションを使用します。

    構文

    rbd create IMAGE_NAME --size MEGABYTES --pool POOL_NAME --image-feature FEATURE

    [root@rbd-client ~]# rbd create image1 --size 1024 --pool data --image-feature exclusive-lock,journaling

  2. 以前に作成したイメージのジャーナリングを有効にするには、rbd feature enable コマンドを使用します。

    構文

    rbd feature enable POOL_NAME/IMAGE_NAME FEATURE_NAME

    [root@rbd-client ~]# rbd feature enable data/image1 exclusive-lock
    [root@rbd-client ~]# rbd feature enable data/image1 journaling

  3. デフォルトではすべての新規イメージでジャーナリングを有効にするには、以下の設定を Ceph 設定ファイルに追加します。

    [root@rbd-client ~]# rbd default features = 125

4.4. 一方向ミラーリング

一方向ミラーリングは、1 つのストレージクラスターのプライマリーイメージがセカンダリーストレージクラスターに複製されることを意味します。セカンダリーストレージクラスターでは、レプリケートされたイメージはプライマリー以外のもので、ブロックデバイスクライアントはイメージに書き込むことができません。

注記

一方向ミラーリングは、複数のセカンダリーサイトをサポートします。複数のセカンダリーサイトで一方向ミラーリングを設定するには、各セカンダリークラスターで以下の手順を実行します。

注記

一方向ミラーリングは、イメージのクラッシュ一貫性のあるコピーを維持するのに適しています。一方向ミラーリングは、一方向ミラーリングを使用する際にクラスターをフェイルバックできないため、OpenStack の自動フェイルオーバーおよびフェイルバックにセカンダリーイメージを使用するなど、すべての状況では適切ではない場合があります。このような場合、双方向ミラーリングを使用します。

重要

追加のセカンダリークラスターを使用している場合は、フェールオーバーするセカンダリークラスターのいずれかを選択します。フェイルバック時に同じクラスターから同期します。

前提条件

  • 2 つのストレージクラスターがあり、プライマリーストレージクラスターからセカンダリーストレージクラスターにイメージを複製する必要があります。
  • site-b クラスターには、rbd-mirror デーモンを実行する場所にクライアントノードが割り当てられます。このデーモンは、site-a クラスターに接続し、イメージを site-b クラスターと同期します。
  • 同じ名前のプールが両方のクラスターに作成されます。以下の例では、プールの名前は data です。
  • プールにはミラーリングするイメージが含まれ、ジャーナリングが有効にされているイメージが含まれます。

Ceph ブロックデバイスのミラーリングを設定するには、以下の 2 つの方法があります。

その他のリソース

4.5. 双方向ミラーリング

双方向ミラーリングを使用すると、2 つのストレージクラスター間のいずれかの方向でイメージを複製できます。ストレージクラスターから同じイメージに変更を作成してから、変更を前後に伝播することはできません。イメージは、書き込み元の変更先および同期先のストレージクラスターから昇格または降格されます。

前提条件

  • 2 つのクラスターがあり、いずれの方向でもイメージを複製できます。
  • どちらのストレージクラスターも、rbd-mirror デーモンを実行するクライアントノードを接続しています。サイトストレージクラスターのデーモンは、サイト(ストレージクラスター )に接続して サイト b に イメージを同期します 。また、サイト 上のデーモンはサイト- b ストレージクラスターに接続し、イメージを site-a に同期し ます。
  • 同じ名前のプールが両方のストレージクラスターに作成されます。
  • プールにはミラーリングするイメージが含まれ、ジャーナリングが有効にされているイメージが含まれます。

Ceph ブロックデバイスのミラーリングを設定するには、以下の 2 つの方法があります。

その他のリソース

4.6. プールでのミラーリングの設定

ストレージ管理者は、Red Hat Ceph Storage クラスターのピアのプールでミラーリングを設定できます。以下のタスクを実行できます。

  • プールでのミラーリングの有効化。
  • プールでのミラーリングの無効化
  • ピアに関する情報を表示します。
  • ストレージクラスターのピアを追加または削除します。
  • プールのミラーリングステータスを取得します。
重要

両方のストレージクラスターピアで以下の手順を実行します。

4.6.1. 前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

4.6.2. プールでのミラーリングの有効化

両方のピアクラスターで以下のコマンドを実行して、プールでのミラーリングを有効にします。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. プールでミラーリングを有効にするには、以下を実行します。

    構文

    rbd mirror pool enable POOL_NAME MODE

    [root@rbd-client ~]# rbd mirror pool enable data pool

    この例では、data という名前のプール全体のミラーリングを有効にします。

    [root@rbd-client ~]# rbd mirror pool enable data image

    この例では、data という名前のプールでイメージモードのミラーリングを有効にします。

その他のリソース

4.6.3. プールでのミラーリングの無効化

ミラーリングを無効にする前に、ピアクラスターを削除します。

注記

プールでミラーリングを無効にする場合は、イメージモードでミラーリングが有効になったプール内のイメージでも、ミラーリングを無効にします。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. プールでミラーリングを無効にするには、以下を実行します。

    構文

    rbd mirror pool disable POOL_NAME

    [root@rbd-client ~]# rbd mirror pool disable data

    この例では、data という名前のプールのミラーリングを無効にします。

その他のリソース

4.6.4. ストレージクラスターピアの追加

rbd-mirror デーモンのストレージクラスターピアを追加して、ピアストレージクラスターを検出します。たとえば、サイト(ストレージクラスター)をピアとしてサイト- b ストレージクラスターに追加するには、site -b ストレージクラスターのクライアントノードから以下の手順に従います。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. ピアをプールに登録します。

    構文

    rbd --cluster CLUSTER_NAME mirror pool peer add POOL_NAME PEER_CLIENT_NAME@PEER_CLUSTER_NAME -n CLIENT_NAME

    [root@rbd-client ~]# rbd --cluster site-b mirror pool peer add data client.site-a@site-a -n client.site-b

4.6.5. ピアに関する情報の表示

ストレージクラスターのピアに関する情報を表示します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. ピアに関する情報を表示するには、以下を実行します。

    構文

    rbd mirror pool info POOL_NAME

    [root@rbd-client ~]# rbd mirror pool info data
    Mode: pool
    Peers:
      UUID                                 NAME   CLIENT
      7e90b4ce-e36d-4f07-8cbc-42050896825d site-a client.site-a

4.6.6. ストレージクラスターピアの削除

ピア UUID を指定して、ストレージクラスターのピアを削除します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. プール名とピアの UUID(Universally Unique Identifier)を指定します。

    構文

    rbd mirror pool peer remove POOL_NAME PEER_UUID

    [root@rbd-client ~]# rbd mirror pool peer remove data 7e90b4ce-e36d-4f07-8cbc-42050896825d

    ヒント

    ピア UUID を表示するには、rbd mirror pool info コマンドを使用します。

4.6.7. プールのミラーリングステータスの取得

プールのミラーステータスを取得します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. ミラーリングプールのサマリーを取得するには、以下を実行します。

    構文

    rbd mirror pool status POOL_NAME

    [root@rbd-client ~]# rbd mirror pool status data
    health: OK
    images: 1 total

    ヒント

    プール内の各ミラーリングイメージのステータス情報を出力するには、--verbose オプションを使用します。

4.6.8. プールの一方向ミラーリングの設定

プライマリーストレージクラスターからセカンダリーストレージクラスターに複製するようにプールを設定します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。
  • データ プール内のすべてのイメージに排他的ロックとジャーナリングが有効になっていることを確認します。

手順

  1. site-b クラスターのクライアントノードで、rbd- mirror パッケージをインストールします。

    [root@rbd-client ~]# yum install rbd-mirror
    注記

    このパッケージは、Red Hat Ceph Storage Tools リポジトリーで提供されます。

  2. site-b クラスターのクライアントノードで、CLUSTER オプションを /etc/sysconfig/ceph ファイルに追加してクラスター名を指定します。

    CLUSTER=site-b
  3. 両方のストレージクラスターで、データ プールにアクセスするためのパーミッションを持つユーザーを作成し、キーリングを CLUSTER_NAME.client.USER_NAME.keyring ファイルに出力します。

    1. サイト内の Ceph Monitor ノードで client. site-a ユーザーを作成し、キーリングを site-a. client.site-a.keyring ファイルに出力します。

      [root@rbd-client ~]# ceph auth get-or-create client.site-a mon 'profile rbd' osd 'profile rbd pool=data' -o /etc/ceph/site-a.client.site-a.keyring

    2. site-b ストレージクラスターの Ceph Monitor ノードで client. site-b ユーザーを作成し、キーリングを site- b. client.site-b.keyring ファイルに出力します。

      [root@rbd-client ~]# ceph auth get-or-create client.site-b mon 'profile rbd' osd 'profile rbd pool=data' -o /etc/ceph/site-b.client.site-b.keyring

  4. Ceph 設定ファイルと新たに作成されたキーリングファイルを サイト-a Ceph Monitor ノードから サイト-b Ceph Monitor およびクライアントノードにコピーします。

    構文

    scp /etc/ceph/ceph.conf USER@SITE_B_MON_NODE_NAME:/etc/ceph/site-a.conf
    scp /etc/ceph/site-a.client.site-a.keyring USER@SITE_B_MON_NODE_NAME:/etc/ceph/
    
    scp /etc/ceph/ceph.conf USER@SITE_B_CLIENT_NODE_NAME:/etc/ceph/site-a.conf
    scp /etc/ceph/site-a.client.site-a.keyring USER@SITE_B_CLIENT_NODE_NAME:/etc/ceph/

    注記

    Ceph 設定ファイルを site- a Ceph Monitor ノードからサイト- b Ceph Monitor に転送する scp コマンドおよびクライアントノードは、ファイルの名前を site-a.conf に変更します。キーリングファイル名は同じままになります。

  5. site-b クラスタークライアントノードの ceph.conf を参照する site-b.conf という名前のシンボリックリンクを作成します。

    [root@rbd-client ~]# cd /etc/ceph
    [root@rbd-client ~]# ln -s ceph.conf site-b.conf

  6. site-b クライアントノードで rbd-mirror デーモンを有効にして起動します。

    構文

    systemctl enable ceph-rbd-mirror.target
    systemctl enable ceph-rbd-mirror@CLIENT_ID
    systemctl start ceph-rbd-mirror@CLIENT_ID

    CLIENT_ID を、rbd-mirror デーモンが使用する Red Hat Ceph Storage ユーザーに変更します。ユーザーには、ストレージクラスターへの適切な cephx アクセスが必要です。

    [root@rbd-client ~]# systemctl enable ceph-rbd-mirror.target
    [root@rbd-client ~]# systemctl enable ceph-rbd-mirror@site-b
    [root@rbd-client ~]# systemctl start ceph-rbd-mirror@site-b

  7. サイト上の Ceph Monitor ノードで以下のコマンドを実行して、サイト上の データ プールのプールミラーリングを有効にします。これには、ストレージクラスター の Ceph Monitor ノードで以下のコマンド 実行します。

    [root@rbd-client ~]# rbd mirror pool enable data pool

    ミラーリングが正常に有効化されていることを確認します。

    [root@rbd-client ~]# rbd mirror pool info data
    Mode: pool
    Peers: none

  8. site- b ストレージクラスター のクライアントノードから次のコマンドを実行して、サイトストレージクラスターを サイト b ストレージクラスターのピアとして追加します。

    [root@rbd-client ~]# rbd --cluster site-b mirror pool peer add data client.site-a@site-a -n client.site-b

    ピアが正常に追加されたことを確認します。

    [root@rbd-client ~]# rbd mirror pool info data
    Mode: pool
    Peers:
      UUID                                 NAME   CLIENT
      7e90b4ce-e36d-4f07-8cbc-42050896825d site-a client.site-a

  9. しばらくしたら、image1 イメージおよび image 2 イメージのステータスを確認します。状態が up+replaying の場合には、ミラー リングが適切に機能します。site-b ストレージクラスター内の Ceph Monitor ノードから以下のコマンドを実行します。

    [root@rbd-client ~]# rbd mirror image status data/image1
    image1:
      global_id:   7d486c3f-d5a1-4bee-ae53-6c4f1e0c8eac
      state:       up+replaying
      description: replaying, master_position=[object_number=3, tag_tid=1, entry_tid=3], mirror_position=[object_number=3, tag_tid=1, entry_tid=3], entries_behind_master=0
      last_update: 2019-04-22 13:19:27

    [root@rbd-client ~]# rbd mirror image status data/image2
    image2:
      global_id:   703c4082-100d-44be-a54a-52e6052435a5
      state:       up+replaying
      description: replaying, master_position=[object_number=3, tag_tid=1, entry_tid=3], mirror_position=[], entries_behind_master=3
      last_update: 2019-04-22 13:19:19

その他のリソース

  • 詳細は、『 Red Hat Ceph Storage Block Device Guide』 の「 Enabling block device journaling 」セクションを参照してください。
  • Ceph ユーザーの詳細については、『 Red Hat Ceph Storage Administration Guide』 の「 User Management 」セクションを参照してください。

4.7. イメージへのミラーリングの設定

ストレージ管理者は、Red Hat Ceph Storage クラスターのピアのイメージでミラーリングを設定できます。以下のタスクを実行できます。

  • イメージのミラーリングの有効化。
  • イメージのミラーリングの無効化
  • イメージのプロモーションと降格。
  • イメージの再同期。
  • 1 つのイメージのミラーリングステータスを取得します。
重要

単一のストレージクラスターで以下の手順を実行します。

4.7.1. 前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

4.7.2. イメージのミラーリングの有効化

両方のピアストレージクラスターのイメージモードでプール全体でミラーリングを有効にします。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. プール内の特定イメージのミラーリングを有効にします。

    構文

    rbd mirror image enable POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image enable data/image2

    この例では、データ プール内の image2 イメージのミラーリングを有効にします。

その他のリソース

  • 詳細は、『 Red Hat Ceph Storage Block Device Guide』 の「 Enabling mirroring on a pool 」セクションを参照してください。

4.7.3. イメージミラーリングの無効化

イメージのミラーを無効にします。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. 特定のイメージのミラーリングを無効にするには、以下を実行します。

    構文

    rbd mirror image disable POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image disable data/image2

    この例では、データ プール内の image2 イメージのミラーリングを無効にします。

4.7.4. イメージのプロモーションおよび降格

イメージをプロモートまたは降格します。

注記

昇格後もイメージが有効ではないため、同期している非プライマリーイメージは強制的にプロモートしないでください。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. イメージを非プライマリーに降格するには、以下を実行します。

    構文

    rbd mirror image demote POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image demote data/image2

    この例では、データ プールの image2 イメージを降格します。

  2. イメージをプライマリーにプロモートするには、以下を実行します。

    構文

    rbd mirror image promote POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image promote data/image2

    この例では、データ プールで image2 をプロモートします。

    使用しているミラーリングのタイプに応じて、「 一方向ミラーリングでの障害からの 復旧」または「双方向ミラーリング のある障害からの復旧」を参照してください。

  3. --force オプションを使用して、プライマリー以外のイメージを強制的にプロモートします。

    構文

    rbd mirror image promote --force POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image promote --force data/image2

    降格をピア Ceph ストレージクラスターに伝播できない場合は、強制的に昇格を使用します。たとえば、クラスター障害や通信の停止などが原因となります。

その他のリソース

4.7.5. イメージの再同期

イメージを再同期します。2 つのピアクラスター間で一貫性のない状態がある場合、rbd-mirror デーモンは、不整合の原因となるイメージのミラーリングを試行しません。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. プライマリーイメージへの再同期を要求するには、以下を実行します。

    構文

    rbd mirror image resync POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image resync data/image2

    この例では、データ プールの image2 の再同期を要求します。

4.7.6. 単一イメージのミラーリングステータスの取得

イメージのミラーステータスを取得します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. ミラーリングされたイメージのステータスを取得するには、以下を実行します。

    構文

    rbd mirror image status POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image status data/image2
    image2:
      global_id:   703c4082-100d-44be-a54a-52e6052435a5
      state:       up+replaying
      description: replaying, master_position=[object_number=0, tag_tid=3, entry_tid=0], mirror_position=[object_number=0, tag_tid=3, entry_tid=0], entries_behind_master=0
      last_update: 2019-04-23 13:39:15

    この例では、データ プールの image2 イメージのステータスを取得します。

4.7.7. イメージの一方向ミラーリングの設定

プライマリーストレージクラスターからセカンダリーストレージクラスターに複製するようにイメージを設定します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。
  • データ プール内でミラーリングする選択したイメージに排他ロックがあり、ジャーナリングが有効になっていることを確認してください。

手順

  1. site-b ストレージクラスターのクライアントノードで、CLUSTER オプションを /etc/sysconfig/ceph ファイルに追加してストレージクラスター名を指定します。

    CLUSTER=site-b
  2. 両方のストレージクラスターで、データ プールにアクセスするためのパーミッションを持つユーザーを作成し、キーリングを CLUSTER_NAME.client.USER_NAME.keyring ファイルに出力します。

    1. サイト内の Ceph Monitor ノードで client. site-a ユーザーを作成し、キーリングを site-a. client.site-a.keyring ファイルに出力します。

      [root@rbd-client ~]# ceph auth get-or-create client.site-a mon 'profile rbd' osd 'profile rbd pool=data' -o /etc/ceph/site-a.client.site-a.keyring

    2. site-b ストレージクラスターの Ceph Monitor ノードで client. site-b ユーザーを作成し、キーリングを site- b. client.site-b.keyring ファイルに出力します。

      [root@rbd-client ~]# ceph auth get-or-create client.site-b mon 'profile rbd' osd 'profile rbd pool=data' -o /etc/ceph/site-b.client.site-b.keyring

  3. Ceph 設定ファイルと新たに作成されたキーリングファイルを サイト-a Ceph Monitor ノードから サイト-b Ceph Monitor およびクライアントノードにコピーします。

    構文

    scp /etc/ceph/ceph.conf USER@SITE_B_MON_NODE_NAME:/etc/ceph/site-a.conf
    scp /etc/ceph/site-a.client.site-a.keyring USER@SITE_B_MON_NODE_NAME:/etc/ceph/
    
    scp /etc/ceph/ceph.conf USER@SITE_B_CLIENT_NODE_NAME:/etc/ceph/site-a.conf
    scp /etc/ceph/site-a.client.site-a.keyring USER@SITE_B_CLIENT_NODE_NAME:/etc/ceph/

    注記

    Ceph 設定ファイル site -a モニターノードから site- b monitor に転送し、クライアントノードの名前を site-a.conf に変更します。キーリングファイル名は同じままになります。

  4. site-b クラスタークライアントノードの ceph.conf を参照する site-b.conf という名前のシンボリックリンクを作成します。

    [root@rbd-client ~]# cd /etc/ceph
    [root@rbd-client ~]# ln -s ceph.conf site-b.conf

  5. site-b クライアントノードで rbd-mirror デーモンを有効にして起動します。

    構文

    systemctl enable ceph-rbd-mirror.target
    systemctl enable ceph-rbd-mirror@CLIENT_ID
    systemctl start ceph-rbd-mirror@CLIENT_ID

    CLIENT_ID を、rbd-mirror デーモンが使用するユーザーに変更します。ユーザーには、クラスターへの適切な cephx アクセスが必要です。詳細は、『 Red Hat Ceph Storage Administration Guide』の「 User Management 」の章を参照してください

    [root@rbd-client ~]# systemctl enable ceph-rbd-mirror.target
    [root@rbd-client ~]# systemctl enable ceph-rbd-mirror@site-b
    [root@rbd-client ~]# systemctl start ceph-rbd-mirror@site-b

  6. site -a クラスターのモニターノードで以下のコマンドを実行して、サイト 上のクラスターにある データ プールのミラーリングを有効にし ます

    [root@rbd-client ~]# rbd mirror pool enable data pool

    ミラーリングが正常に有効化されていることを確認します。

    [root@rbd-client ~]# rbd mirror pool info data
    Mode: pool
    Peers: none

  7. サイト上の Ceph Monitor ノードから、 データ プールのイメージミラーリングを有効にします。

    [root@rbd-client ~]# rbd mirror pool enable data image

    ミラーリングが正常に有効化されていることを確認します。

    [root@rbd-client ~]# rbd mirror pool info data
    Mode: image
    Peers: none

  8. サイト b ストレージクラスターのクライアントノードから、site-a ストレージクラスターをピア として 追加します。

    [root@rbd-client ~]# rbd --cluster site-b mirror pool peer add data client.site-a@site-a -n client.site-b

    ピアが正常に追加されたことを確認します。

    [root@rbd-client ~]# rbd mirror pool info data
    Mode: image
    Peers:
      UUID                                 NAME   CLIENT
      9c1da891-b9f4-4644-adee-6268fe398bf1 site-a client.site-a

  9. サイト上の Ceph Monitor ノードから、image 1 イメージ および image 2 イメージのイメージミラーリングを明示的に有効にします。

    [root@rbd-client ~]# rbd mirror image enable data/image1
    Mirroring enabled
    [root@rbd-client ~]# rbd mirror image enable data/image2
    Mirroring enabled
  10. しばらくしたら、image1 イメージおよび image 2 イメージのステータスを確認します。状態が up+replaying の場合には、ミラー リングが適切に機能します。site-b ストレージクラスター内の Ceph Monitor ノードから以下のコマンドを実行します。

    [root@rbd-client ~]# rbd mirror image status data/image1
    image1:
      global_id:   08027096-d267-47f8-b52e-59de1353a034
      state:       up+replaying
      description: replaying, master_position=[object_number=3, tag_tid=1, entry_tid=3], mirror_position=[object_number=3, tag_tid=1, entry_tid=3], entries_behind_master=0
      last_update: 2019-04-12 17:24:04

    [root@rbd-client ~]# rbd mirror image status data/image2
    image2:
      global_id:   596f41bc-874b-4cd4-aefe-4929578cc834
      state:       up+replaying
      description: replaying, master_position=[object_number=3, tag_tid=1, entry_tid=3], mirror_position=[object_number=3, tag_tid=1, entry_tid=3], entries_behind_master=0
      last_update: 2019-04-12 17:23:51

その他のリソース

4.8. ブロックデバイスレプリケーションの遅延

一方向または双方向のレプリケーションを使用する場合でも、RADOS Block Device(RBD)のミラーリングイメージ間でレプリケーションを遅延させることができます。セカンダリーイメージに複製される前にプライマリーイメージへの不要な変更を元に戻す必要がある場合は、遅延したレプリケーションを実装する必要があります。

遅延したレプリケーションを実装するには、宛先ストレージクラスター 内の rbd- mirroring_replay_delay = MINIMUM_DELAY_IN_SECONDS 設定オプションを設定する必要があります。この設定は、rbd-mirror デーモンが使用する ceph.conf ファイルまたは個別のイメージベースでグローバルに適用できます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. 特定のイメージに遅延したレプリケーションを使用するには、プライマリーイメージで以下の rbd CLI コマンドを実行します。

    構文

    rbd image-meta set POOL_NAME/IMAGE_NAME conf_rbd_mirroring_replay_delay MINIMUM_DELAY_IN_SECONDS

    [root@rbd-client ~]# rbd image-meta set vms/vm-1 conf_rbd_mirroring_replay_delay 600

    この例では、vms プール内のイメージ vm-1 に最小 10 分間のレプリケーション遅延を設定します。

4.9. 障害からの復旧

ストレージ管理者は、ミラーリングが設定された別のストレージクラスターからデータを復旧する方法を把握して、ハードウェア障害の発生に向けて準備できます。

この例では、プライマリーストレージクラスターは site-a と呼ばれ、セカンダリーストレージクラスターは site-b と呼ばれます。また、ストレージクラスターには、image1 および image 2 の 2 つのイメージを持つ データ プールがあります。

4.9.1. 前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • 一方向または双方向ミラーリングが設定されている。

4.9.2. 一方向ミラーリングの障害からの復旧

一方向ミラーリングを使用する場合に障害からの復旧には、以下の手順を使用します。プライマリークラスターが終了した後にセカンダリークラスターにフェイルオーバーする方法と、フェイルオーバー方法を示します。シャットダウンは順序付けまたは順序以外の値にすることができます。

重要

一方向ミラーリングは、複数のセカンダリーサイトをサポートします。追加のセカンダリークラスターを使用している場合は、フェールオーバーするセカンダリークラスターのいずれかを選択します。フェイルバック時に同じクラスターから同期します。

4.9.3. 双方向ミラーリングのある障害からの復旧

双方向ミラーリングを使用する場合に障害からの復旧には、以下の手順を使用します。これらは、プライマリークラスターが終了した後に、セカンダリークラスターでミラーリングされたデータにフェールオーバーする方法と、フェイルバック方法を示します。シャットダウンは順序付けまたは順序以外の値にすることができます。

その他のリソース

  • イメージのデモ、プロモート、および再同期の詳細は、『 Red Hat Ceph Storage Block Device Guide』の「Configuring mirroring on a image 」セクションを参照してください

4.9.4. 順序シャットダウン後のフェイルオーバー

正常にシャットダウンした後に、セカンダリーストレージクラスターにフェイルオーバーします。

前提条件

手順

  1. プライマリーイメージを使用するすべてのクライアントを停止します。この手順では、どのクライアントがイメージを使用するかによって異なります。たとえば、イメージを使用する OpenStack インスタンスからボリュームをデタッチします。
  2. site-a クラスターのモニターノードで以下のコマンドを実行し、site-a クラスターにあるプライマリーイメージを降格します。

    構文

    rbd mirror image demote POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image demote data/image1
    [root@rbd-client ~]# rbd mirror image demote data/image2

  3. site-b クラスターのモニターノードで以下のコマンドを実行して、site-b クラ スター にある非プライマリーイメージをプロモートします。

    構文

    rbd mirror image promote POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image promote data/image1
    [root@rbd-client ~]# rbd mirror image promote data/image2

  4. しばらくしたら、site-b クラスターのモニターノードからイメージのステータスを確認します。up+stopped の状態を表示し、プライマリーとして一覧表示されるはずです。

    [root@rbd-client ~]# rbd mirror image status data/image1
    image1:
      global_id:   08027096-d267-47f8-b52e-59de1353a034
      state:       up+stopped
      description: local image is primary
      last_update: 2019-04-17 16:04:37
    [root@rbd-client ~]# rbd mirror image status data/image2
    image2:
      global_id:   596f41bc-874b-4cd4-aefe-4929578cc834
      state:       up+stopped
      description: local image is primary
      last_update: 2019-04-17 16:04:37
  5. イメージへのアクセスを再開します。この手順では、どのクライアントがイメージを使用するかによって異なります。

その他のリソース

4.9.5. 順序以外のシャットダウン後のフェイルオーバー

非順序でシャットダウンした後にセカンダリーストレージクラスターにフェイルオーバーします。

前提条件

手順

  1. プライマリーストレージクラスターがダウンしていることを確認します。
  2. プライマリーイメージを使用するすべてのクライアントを停止します。この手順では、どのクライアントがイメージを使用するかによって異なります。たとえば、イメージを使用する OpenStack インスタンスからボリュームをデタッチします。
  3. site-b ストレージクラスターの Ceph Monitor ノードから、非プライマリーイメージをプロモートします。demotion は ストレージクラスターに伝搬できないため、--force オプションを使用し ます。

    構文

    rbd mirror image promote --force POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image promote --force data/image1
    [root@rbd-client ~]# rbd mirror image promote --force data/image2

  4. site-b ストレージクラスターの Ceph Monitor ノードからイメージのステータスを確認します。up+stopping_replay の状態が表示され、説明は 強制的にプロモート されるはずです。

    [root@rbd-client ~]# rbd mirror image status data/image1
    image1:
      global_id:   08027096-d267-47f8-b52e-59de1353a034
      state:       up+stopping_replay
      description: force promoted
      last_update: 2019-04-17 13:25:06
    [root@rbd-client ~]# rbd mirror image status data/image2
    image2:
      global_id:   596f41bc-874b-4cd4-aefe-4929578cc834
      state:       up+stopping_replay
      description: force promoted
      last_update: 2019-04-17 13:25:06

その他のリソース

4.9.6. フェイルバックの準備

2 つのストレージクラスターが最初は一方向ミラーリング専用に設定されていた場合に、フェイルバックのためにプライマリーストレージクラスターをミラーリングするように、反対方向でイメージを複製するように、ミラーリング用にプライマリーストレージクラスターを設定します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. サイトストレージクラスターのクライアントノードで rbd- mirror パッケージをインストールします。

    [root@rbd-client ~]# yum install rbd-mirror
    注記

    このパッケージは、Red Hat Ceph Storage Tools リポジトリーで提供されます。

  2. サイトストレージクラスターのクライアントノードで、CLUSTER オプション /etc/sysconfig/ceph ファイルに追加してストレージクラスター名を指定します。

    CLUSTER=site-b
  3. site-b Ceph 設定ファイルおよびキーリングファイルを サイト-b Ceph Monitor ノードからサイト ごとの Ceph Monitor ノードおよびクライアントノードにコピーします。

    構文

    scp /etc/ceph/ceph.conf USER@SITE_A_MON_NODE_NAME:/etc/ceph/site-b.conf
    scp /etc/ceph/site-b.client.site-b.keyring root@SITE_A_MON_NODE_NAME:/etc/ceph/
    scp /etc/ceph/ceph.conf user@SITE_A_CLIENT_NODE_NAME:/etc/ceph/site-b.conf
    scp /etc/ceph/site-b.client.site-b.keyring user@SITE_A_CLIENT_NODE_NAME:/etc/ceph/

    注記

    Ceph 設定ファイルを site -b Ceph Monitor ノードからサイト (Ceph Monitor)に転送する scp コマンドが ファイルを site-a.conf に変更します。キーリングファイル名は同じままになります。

  4. サイト(キーリングファイルを サイト)から Ceph Monitor ノードから クライアントノードにコピーし ます。

    構文

    scp /etc/ceph/site-a.client.site-a.keyring <user>@SITE_A_CLIENT_HOST_NAME:/etc/ceph/

  5. site-a クライアントノードで rbd-mirror デーモンを有効にして起動します。

    構文

    systemctl enable ceph-rbd-mirror.target
    systemctl enable ceph-rbd-mirror@CLIENT_ID
    systemctl start ceph-rbd-mirror@CLIENT_ID

    CLIENT_ID を、rbd-mirror デーモンが使用する Ceph Storage クラスターユーザーに変更します。ユーザーには、ストレージクラスターへの適切な cephx アクセスが必要です。

    [root@rbd-client ~]# systemctl enable ceph-rbd-mirror.target
    [root@rbd-client ~]# systemctl enable ceph-rbd-mirror@site-a
    [root@rbd-client ~]# systemctl start ceph-rbd-mirror@site-a

  6. サイト上のクライアントノードから、 site-b クラスター をピアとして追加します。

    [root@rbd-client ~]# rbd --cluster site-a mirror pool peer add data client.site-b@site-b -n client.site-a

    複数のセカンダリーストレージクラスターを使用している場合は、フェイルオーバーに使用するセカンダリーストレージクラスターのみが追加され、フェイルバック元を追加する必要があります。

  7. サイトストレージクラスターのモニターノードから site- b ストレージクラスターがピアとして正常に追加されたことを確認します。

    [root@rbd-client ~]# rbd mirror pool info -p data
    Mode: image
    Peers:
      UUID                                 NAME   CLIENT
      d2ae0594-a43b-4c67-a167-a36c646e8643 site-b client.site-b

その他のリソース

  • 詳細は、『 Red Hat Ceph Storage Administration Guide』の「 User Management 」の章を参照してください

4.9.6.1. プライマリーストレージクラスターへのフェイルバック

以前のプライマリーストレージクラスターが復旧すると、プライマリーストレージクラスターにフェイルバックします。

前提条件

手順

  1. site-b クラスターのモニターノードからイメージのステータスを再度確認します。これらは up-stopped の状態を表示し、説明 はローカルイメージが primary と示すべきです。

    [root@rbd-client ~]# rbd mirror image status data/image1
    image1:
      global_id:   08027096-d267-47f8-b52e-59de1353a034
      state:       up+stopped
      description: local image is primary
      last_update: 2019-04-22 17:37:48
    [root@rbd-client ~]# rbd mirror image status data/image2
    image2:
      global_id:   08027096-d267-47f8-b52e-59de1353a034
      state:       up+stopped
      description: local image is primary
      last_update: 2019-04-22 17:38:18

  2. ストレージクラスターの Ceph Monitor ノードから、イメージがプライマリーかどうかを 判断 します。

    構文

    rbd mirror pool info POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd info data/image1
    [root@rbd-client ~]# rbd info data/image2

    コマンドの出力で、状態を判断するために primary: true または mirroring primary: false のミラーリングを探します。

  3. site-a ストレージクラスターの Ceph Monitor ノードから以下のようなコマンドを実行して、プライマリーとして一覧表示されるイメージを 降格します。

    構文

    rbd mirror image demote POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image demote data/image1

  4. イメージを順番にシャットダウンしていない場合は ONLY を再同期します。サイトストレージクラスターのモニターノードで以下のコマンドを実行し、イメージ をサイト b から site-a に再同期し ます

    構文

    rbd mirror image resync POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image resync data/image1
    Flagged image for resync from primary
    [root@rbd-client ~]# rbd mirror image resync data/image2
    Flagged image for resync from primary

  5. しばらくすると、イメージが up+replaying 状態 にあることを確認して、イメージの再同期が完了していることを確認します。サイト内のモニターノードで以下のコマンドを実行して、それらの状態を チェックします。

    構文

    rbd mirror image status POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image status data/image1
    [root@rbd-client ~]# rbd mirror image status data/image2

  6. site-b ストレージクラスターの Ceph Monitor ノードで以下のコマンドを実行して、サイト b ストレージクラスターのイメージを降格します。

    構文

    rbd mirror image demote POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image demote data/image1
    [root@rbd-client ~]# rbd mirror image demote data/image2

    注記

    セカンダリーストレージクラスターが複数ある場合は、プロモートされたセカンダリーストレージクラスターからのみ実行する必要があります。

  7. サイト上の Ceph Monitor ノードで以下のコマンドを 実行して、サイト上のストレージクラスターにある以前のプライマリーイメージを プロモートします。

    構文

    rbd mirror image promote POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image promote data/image1
    [root@rbd-client ~]# rbd mirror image promote data/image2

  8. site-a Storage クラスターの Ceph Monitor ノードからイメージのステータスを 確認します。up+stopped のステータスが表示され、説明は ローカルイメージが primary と示される はずです。

    構文

    rbd mirror image status POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd mirror image status data/image1
    image1:
      global_id:   08027096-d267-47f8-b52e-59de1353a034
      state:       up+stopped
      description: local image is primary
      last_update: 2019-04-22 11:14:51
    [root@rbd-client ~]# rbd mirror image status data/image2
    image2:
      global_id:   596f41bc-874b-4cd4-aefe-4929578cc834
      state:       up+stopped
      description: local image is primary
      last_update: 2019-04-22 11:14:51

4.9.7. 双方向ミラーリングの削除

フェイルバックが完了したら、双方向ミラーリングを削除し、Ceph ブロックデバイスミラーリングサービスを無効にすることができます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. site-b ストレージクラスターをサイトストレージクラスターからピアとして削除し ます

    [root@rbd-client ~]# rbd mirror pool peer remove data client.remote@remote --cluster local
    [root@rbd-client ~]# rbd --cluster site-a mirror pool peer remove data client.site-b@site-b -n client.site-a

  2. site-a クライアントで rbd-mirror デーモンを停止して無効にします。

    構文

    systemctl stop ceph-rbd-mirror@CLIENT_ID
    systemctl disable ceph-rbd-mirror@CLIENT_ID
    systemctl disable ceph-rbd-mirror.target

    [root@rbd-client ~]# systemctl stop ceph-rbd-mirror@site-a
    [root@rbd-client ~]# systemctl disable ceph-rbd-mirror@site-a
    [root@rbd-client ~]# systemctl disable ceph-rbd-mirror.target

4.10. 非同期更新および Ceph ブロックデバイスミラーリング

Ceph ブロックデバイスのミラーリングを使用してストレージクラスターを更新する場合は、『 Red Hat Ceph Storage Installation Guide』 の「更新」の手順に従います。更新が完了したら、Ceph ブロックデバイスインスタンスを再起動します。

注記

インスタンスの再起動に必要な順序はありません。Red Hat は、プライマリーイメージでプールを参照し、その後にミラーリングされたプールをポイントするインスタンスを再起動することを推奨します。

第5章 rbd カーネルモジュール

ストレージ管理者は、rbd カーネルモジュールを介して Ceph ブロックデバイスにアクセスできます。ブロックデバイスをマップおよびマッピング解除し、それらのマッピングを表示できます。また、rbd カーネルモジュールからイメージの一覧を取得できます。

重要

Red Hat Enterprise Linux(RHEL)以外の Linux ディストリビューション上のカーネルクライアントは許可されますが、サポート対象外となります。これらのカーネルクライアントの使用時にストレージクラスターで問題が見つかると、Red Hat は対処しますが、カーネルクライアントで根本的な原因が見つかった場合は、この問題はソフトウェアベンダーによる対応が必要になります。

5.1. 前提条件

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

5.2. イメージの一覧の取得

Ceph ブロックデバイスイメージの一覧を取得します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. ブロックデバイスイメージをマウントするには、まずイメージの一覧を返します。

    [root@rbd-client ~]# rbd list

5.3. ブロックデバイスのマッピング

rbd を使用して、イメージ名をカーネルモジュールにマッピングします。イメージ名、プール名、およびユーザー名を指定する必要があります。rbd は、まだ読み込まれていない場合は RBD カーネルモジュールを読み込みます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. イメージ名をカーネルモジュールにマップします。

    構文

    rbd device map POOL_NAME/IMAGE_NAME --id USER_NAME

    [root@rbd-client ~]# rbd device map rbd/myimage --id admin

  2. cephx 認証を使用する場合は、キーリングまたはシークレットが含まれるファイルのいずれかでシークレットを指定します。

    構文

    [root@rbd-client ~]# rbd device map POOL_NAME/IMAGE_NAME --id USER_NAME --keyring PATH_TO_KEYRING

    または

    [root@rbd-client ~]# rbd device map POOL_NAME/IMAGE_NAME --id USER_NAME --keyfile PATH_TO_FILE

5.4. マッピングされたブロックデバイスの表示

rbd コマンドを使用して、どのブロックデバイスイメージがカーネルモジュールにマッピングされているかを表示できます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. マップされたブロックデバイスを表示します。

    [root@rbd-client ~]# rbd device list

5.5. ブロックデバイスのマッピング解除

unmap オプションを使用し、デバイス名を指定して、rbd コマンドでブロックデバイスイメージをマッピング解除できます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. ブロックデバイスイメージのマッピングを解除します。

    構文

    rbd device unmap /dev/rbd/POOL_NAME/IMAGE_NAME

    [root@rbd-client ~]# rbd device unmap /dev/rbd/rbd/foo

第6章 Ceph ブロックデバイス Python モジュールの使用

rbd python モジュールは、Ceph ブロックデバイスイメージへのファイルのようなアクセスを提供します。この組み込みツールを使用するには、rbd モジュールおよび rados Python モジュールをインポートします。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ノードへのルートレベルのアクセス。

手順

  1. RADOS に接続し、IO コンテキストを開きます。

    cluster = rados.Rados(conffile='my_ceph.conf')
    cluster.connect()
    ioctx = cluster.open_ioctx('mypool')
  2. イメージの作成に使用する :class:rbd.RBD オブジェクトをインスタンス化します。

    rbd_inst = rbd.RBD()
    size = 4 * 1024**3  # 4 GiB
    rbd_inst.create(ioctx, 'myimage', size)
  3. イメージで I/O を実行するには、:class:rbd.Image オブジェクトをインスタンス化します。

    image = rbd.Image(ioctx, 'myimage')
    data = 'foo' * 200
    image.write(data, 0)

    これにより、イメージの最初の 600 バイトに「foo」が書き込まれます。データは :type:unicode - librbd にすることはできませ

  4. イメージ、IO コンテキスト、および RADOS への接続を閉じます。

    image.close()
    ioctx.close()
    cluster.shutdown()

    安全性を確保するには、これらの呼び出しはそれぞれ個別の :finally block に置く必要があります。

    import rados
    import rbd
    
    cluster = rados.Rados(conffile='my_ceph_conf')
    try:
        ioctx = cluster.open_ioctx('my_pool')
        try:
            rbd_inst = rbd.RBD()
            size = 4 * 1024**3  # 4 GiB
            rbd_inst.create(ioctx, 'myimage', size)
            image = rbd.Image(ioctx, 'myimage')
            try:
                data = 'foo' * 200
                image.write(data, 0)
            finally:
                image.close()
        finally:
            ioctx.close()
    finally:
        cluster.shutdown()

    これは複雑になる可能性があるため Rados 、Ioctx、 および Image クラスは、自動的に閉じたりシャットダウンするコンテキストマネージャーとして使用できます。上記の例をコンテキストマネージャーとして使用すると、以下のようになります。

    with rados.Rados(conffile='my_ceph.conf') as cluster:
        with cluster.open_ioctx('mypool') as ioctx:
            rbd_inst = rbd.RBD()
            size = 4 * 1024**3  # 4 GiB
            rbd_inst.create(ioctx, 'myimage', size)
            with rbd.Image(ioctx, 'myimage') as image:
                data = 'foo' * 200
                image.write(data, 0)

第7章 Ceph iSCSI ゲートウェイ

ストレージ管理者は、Red Hat Ceph Storage クラスターの iSCSI ゲートウェイをインストールし、設定できます。Ceph の iSCSI ゲートウェイを使用すると、従来のストレージエリアネットワーク(SAN)の機能と利点をすべて使用して、完全に統合されたブロックストレージインフラストラクチャーを効果的に実行できます。

7.1. Ceph iSCSI ゲートウェイの概要

従来は、Ceph ストレージクラスターへのブロックレベルのアクセスは、QEMU および librbd に限定されました。これは、OpenStack 環境内で導入するための主要なルーターです。Ceph ストレージクラスターへのブロックレベルのアクセスにより、iSCSI 標準を利用してデータストレージを提供できるようになりました。

iSCSI ゲートウェイは、Red Hat Ceph Storage を iSCSI 標準と統合して、RADOS Block Device(RBD)イメージを SCSI ディスクとしてエクスポートする高可用性(HA)iSCSI ターゲットを提供します。iSCSI プロトコルは、イニシエーターと呼ばれるクライアントが、TCP/IP ネットワークを介して、SCSI コマンドをターゲットとして知られる SCSI ストレージデバイスに送信することができます。これにより、Microsoft Windows などの異種クライアントが Red Hat Ceph Storage クラスターにアクセスできるようになります。

図7.1 Ceph iSCSI Gateway HA の設計

Ceph iSCSI HA 424879 1116 ECE 01

7.2. iSCSI ターゲットの要件

Red Hat Ceph Storage Highly Available(HA)iSCSI ゲートウェイソリューションには、OSD を検出するためのゲートウェイノード数、メモリー容量、タイマー設定の要件があります。

必要なノード数

最小 2 つの iSCSI ゲートウェイノードをインストールします。回復性と I/O 処理を増やすには、最大 4 つの iSCSI ゲートウェイノードをインストールします。

メモリー要件

RBD イメージのメモリーフットプリントは、サイズが大きくなる可能性があります。iSCSI ゲートウェイノードにマッピングされた各 RBD イメージは、約 90 MB のメモリーを使用します。iSCSI ゲートウェイノードに、各マッピングされた RBD イメージをサポートするのに十分なメモリーがあることを確認します。

OSD の検出

Ceph Monitors または OSD には特定の iSCSI ゲートウェイオプションはありませんが、OSD を検出するデフォルトのタイマーを減らしてイニシエーターのタイムアウトを減らすことが重要です。OSD を検出するタイマーの設定 が減少する指示に従って、イニシエーターのタイムアウトの可能性を低減します。

その他のリソース

7.3. iSCSI ゲートウェイのインストール

ストレージ管理者は、Ceph iSCSI ゲートウェイの利点を活用する前に、必要なソフトウェアパッケージをインストールする必要があります。Ceph iSCSI ゲートウェイは、Ansible デプロイメントツールを使用するか、コマンドラインインターフェース を使用してインストールできます。

各 iSCSI ゲートウェイは、Linux I/O ターゲットカーネルサブシステム(LIO)を実行して iSCSI プロトコルのサポートを提供します。LIO はユーザー空間パススルー(TCMU)を使用して Ceph librbd ライブラリーと対話し、RBD イメージを iSCSI クライアントに公開します。Ceph iSCSI ゲートウェイを使用すると、従来のストレージエリアネットワーク(SAN)の機能と利点をすべて使用して、完全に統合されたブロックストレージインフラストラクチャーを効果的に実行できます。

7.3.1. 前提条件

  • Red Hat Enterprise Linux 8 または 7.7 以降。
  • 稼働中の Red Hat Ceph Storage 4 クラスター

7.3.2. Ansible を使用した Ceph iSCSI ゲートウェイのインストール

Ansible ユーティリティーを使用してパッケージをインストールし、Ceph iSCSI ゲートウェイのデーモンを設定します。

前提条件

  • ceph-ansible パッケージがインストールされている Ansible 管理ノード。

手順

  1. iSCSI ゲートウェイノードで、Red Hat Ceph Storage 4 Tools リポジトリーを有効にします。詳細は、『 Red Hat Ceph Storage Installation Guide』の「Enabling the Red Hat Ceph Storage Repositories 」セクションを参照してください
  2. Ansible 管理ノードで、ゲートウェイグループの /etc/ansible/hosts ファイルにエントリーを追加します。iSCSI ゲートウェイを OSD ノードとコロケートする場合は、OSD ノードを [iscsigws] セクションに追加します。

    [iscsigws]
    ceph-igw-1
    ceph-igw-2
  3. Ansible は、iscsigws .yml.sample という名前の /usr/share/ceph-ansible/group_vars/ ディレクトリーに ファイルを配置します。iscsigws.yml. sample ファイルに iscsigws.yml という名前のファイルのコピー を作成します。
  4. 必要に応じて、iSCSI Gateway Variables セクションの Ansible 変数および説明を確認し、必要に応じて iscsigws.yml を更新します。

    警告

    ゲートウェイ設定の変更は、一度に 1 つのゲートウェイからのみサポートされます。複数のゲートウェイで変更を同時に実行しようとすると、設定が不安定になり、一貫性がなくなる可能性があります。

    警告

    Ansible は、ansible -playbook コマンドが使用される場合に group_vars /iscsigws.yml ファイルの設定に基づいて ceph-iscsi パッケージをインストールし、/etc/ceph/iscsi- gateway. cfg ファイルを作成し、更新します。「コマンドラインインターフェースを使用した iSCSI ゲートウェイのインストール」で説明されているコマンドラインインターフェースを使用して ceph-iscsi パッケージをインストールしている場合は、iscsi-gateway.cfg ファイルから既存の設定を group_vars/iscsigws.yml ファイルにコピーします。

  5. Ansible 管理ノードで、Ansible Playbook を実行します。

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

      [admin@ansible ~]$ cd /usr/share/ceph-ansible
      [admin@ansible ~]$ ansible-playbook site.yml
    • コンテナー のデプロイメント:

      [admin@ansible ~]$ cd /usr/share/ceph-ansible
      [admin@ansible ~]$ ansible-playbook site-docker.yml
      警告

      スタンドアロンの iSCSI ゲートウェイノードで、正しい Red Hat Ceph Storage 4 ソフトウェアリポジトリーが有効になっていることを確認します。これが利用できない場合、Ansible は誤ったパッケージをインストールする可能性があります。

  6. ターゲット、LUN、およびクライアントを作成するには、gwcli ユーティリティー または Red Hat Ceph Storage Dashboard を使用します。

    重要

    targetcli ユーティリティーを使用して設定を変更しないでください。これにより、ALUA の誤設定およびパスフェイルオーバーの問題が問題になります。データが破損する可能性があります。iSCSI ゲートウェイ全体で設定が一致しず、WWN 情報が一致しなくなる可能性があります。これにより、クライアントパスの問題が発生する可能性があります。

7.3.3. コマンドラインインターフェースを使用した Ceph iSCSI ゲートウェイのインストール

Ceph iSCSI ゲートウェイは、iSCSI ターゲットノードおよび Ceph クライアントノードです。Ceph iSCSI ゲートウェイは、スタンドアロンノードまたは Ceph Object Store Disk(OSD)ノードにコロケーションを設定することもできます。Ceph iSCSI ゲートウェイをインストールするには、以下の手順を実施します。

前提条件

  • Red Hat Enterprise Linux 8 または 7.7 以降
  • Red Hat Ceph Storage 4 クラスター以降
  • ストレージクラスターの全 Ceph Monitor ノード上で、ceph-mon サービスを root ユーザーとして再起動します。

    構文

    systemctl restart ceph-mon@MONITOR_HOST_NAME

    [root@mon ~]# systemctl restart ceph-mon@monitor1

  • Ceph iSCSI ゲートウェイが OSD ノードにコロケーションされていない場合には、/etc/ceph/ ディレクトリーにある Ceph 設定ファイルを、ストレージクラスター内の実行中の Ceph ノードからすべての iSCSI ゲートウェイノードにコピーします。Ceph 設定ファイルは、/etc/ceph/ の下にある iSCSI ゲートウェイノードに存在している必要があります。
  • すべての Ceph iSCSI ゲートウェイノードで、Ceph Tools リポジトリーを有効にします。詳細は、『インストールガイド』の「 Red Hat Ceph Storage リポジトリーの有効化 」セクションを参照してください
  • すべての Ceph iSCSI ゲートウェイノードで、Ceph コマンドラインインターフェースをインストールし、設定します。詳細は、『Red Hat Ceph Storage 4 インストールガイド』の「Ceph コマンドラインインターフェース のインストール」の章を参照してください
  • 必要な場合は、すべての Ceph iSCSI ノードのファイアウォールで TCP ポート 3260 および 5000 を開きます。
  • 新しい RADOS Block Device(RBD)を使用するか、既存の RADOS Block Device(RBD)を使用します。

手順

  1. すべての Ceph iSCSI ゲートウェイノードで、ceph-iscsi パッケージおよび tcmu- runner パッケージをインストールします。

    [root@iscsigw ~]# yum install ceph-iscsi tcmu-runner
    重要

    このパッケージの以前のバージョンが存在する場合は、新しいバージョンをインストールする前に削除してください。これらの新しいバージョンは、Red Hat Ceph Storage リポジトリーからインストールする必要があります。

  2. 必要に応じて、すべての Ceph iSCSI ゲートウェイノードで、必要に応じて OpenSSL ユーティリティーをインストールし、設定します。

    1. openssl パッケージをインストールします。

      [root@iscsigw ~]# yum install openssl
    2. プライマリー iSCSI ゲートウェイノードで、SSL キーを保持するディレクトリーを作成します。

      [root@iscsigw ~]# mkdir ~/ssl-keys
      [root@iscsigw ~]# cd ~/ssl-keys
    3. プライマリー iSCSI ゲートウェイノードで、証明書およびキーファイルを作成します。要求されたら環境情報を入力します。

      [root@iscsigw ~]# openssl req -newkey rsa:2048 -nodes -keyout iscsi-gateway.key -x509 -days 365 -out iscsi-gateway.crt
    4. プライマリー iSCSI ゲートウェイノードで PEM ファイルを作成します。

      [root@iscsigw ~]# cat iscsi-gateway.crt iscsi-gateway.key > iscsi-gateway.pem
    5. プライマリー iSCSI ゲートウェイノードで、公開鍵を作成します。

      [root@iscsigw ~]# openssl x509 -inform pem -in iscsi-gateway.pem -pubkey -noout > iscsi-gateway-pub.key
    6. プライマリー iSCSI ゲートウェイノードから、iscsi-gateway .crt、iscsi-gateway. pem、iscsi-gateway -pub.key、および iscsi-gateway.key ファイルを他の iSCSI ゲートウェイノードの /etc/ceph/ ディレクトリーにコピーします。
  3. Ceph iSCSI ゲートウェイノードで設定ファイルを作成し、これをすべての iSCSI ゲートウェイノードにコピーします。

    1. /etc/ceph/ ディレクトリーに iscsi-gateway.cfg という名前のファイルを作成します。

      [root@iscsigw ~]# touch /etc/ceph/iscsi-gateway.cfg
    2. iscsi-gateway.cfg ファイルを編集し、以下の行を追加します。

      構文

      [config]
      cluster_name = CLUSTER_NAME
      gateway_keyring = CLIENT_KEYRING
      api_secure = true
      trusted_ip_list = IP_ADDR,IP_ADDR

      [config]
      cluster_name = ceph
      gateway_keyring = ceph.client.admin.keyring
      api_secure = true
      trusted_ip_list = 192.168.0.10,192.168.0.11

    3. iscsi-gateway.cfg ファイルをすべての iSCSI ゲートウェイノードにコピーします。このファイルは、すべての iSCSI ゲートウェイノードで同一である必要があることに注意してください。
  4. すべての Ceph iSCSI ゲートウェイノードで、API サービスを有効にして起動します。

    [root@iscsigw ~]# systemctl enable rbd-target-api
    [root@iscsigw ~]# systemctl start rbd-target-api
    [root@iscsigw ~]# systemctl enable rbd-target-gw
    [root@iscsigw ~]# systemctl start rbd-target-gw
  5. 次に、ターゲット、LUN、およびクライアントを設定します。詳細は「 コマンドラインインターフェースを使用した iSCSI ターゲットの設定 」セクションを参照してください。

その他のリソース

7.3.4. その他のリソース

7.4. iSCSI ターゲットの設定

ストレージ管理者は、gwcli コマンドラインユーティリティー を使用して、ターゲット、LUN、およびクライアントを 設定 できます。iSCSI ターゲットの パフォーマンスを最適化 することもできます。gwcli reconfigure サブコマンドを 使用します。

警告

Red Hat は、Ceph iSCSI ゲートウェイツール(gwcli、ceph-ansible など)によってエクスポートされる Ceph ブロックデバイスイメージの管理をサポート ません。また、rbd コマンドを使用して、Ceph iSCSI ゲートウェイがエクスポートした RBD イメージの名前を変更または削除すると、不安定なストレージクラスターが発生する可能性があります。

警告

iSCSI ゲートウェイ設定から RBD イメージを削除する前に、オペレーティングシステムからストレージデバイスを削除する標準の手順に従ってください。詳細は、『Red Hat Enterprise Linux 7 の ストレージ 管理ガイド』 の「ストレージデバイスの削除 」または「Red Hat Enterprise Linux 8 の システム設計ガイド 」を参照してください。

7.4.1. 前提条件

  • Ceph iSCSI ゲートウェイソフトウェアのインストール

7.4.2. コマンドラインインターフェースを使用した iSCSI ターゲットの設定

Ceph iSCSI ゲートウェイは、iSCSI ターゲットノードおよび Ceph クライアントノードです。スタンドアロンノードで Ceph iSCSI ゲートウェイを設定するか、Ceph Object Storage Device(OSD)ノードとコロケートします。

警告

本ドキュメントまたは Red Hat サポートで指定されていない限り、gwcli reconfigure サブコマンドを使用して他のオプションを変更しないでください。

前提条件

  • Ceph iSCSI ゲートウェイソフトウェアのインストール

手順

  1. iSCSI ゲートウェイコマンドラインインターフェースを起動します。

    [root@iscsigw ~]# gwcli
  2. IPv4 アドレスまたは IPv6 アドレスを使用して iSCSI ゲートウェイを作成します。

    構文

    >/iscsi-targets create iqn.2003-01.com.redhat.iscsi-gw:_target_name_
    > goto gateways
    > create ISCSI_GW_NAME IP_ADDR_OF_GW
    > create ISCSI_GW_NAME IP_ADDR_OF_GW

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

    注記

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

  3. Ceph ブロックデバイスを追加します。

    構文

    > cd /disks
    >/disks/ create POOL_NAME image=IMAGE_NAME size=IMAGE_SIZE_m|g|t

    > cd /disks
    >/disks/ create rbd image=disk_1 size=50g

    注記

    プールまたはイメージ名でピリオド(.)を使用しないでください。

  4. クライアントを作成します。

    構文

    > goto hosts
    > create iqn.1994-05.com.redhat:_client_name_
    > auth use username=USER_NAME password=PASSWORD

    > goto hosts
    > create iqn.1994-05.com.redhat:rh7-client
    > auth username=iscsiuser1 password=temp12345678

    重要

    Red Hat は、Challenge Handshake Authentication Protocol(CHAP)を有効にし、一部の CHAP を無効にしたクライアントの組み合わせをサポートしません。すべてのクライアントは、CHAP を有効にするか、CHAP を無効にしている必要があります。デフォルトの動作では、イニシエーター名のみがイニシエーターを認証します。

    イニシエーターがターゲットにログインできない場合は、イニシエーターに対して CHAP 認証が正しく設定されないことがあります。以下に例を示します。

    o- hosts ................................ [Hosts: 2: Auth: MISCONFIG]

    ホスト レベルで次のコマンドを実行して、すべての CHAP 認証をリセットします。

    /> goto hosts
    /iscsi-target...csi-igw/hosts> auth nochap
    ok
    ok
    /iscsi-target...csi-igw/hosts> ls
    o- hosts ................................ [Hosts: 2: Auth: None]
      o- iqn.2005-03.com.ceph:esx ........... [Auth: None, Disks: 4(310G)]
      o- iqn.1994-05.com.redhat:rh7-client .. [Auth: None, Disks: 0(0.00Y)]
  5. クライアントにディスクを追加します。

    構文

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

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

  6. API が SSL を正しく使用していることを確認するには、https の場合は /var/ log /rbd-target-api.log または /var/log/rbd-target-api. log にある rbd-target-api.log を検索します。以下に例を示します。

    Aug 01 17:27:42 test-node.example.com python[1879]:  * Running on https://0.0.0.0:5000/
  7. Ceph ISCSI ゲートウェイが機能していることを確認します。

    /> goto gateways
    /iscsi-target...-igw/gateways> ls
    o- gateways ............................ [Up: 2/2, Portals: 2]
      o- ceph-gw-1  ........................ [ 10.172.19.21 (UP)]
      o- ceph-gw-2  ........................ [ 10.172.19.22 (UP)]

    ステータスが UNKNOWN である場合は、ネットワークの問題と設定の誤りを確認します。ファイアウォールを使用している場合は、適切な TCP ポートが開いていることを確認してください。iSCSI ゲートウェイが trusted_ip_list オプションに一覧 表示されていることを確認します。rbd-target-api サービスが iSCSI ゲートウェイノードで実行されていることを確認します。

  8. 必要に応じて、max_data_area_mb オプションを再設定します。

    構文

    >/disks/ reconfigure max_data_area_mb NEW_BUFFER_SIZE

    >/disks/ reconfigure max_data_area_mb 64

    注記

    max_data_area_mb オプションは、iSCSI ターゲットと Ceph クラスターとの間で SCSI コマンドデータを渡するために各イメージが使用できるメガバイト単位のメモリー容量を制御します。この値が小さすぎると、キューのフルリトライが過剰になる可能性があり、パフォーマンスに影響します。値が大きすぎると、1 つのディスクでシステムメモリーの使用が過剰になる可能性があり、他のサブシステムの割り当てに失敗する可能性があります。max_data_area_mb オプションのデフォルト値は 8 です。

  9. iSCSI イニシエーターを設定します。

その他のリソース

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

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

警告

Red Hat サポート、または本書で指定されているように指示された場合のみ、これらの設定を変更します。

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

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

  • max_data_area_mb
  • cmdsn_depth
  • immediate_data
  • initial_r2t
  • max_outstanding_r2t
  • first_burst_length
  • max_burst_length
  • max_recv_data_segment_length
  • max_xmit_data_segment_length

その他のリソース

7.4.4. OSD を検出するためのタイマー設定の低速

OSD の検出にタイマー設定を減らしなければならない場合があります。たとえば、Red Hat Ceph Storage を iSCSI ゲートウェイとして使用する場合は、OSD を検出するためのタイマー設定を減らすことで、イニシエーターのタイムアウトを軽減することができます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • Ansible 管理ノードへのアクセス

手順

  1. 新しいタイマー設定を使用するように Ansible を設定します。

    1. Ansible 管理ノードで、以下のような group _vars/all.yml ファイルに ceph_ conf_overrides セクションを追加するか、既存の ceph_conf_overrides セクションを以下のように編集します。

      ceph_conf_overrides:
           osd:
             osd_client_watch_timeout: 15
             osd_heartbeat_grace: 20
             osd_heartbeat_interval: 5

      上記の設定は、Anisable Playbook の実行時に OSD ノードの ceph.conf 設定ファイルに追加されます。

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

      [admin@ansible ~]$ cd /usr/share/ceph-ansible
    3. Ansible を使用して ceph.conf ファイルを更新し、すべての OSD ノードで OSD デーモンを再起動します。Ansible 管理ノードで、以下のコマンドを実行します。

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

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

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

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

  2. タイマー設定が ceph_conf_overrides で設定されているのと同じであることを確認します。

    構文

    ceph daemon osd.OSD_ID config get osd_client_watch_timeout
    ceph daemon osd.OSD_ID config get osd_heartbeat_grace
    ceph daemon osd.OSD_ID config get osd_heartbeat_interval

    [root@osd ~]# ceph daemon osd.0 config get osd_client_watch_timeout
    {
        "osd_client_watch_timeout": "15"
    }
    
    [root@osd ~]#  ceph daemon osd.0 config get osd_heartbeat_grace
    {
        "osd_heartbeat_grace": "20"
    }
    
    [root@osd ~]# ceph daemon osd.0 config get osd_heartbeat_interval
    {
        "osd_heartbeat_interval": "5"
    }

  3. 必要に応じて、OSD デーモンをすぐに再起動できない場合は、Ceph Monitor ノードまたはすべての Ceph OSD ノード上で直接オンライン更新を行うことができます。OSD デーモンを再起動したら、上記のように Ansible を使用して新しいタイマー設定を ceph.conf に追加し、設定は再起動後も維持されます。

    1. Ceph Monitor ノードから OSD タイマー設定をオンラインで更新するには、以下を実行します。

      構文

      ceph tell osd.OSD_ID injectargs '--osd_client_watch_timeout 15'
      ceph tell osd.OSD_ID injectargs '--osd_heartbeat_grace 20'
      ceph tell osd.OSD_ID injectargs '--osd_heartbeat_interval 5'

      [root@mon ~]# ceph tell osd.0 injectargs '--osd_client_watch_timeout 15'
      [root@mon ~]# ceph tell osd.0 injectargs '--osd_heartbeat_grace 20'
      [root@mon ~]# ceph tell osd.0 injectargs '--osd_heartbeat_interval 5'

    2. Ceph OSD ノードから OSD タイマー設定をオンラインで更新するには、以下を実行します。

      構文

      ceph daemon osd.OSD_ID config set osd_client_watch_timeout 15
      ceph daemon osd.OSD_ID config set osd_heartbeat_grace 20
      ceph daemon osd.OSD_ID config set osd_heartbeat_interval 5

      [root@osd ~]# ceph daemon osd.0 config set osd_client_watch_timeout 15
      [root@osd ~]# ceph daemon osd.0 config set osd_heartbeat_grace 20
      [root@osd ~]# ceph daemon osd.0 config set osd_heartbeat_interval 5

その他のリソース

7.4.5. その他のリソース

  • Red Hat Ceph Storage Dashboard を使用した iSCSI ターゲットの設定に関する詳細は、『 Red Hat Ceph Storage Dashboard Guide』の「 iSCSI ターゲットの作成 」セクションを参照してください

7.5. iSCSI イニシエーターの設定

iSCSI イニシエーターを設定して、以下のプラットフォームで Ceph iSCSI ゲートウェイに接続することができます。

7.5.1. Red Hat Enterprise Linux の iSCSI イニシエーターの設定

前提条件

  • Red Hat Enterprise Linux 7.7 以降
  • パッケージ iscsi-initiator-utils-6.2.0.873-35 以降が インストールされていること。
  • パッケージ device-mapper-multipath-0.4.9-99 以降がインストールされている。

手順

  1. iSCSI イニシエーターおよびマルチパスツールをインストールします。

    [root@rhel ~]# yum install iscsi-initiator-utils
    [root@rhel ~]# yum install device-mapper-multipath
  2. /etc/iscsi/initiatorname.iscsi ファイルを編集してイニシエーター名を設定します。イニシエーター名は、gwcli コマンド を使用して初期設定時に使用されたイニシエーター名と一致する必要があることに注意してください。
  3. マルチパス I/O を設定します。

    1. デフォルトの /etc/multipath.conf ファイルを作成し、multipathd サービスを有効にします。

      [root@rhel ~]# mpathconf --enable --with_multipathd y
    2. 以下のように /etc/multipath.conf ファイルを更新します。

      devices {
              device {
                      vendor                 "LIO-ORG"
                      product                "TCMU device"
                      hardware_handler       "1 alua"
                      path_grouping_policy   "failover"
                      path_selector          "queue-length 0"
                      failback               60
                      path_checker           tur
                      prio                   alua
                      prio_args              exclusive_pref_bit
                      fast_io_fail_tmo       25
                      no_path_retry          queue
              }
      }
    3. multipathd サービスを再起動します。

      [root@rhel ~]# systemctl reload multipathd
  4. CHAP および iSCSI の検出およびログインを設定します。

    1. /etc/iscsi/iscsid.conf ファイルを更新して、CHAP ユーザー名およびパスワードを指定します。以下に例を示します。

      node.session.auth.authmethod = CHAP
      node.session.auth.username = user
      node.session.auth.password = password
    2. ターゲットポータルを検出します。

      構文

      iscsiadm -m discovery -t st -p IP_ADDR

    3. ターゲットにログインします。

      構文

      iscsiadm -m node -T TARGET -l

  5. マルチパス I/O 設定を表示します。multipathd デーモンは、multipath.conf ファイルの設定に基づいてデバイスを自動的に設定します。

    1. multipath コマンドを使用して、フェイルオーバー設定のデバイス設定と、各パスの優先度グループを表示します。以下に例を示します。

      [root@rhel ~]# multipath -ll
      mpathbt (360014059ca317516a69465c883a29603) dm-1 LIO-ORG,TCMU device
      size=1.0G features='0' hwhandler='1 alua' wp=rw
      |-+- policy='queue-length 0' prio=50 status=active
      | `- 28:0:0:1 sde  8:64  active ready running
      `-+- policy='queue-length 0' prio=10 status=enabled
        `- 29:0:0:1 sdc  8:32  active ready running

      multipath -ll output prio の値は ALUA の状態を示します。prio=50 は、ALUA Active-Optimized 状態で所有する iSCSI ゲートウェイへのパスを示し、prio=10 は Active-non-Optimized パスであることを示します。status フィールドは、使用中のパスを示します。active は、現在使用中のパスを示し、有効 になっている場合はフェイルオーバーパスを示し ます

    2. multipath -ll 出力の sde などのデバイス名を iSCSI ゲートウェイに一致させるには、次のコマンドを実行します。

      [root@rhel ~]# iscsiadm -m session -P 3

      Persistent Portal の値は、gwcli ユーティリティー に一覧表示される iSCSI ゲートウェイに割り当てられる IP アドレスです。

7.5.2. Red Hat Virtualization の iSCSI イニシエーターの設定

前提条件

  • Red Hat Virtualization 4.1
  • すべての Red Hat Virtualization ノード上で設定された MPIO デバイス
  • iscsi-initiator-utils-6.2.0.873-35 パッケージ以降
  • device-mapper-multipath-0.4.9-99 パッケージまたはそれ以降

手順

  1. マルチパス I/O を設定します。

    1. デフォルトの /etc/multipath.conf ファイルを作成し、multipathd サービスを有効にします。

      [root@rhv ~]# mpathconf --enable --with_multipathd y
    2. 以下のように /etc/multipath.conf ファイルを更新します。

      devices {
              device {
                      vendor                 "LIO-ORG"
                      product                "TCMU device"
                      hardware_handler       "1 alua"
                      path_grouping_policy   "failover"
                      path_selector          "queue-length 0"
                      failback               60
                      path_checker           tur
                      prio                   alua
                      prio_args              exclusive_pref_bit
                      fast_io_fail_tmo       25
                      no_path_retry          queue
              }
      }
    3. multipathd サービスを再起動します。

      [root@rhv ~]# systemctl reload multipathd
  2. Storage resource タブをクリックして、既存のストレージドメインを一覧表示します。
  3. 新規ドメイン ボタンをクリックして、新規ドメイン 画面を開きます。
  4. 新しいストレージ ドメインの名前 を入力します。
  5. データセンタードロップダウンメニューを 使用して、データセンター を選択します。
  6. ドロップダウンメニューを使用して、Domain Function および Storage Type を選択します。選択したドメイン機能と互換性のないストレージドメインタイプは利用できません。
  7. Use Host フィールドでアクティブなホストを選択します。これがデータセンターの最初のデータドメインではない場合は、データセンターの✓ ホストを選択する必要があります。
  8. 新規ドメイン ウィンドウで、iSCSI がストレージタイプとして選択されると、未使用の LUN で既知のターゲットが自動的に表示されます。ストレージを追加するターゲットが一覧にない場合は、ターゲット検出を使用して検索することができます。それ以外の場合は、次の手順に進みます。

    1. ターゲットの 検出をクリックして、ターゲット検出オプションを有効に します。ターゲットの検出およびログイン時に、新規ドメイン ウインドウには、その環境によって未使用の LUN を持つターゲットが自動的に表示されます。環境外の LUN も表示されることに注意してください。Discover Targets オプションを使用して、多くのターゲットに LUN を追加するか、または複数のパスを同じ LUN に追加できます。
    2. アドレス フィールド に、iSCSI ホストの完全修飾ドメイン名または IP アドレスを入力します。
    3. Port フィールド でターゲットを参照するときに、ホストに接続するポートを入力します。デフォルトは 3260 です。
    4. ストレージのセキュア化にチャレンジハンドシェイク認証プロトコル(CHAP)を使用している場合は、ユーザー認証 チェックボックスを選択します。CHAP ユーザー名と CHAP パスワード を入力します。
    5. Discover ボタンをクリックします。
    6. 検出結果から使用するターゲットを選択し、ログイン ボタンをクリックします。次に、Login All をクリックして、検出されたすべてのターゲットにログインします。

      重要

      複数のパスアクセスが必要な場合は、必要なすべてのパスでターゲットを検出し、ログインするようにしてください。ストレージドメインを変更して追加のパスを追加することは、現在サポートされていません。

  9. 目的のターゲットの横にある + ボタンをクリックします。これにより、エントリーが拡張され、ターゲットに接続されている未使用の LUN が表示されます。
  10. ストレージドメインの作成に使用する各 LUN のチェックボックスを選択します。
  11. 必要に応じて、高度なパラメーターを設定できます。

    1. 高度なパラメーター をクリックします。
    2. Warning Low Space Indicator フィールドにパーセンテージ値を入力します。ストレージドメインで利用可能な空き領域がこのパーセンテージを下回ると、警告メッセージがユーザーに表示され、ログに記録されます。
    3. Critical Space Action Blocker フィールドに GB の値を入力します。ストレージドメインで利用可能な空き領域がこの値を下回ると、エラーメッセージがユーザーに表示されてログに記録され、一時的に領域を消費する新しいアクションがブロックされます。
    4. Wipe After Delete チェックボックスを選択して、削除後の消去 を有効にします。このオプションは、ドメインの作成後に編集できますが、すでに存在するディスクプロパティーを 削除した後に消去 は変更しません。
    5. Discard After Delete チェックボックスを 選択して、削除後の破棄を有効にします。このオプションは、ドメインの作成後に編集できます。このオプションは、ストレージドメインをブロックする場合にのみ利用できます。
  12. OK をクリックし てストレージドメインを作成し、ウィンドウを閉じます。

7.5.3. Microsoft Windows の iSCSI イニシエーターの設定

前提条件

  • Microsoft Windows Server 2016

手順

  1. iSCSI イニシエーターをインストールし、検出および設定を設定します。

    1. iSCSI イニシエータードライバーおよび MPIO ツールをインストールします。
    2. MPIO プログラムを起動し、Discover Multi-Paths タブをクリックし、iSCSI デバイスの追加サポートチェックボックスを 選択して Add をクリックします。
    3. MPIO プログラムを再起動します。
    4. iSCSI イニシエータープロパティーウィンドウで、検出 タブ 1 ターゲットポータルを追加します。IP アドレスまたは DNS 名を入力します。 2 およびポート 3 Ceph iSCSI ゲートウェイでは、以下のようになります。

      iSCSI 検出タブ
    5. Targets タブで 1 ターゲットを選択し、Connectをクリックします。 2 :

      iSCSI ターゲットタブ
    6. Connect To Target ウィンドウで、マルチパスの有効化 オプションを選択します。 1 をクリックし、詳細 ボタンをクリックします。 2 :

      iSCSI をターゲット mod に接続します。
    7. Connect using セクションで、Target portal IPを選択します。 1 .Enable CHAP login on を選択します。 2 Name および Target secret の値を入力します。 3 Ceph iSCSI クライアントのクレデンシャルセクションから、OKをクリックします。 4 :

      iSCSI Advanced window mod
      重要

      Windows Server 2016 は 12 バイト未満の CHAP シークレットを許可しません。

    8. iSCSI ゲートウェイの設定時に定義されたターゲットポータルごとに、以前の 2 つの手順を繰り返します。
    9. イニシエーター名が、初期設定中に使用されるイニシエーター名とは異なる場合は、イニシエーター名の名前を変更します。iSCSI イニシエータープロパティー画面Configuration タブで 1 変更 ボタンをクリックします。 2 イニシエーター名の名前を変更するには、次のコマンドを実行します。

      iSCSI windows イニシエータープロパティー mod
  2. マルチパス I/O を設定します。PowerShell では、PDORemovePeriod コマンドを 使用 して MPIO 負荷分散ポリシーと mpclaim コマンド を使用して負荷分散ポリシーを設定します。iSCSI イニシエーターツールが、残りのオプションを設定します。

    注記

    Red Hat は、PDORemovePeriod オプション を PowerShell から 120 秒に増やすことを推奨します。この値をアプリケーションに基づいて調整する必要がある場合があります。すべてのパスがダウンし、120 秒の期限が切れると、オペレーティングシステムは I/O 要求の失敗を開始します。

    Set-MPIOSetting -NewPDORemovePeriod 120
    1. フェイルオーバーポリシーの設定

      mpclaim.exe -l -m 1
    2. フェイルオーバーポリシーの確認

      mpclaim -s -m
      MSDSM-wide Load Balance Policy: Fail Over Only
    3. Targets タブにある iSCSI イニシエーターツールの使用 1 デバイスをクリックします。 ボタン 2 :

      iSCSI ターゲットタブ2 mod
    4. デバイス画面で、 ディスクを選択します。 1 次に、MPIO…​ ボタン 2 :

      iSCSI デバイス mpio mod
    5. Device Details ウィンドウには、各ターゲットポータルへのパスが表示されます。Load Balancing Policy Fail Over Only を選択する必要があります。

      MPIO set failover only mod
    6. PowerShell から マルチパス 設定を表示します。

      mpclaim -s -d MPIO_DISK_ID

      MPIO_DISK_ID は、適切なディスク識別子に置き換えます。

      注記

      アクティブ/最適化パスは 1 つあります。これは、LUN を所有する iSCSI ゲートウェイノードへのパスで、相互の iSCSI ゲートウェイノードにアクティブ/非最適化のパスがあります。

      MPclaim 出力 mod
  3. 必要に応じて、設定を調整します。以下のレジストリー設定の使用を検討してください。

    • Windows ディスクタイムアウト

      key

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk

      TimeOutValue = 65

    • Microsoft iSCSI イニシエータードライバー

      key

      HKEY_LOCAL_MACHINE\\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318}\<Instance_Number>\Parameters

      LinkDownTime = 25
      SRBTimeoutDelta = 15

7.5.4. VMware ESXi の iSCSI イニシエーターの設定

前提条件

  • 仮想マシン互換性 6.5 または 6.7 および VMFS 6 を使用した VMware ESXi 6.5 および 6.7u3b
  • VMware ホストクライアントへのアクセス
  • VMware ESXi ホストへの root アクセスによる esxcli コマンド 実行

手順

  1. HardwareAcceleratedMove( XCOPY )を無効にします。

    > esxcli system settings advanced set --int-value 0 --option /DataMover/HardwareAcceleratedMove
  2. iSCSI ソフトウェアを有効にします。ペインから ストレージをクリックします1 .Adapters タブを選択します。 2 .iSCSI の設定をクリックします。 3 :

    ESX Web クライアントストレージのメインモード
  3. Name & alias セクションのイニシエーター名を確認します。 1 .

    ESX Web クライアント設定 iscsi main mod step2
  4. イニシエーター名が、gwcli を使用してクライアントの作成時にクライアントを作成する際に使用されたイニシエーター名とは異なる場合は イニシエーター名(VMware ESX ホストから)を変更し ます

    1. iSCSI ソフトウェアのアダプター名を取得します。

      > esxcli iscsi adapter list
      > Adapter  Driver     State   UID            Description
      > -------  ---------  ------  -------------  ----------------------
      > vmhba64  iscsi_vmk  online  iscsi.vmhba64  iSCSI Software Adapter
    2. イニシエーター名を設定します。

      構文

      > esxcli iscsi adapter set -A ADAPTOR_NAME -n INITIATOR_NAME

      > esxcli iscsi adapter set -A vmhba64 -n iqn.1994-05.com.redhat:rh7-client

  5. CHAP を設定します。CHAP 認証 セクションを展開します。 1 .「ターゲットで必要な場合以外は CHAP は使用しない」を選択します。 2 .CHAP および シークレットを入力します。 3 初期セットアップで使用された認証情報。相互 CHAP 認証 セクションを確認します。 4 「 CHAP」が選択されていない。

    ESX web クライアントchap mod step3
    警告

    VMware Host Client のバグにより、CHAP 設定は最初に使用されません。Ceph iSCSI ゲートウェイノードでは、カーネルログには、このバグの識別として以下のエラーが含まれます。

    > kernel: CHAP user or password not set for Initiator ACL
    > kernel: Security negotiation failed.
    > kernel: iSCSI Login negotiation failed.

    このバグを回避するには、esxcli コマンド を使用して CHAP を設定します。authname 引数 は vSphere Web クライアントの 名前 です。

    > esxcli iscsi adapter auth chap set --direction=uni --authname=myiscsiusername --secret=myiscsipassword --level=discouraged -A vmhba64
  6. iSCSI 設定を構成します。高度な設定の拡張 1 .RecoveryTimeout を 25 に設定します。 2 .

    ESX web クライアント iscsi リカバリータイムアウト mod step4
  7. 検出アドレスを設定します。動的ターゲット セクションで 1動的ターゲットの追加」をクリックします。 2 .Addressの下にある 3 Ceph iSCSI ゲートウェイのいずれかに IP アドレスを追加します。1 つの IP アドレスのみを追加する必要があります。最後に、Save configuration ボタンをクリックします。 4 .メインインターフェースから、Devices タブで RBD イメージが表示されます。

    ESX Web クライアント設定 iscsi main mod step5
    注記

    LUN は、ALUA SATP および MRU─ を使用して自動的に設定されます。他の SATP および✓ は使用しないでください。これは、esxcli コマンド で確認できます。

    構文

    esxcli storage nmp path list -d eui.DEVICE_ID

    DEVICE_ID は適切なデバイス識別子に置き換えます。

  8. マルチパスが正しく設定されていることを確認します。

    1. デバイスを一覧表示します。

      > esxcli storage nmp device list | grep iSCSI
         Device Display Name: LIO-ORG iSCSI Disk (naa.6001405f8d087846e7b4f0e9e3acd44b)
         Device Display Name: LIO-ORG iSCSI Disk (naa.6001405057360ba9b4c434daa3c6770c)

    2. 前の手順で、Ceph iSCSI ディスクのマルチパス情報を取得します。

      > esxcli storage nmp path list -d naa.6001405f8d087846e7b4f0e9e3acd44b
      
      iqn.2005-03.com.ceph:esx1-00023d000001,iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw,t,1-naa.6001405f8d087846e7b4f0e9e3acd44b
         Runtime Name: vmhba64:C0:T0:L0
         Device: naa.6001405f8d087846e7b4f0e9e3acd44b
         Device Display Name: LIO-ORG iSCSI Disk (naa.6001405f8d087846e7b4f0e9e3acd44b)
         Group State: active
         Array Priority: 0
         Storage Array Type Path Config: {TPG_id=1,TPG_state=AO,RTP_id=1,RTP_health=UP}
         Path Selection Policy Path Config: {current path; rank: 0}
      
      iqn.2005-03.com.ceph:esx1-00023d000002,iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw,t,2-naa.6001405f8d087846e7b4f0e9e3acd44b
         Runtime Name: vmhba64:C1:T0:L0
         Device: naa.6001405f8d087846e7b4f0e9e3acd44b
         Device Display Name: LIO-ORG iSCSI Disk (naa.6001405f8d087846e7b4f0e9e3acd44b)
         Group State: active unoptimized
         Array Priority: 0
         Storage Array Type Path Config: {TPG_id=2,TPG_state=ANO,RTP_id=2,RTP_health=UP}
         Path Selection Policy Path Config: {non-current path; rank: 0}

      出力例から、各パスには、以下の部分を含む iSCSI 名または SCSI 名があります。

      イニシエーター名 = iqn.2005-03.com.ceph:esx1 ISID = 00023 d000002 Target name = iqn.─-01.com.redhat.iscsi-gw:iscsi-igw Target port group = 2 Device id = naa.6001405f8d087846e7b4e9e9acd44b

      Group Stateactive の値は、iSCSI ゲートウェイへの Active-Optimized パスであることを示します。gwcli コマンド 、iSCSI ゲートウェイの所有者として アクティブ を一覧表示します。パスの残りの部分には Group State の値が最適 されず、フェイルオーバーパスになります( アクティブな パスが dead 状態になる場合)。

  9. 各 iSCSI ゲートウェイへのパスと一致するには、次のコマンドを実行します。

    > esxcli iscsi session connection list
    vmhba64,iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw,00023d000001,0
       Adapter: vmhba64
       Target: iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw
       ISID: 00023d000001
       CID: 0
       DataDigest: NONE
       HeaderDigest: NONE
       IFMarker: false
       IFMarkerInterval: 0
       MaxRecvDataSegmentLength: 131072
       MaxTransmitDataSegmentLength: 262144
       OFMarker: false
       OFMarkerInterval: 0
       ConnectionAddress: 10.172.19.21
       RemoteAddress: 10.172.19.21
       LocalAddress: 10.172.19.11
       SessionCreateTime: 08/16/18 04:20:06
       ConnectionCreateTime: 08/16/18 04:20:06
       ConnectionStartTime: 08/16/18 04:30:45
       State: logged_in
    
    vmhba64,iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw,00023d000002,0
       Adapter: vmhba64
       Target: iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw
       ISID: 00023d000002
       CID: 0
       DataDigest: NONE
       HeaderDigest: NONE
       IFMarker: false
       IFMarkerInterval: 0
       MaxRecvDataSegmentLength: 131072
       MaxTransmitDataSegmentLength: 262144
       OFMarker: false
       OFMarkerInterval: 0
       ConnectionAddress: 10.172.19.22
       RemoteAddress: 10.172.19.22
       LocalAddress: 10.172.19.12
       SessionCreateTime: 08/16/18 04:20:06
       ConnectionCreateTime: 08/16/18 04:20:06
       ConnectionStartTime: 08/16/18 04:30:41
       State: logged_in

    パス名と ISID 値に一致し、RemoteAddress の値 所有する iSCSI ゲートウェイの IP アドレスになります。

7.6. iSCSI サービスの管理

ceph-iscsi パッケージは、設定管理ロジックと、rbd-target-gw サービスおよび rbd-target -api systemd サービスをインストールします。

rbd-target-api サービスは、起動時に Linux iSCSI ターゲットの状態を復元し、gwcli Red Hat Ceph Storage Dashboard などのツールから ceph-iscsi REST API 呼び出しに応答します。rbd-target-gw サービスは、Prometheus プラグインを使用してメトリクスを提供します。

rbd-target-api サービスは、Linux カーネルのターゲットレイヤーの唯一のユーザーであることを前提としています。rbd-target-api を使用する場合は、targetcli パッケージでインストールされた target サービスを使用しないでください。Ansible は、Ceph iSCSI ゲートウェイのインストール時に targetcli ターゲットサービスを自動的に無効にします。

手順

  1. サービスを開始するには、次のコマンドを実行します。

    # systemctl start rbd-target-api
    # systemctl start rbd-target-gw
  2. サービスを再起動するには、次のコマンドを実行します。

    # systemctl restart rbd-target-api
    # systemctl restart rbd-target-gw
  3. サービスをリロードするには、次のコマンドを実行します。

    # systemctl reload rbd-target-api
    # systemctl reload rbd-target-gw

    リロード 要求は、rbd-target-api で設定を再読み込みし、現在の稼働中の環境に適用します。変更は Ansible からすべての iSCSI ゲートウェイノードに並行してデプロイされるため、通常は必須ではありません。

  4. サービスを停止するには、以下を実行します。

    # systemctl stop rbd-target-api
    # systemctl stop rbd-target-gw

    stop 要求はゲートウェイのポータルインターフェースを閉じ、クライアントへの接続を破棄し、現在の Linux iSCSI ターゲット設定をカーネルから消去します。これにより、iSCSI ゲートウェイがクリーンな状態に戻ります。クライアントが切断されると、クライアント側のマルチパスレイヤーにより、アクティブな I/O が他の iSCSI ゲートウェイに再スケジュールされます。

7.7. iSCSI ゲートウェイの追加

ストレージ管理者は、gwcli コマンドラインツール または Red Hat Ceph Storage Dashboard を使用して、初期 2 つの iSCSI ゲートウェイを 4 つの iSCSI ゲートウェイに拡張できます。iSCSI ゲートウェイを追加すると、負荷分散およびフェイルオーバーのオプションを使用する際の柔軟性が向上し、冗長性が高まります。

7.7.1. 前提条件

  • 稼働中の Red Hat Ceph Storage 4 クラスター
  • スペアノードまたは既存の OSD ノード
  • root 権限

7.7.2. Ansible を使用した iSCSI ゲートウェイの追加

Ansible 自動化ユーティリティーを使用して、iSCSI ゲートウェイを追加できます。この手順では、2 つの iSCSI ゲートウェイのデフォルトインストールを 4 つの iSCSI ゲートウェイに展開します。スタンドアロンノードで iSCSI ゲートウェイを設定するか、既存の OSD ノードとコロケートすることができます。

前提条件

  • Red Hat Enterprise Linux 7.7 以降
  • 稼働中の Red Hat Ceph Storage クラスター
  • iSCSI ゲートウェイソフトウェアのインストール
  • Ansible 管理ノードで root ユーザーにアクセス可能である。
  • 新規ノードで root ユーザーにアクセス可能である。

手順

  1. 新しい iSCSI ゲートウェイノードで、Red Hat Ceph Storage Tools リポジトリーを有効にします。

    Red Hat Enterprise Linux 7

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

    Red Hat Enterprise Linux 8

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

  2. ceph-iscsi-config パッケージをインストールします。

    [root@iscsigw ~]# yum install ceph-iscsi-config
  3. ゲートウェイグループの /etc/ansible/hosts ファイルの一覧に追加します。

    [iscsigws]
    ...
    ceph-igw-3
    ceph-igw-4

    注記

    iSCSI ゲートウェイを OSD ノードとコロケートする場合は、OSD ノードを [iscsigws] セクションに追加します。

  4. ceph-ansible ディレクトリーに移動します。

    [root@ansible ~]# cd /usr/share/ceph-ansible
  5. Ansible 管理ノードで、適切な Ansible Playbook を実行します。

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

      [root@ansible ~]# ansible-playbook site.yml
    • コンテナー のデプロイメント:

      [root@ansible ~]# ansible-playbook site-docker.yml
    重要

    gateway_ip_list オプションに IP アドレスを指定する必要があります。IPv4 アドレスと IPv6 アドレスを混在させることはできません。

  6. iSCSI イニシエーターから、新たに追加された iSCSI ゲートウェイを使用するように再ログインします。

その他のリソース

7.7.3. gwcli を 使用 した iSCSI ゲートウェイの追加

gwcli コマンドラインツールを使用 て、iSCSI ゲートウェイを追加できます。この手順では、2 つの iSCSI ゲートウェイのデフォルトを 4 つの iSCSI ゲートウェイに展開します。

前提条件

  • Red Hat Enterprise Linux 7.7 以降
  • 稼働中の Red Hat Ceph Storage クラスター
  • iSCSI ゲートウェイソフトウェアのインストール
  • root ユーザーが新規ノードまたは OSD ノードにアクセスできること。

手順

  1. Ceph iSCSI ゲートウェイが OSD ノードにコロケーションされていない場合には、/etc/ceph/ ディレクトリーにある Ceph 設定ファイルを、ストレージクラスター内の実行中の Ceph ノードから新しい iSCSI ゲートウェイノードにコピーします。Ceph 設定ファイルは、/etc/ceph/ ディレクトリーの iSCSI ゲートウェイノードに存在している必要があります。
  2. Ceph コマンドラインインターフェースのインストールおよび設定
  3. 新しい iSCSI ゲートウェイノードで、Red Hat Ceph Storage Tools リポジトリーを有効にします。

    Red Hat Enterprise Linux 7

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

    Red Hat Enterprise Linux 8

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

  4. ceph-iscsi パッケージおよび tcmu- runner パッケージをインストールします。

    Red Hat Enterprise Linux 7

    [root@iscsigw ~]# yum install ceph-iscsi tcmu-runner

    Red Hat Enterprise Linux 8

    [root@iscsigw ~]# dnf install ceph-iscsi tcmu-runner

    1. 必要に応じて、openssl パッケージをインストールします。

      Red Hat Enterprise Linux 7

      [root@iscsigw ~]# yum install openssl

      Red Hat Enterprise Linux 8

      [root@iscsigw ~]# dnf install openssl

  5. 既存の iSCSI ゲートウェイノードの 1 つで、/etc/ceph/iscsi-gateway.cfg ファイルを編集し、trusted_ip_list オプションを新しい iSCSI ゲートウェイノードの新しい IP アドレスに追加します。以下に例を示します。

    [config]
    ...
    trusted_ip_list = 10.172.19.21,10.172.19.22,10.172.19.23,10.172.19.24
  6. 更新された /etc/ceph/iscsi-gateway.cfg ファイルをすべての iSCSI ゲートウェイノードにコピーします。

    重要

    iscsi-gateway.cfg ファイルは、すべての iSCSI ゲートウェイノードで同一である必要があります。

  7. 必要に応じて、SSL を使用する場合は 、既存の iSCSI ゲートウェイノード の 1 つから / etc/ceph/ ディレクトリーに ~/ssl-keys/iscsi-gateway.pem~/ssl-keys/iscsi-gateway-pub.key、および ~ /ssl-keys/ iscsi-gateway.key ファイルをコピーします。
  8. 新しい iSCSI ゲートウェイノードで API サービスを有効にして起動します。

    [root@iscsigw ~]# systemctl enable rbd-target-api
    [root@iscsigw ~]# systemctl start rbd-target-api
  9. iSCSI ゲートウェイコマンドラインインターフェースを起動します。

    [root@iscsigw ~]# gwcli
  10. IPv4 アドレスまたは IPv6 アドレスを使用して iSCSI ゲートウェイを作成します。

    構文

    >/iscsi-target create iqn.2003-01.com.redhat.iscsi-gw:_TARGET_NAME_
    > goto gateways
    > create ISCSI_GW_NAME IP_ADDR_OF_GW
    > create ISCSI_GW_NAME IP_ADDR_OF_GW

    >/iscsi-target create iqn.2003-01.com.redhat.iscsi-gw:ceph-igw
    > goto gateways
    > create ceph-gw-3 10.172.19.23
    > create ceph-gw-4 10.172.19.24

    重要

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

  11. iSCSI イニシエーターから、新たに追加された iSCSI ゲートウェイを使用するように再ログインします。

その他のリソース

7.8. イニシエーターが iSCSI ターゲットに接続されていることの確認

iSCSI ゲートウェイをインストールし、iSCSI ターゲットとイニシエーターを設定したら、イニシエーターが iSCSI ターゲットに正しく接続されていることを確認します。

前提条件

  • Ceph iSCSI ゲートウェイソフトウェアのインストール
  • iSCSI ターゲットを設定している。
  • iSCSI イニシエーターを設定していました。

手順

  1. iSCSI ゲートウェイコマンドラインインターフェースを起動します。

    [root@iscsigw ~]# gwcli
  2. イニシエーターが iSCSI ターゲットに接続されていることを確認します。

    /> goto hosts
    /iscsi-target...csi-igw/hosts> ls
    o- hosts .............................. [Hosts: 1: Auth: None]
      o- iqn.1994-05.com.redhat:rh7-client  [LOGGED-IN, Auth: None, Disks: 0(0.00Y)]

    接続されている場合はイニシエーターのステータスは LOGGED-IN になります。

  3. LUN が iSCSI ゲートウェイ間で分散されていることを確認します。

    /> goto hosts
    /iscsi-target...csi-igw/hosts> ls
    o- hosts ................................. [Hosts: 2: Auth: None]
      o- iqn.2005-03.com.ceph:esx ............ [Auth: None, Disks: 4(310G)]
      | o- lun 0 ............................. [rbd.disk_1(100G), Owner: ceph-gw-1]
      | o- lun 1 ............................. [rbd.disk_2(10G), Owner: ceph-gw-2]

    ディスクの作成時に、ディスクには、マッピングされた LUN が最も少ないゲートウェイに基づいて iSCSI ゲートウェイが 所有者 として割り当てられます。この数が分散される場合、ゲートウェイはラウンドロビンの割り当てに基づいて割り当てられます。現在、LUN の分散は動的ではなく、ユーザーが選択できません。

    イニシエーターがターゲットにログインし、マルチ パス層が最適化された場合、イニシエーターのオペレーティングシステムのマルチパスユーティリティーは、ALUA Active-Optimized(AO)の状態にある Owner ゲートウェイへのパスを 報告 します。マルチパスユーティリティー 、ALUA Active-non-Optimized(ANO)状態にある他のパスを報告します。

    AO パスが失敗すると、他の iSCSI ゲートウェイのいずれかが使用されます。フェイルオーバーゲートウェイの順序は、イニシエーターの マルチパスレイヤー によって異なります。通常、通常、最初に見つかったパスに基づいて順番になります。

7.9. Ansible を使用した Ceph iSCSI ゲートウェイのアップグレード

Red Hat Ceph Storage iSCSI ゲートウェイのアップグレードは、ローリングアップグレード用に設計された Ansible Playbook を使用して実行できます。

前提条件

  • 稼働中の Ceph iSCSI ゲートウェイ。
  • 稼働中の Red Hat Ceph Storage クラスター

手順

  1. 正しい iSCSI ゲートウェイノードが Ansible インベントリーファイル(/etc/ansible/hosts)に一覧表示されていることを確認します。
  2. ローリングアップグレード Playbook を実行します。

    [admin@ansible ~]$ ansible-playbook rolling_update.yml
  3. 適切な Playbook を実行してアップグレードを完了します。

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

    [admin@ansible ~]$ ansible-playbook site.yml --limit iscsigws

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

    [admin@ansible ~]$ ansible-playbook site-docker.yml --limit iscsigws

7.10. コマンドラインインターフェースを使用した Ceph iSCSI ゲートウェイのアップグレード

一度に 1 つのベアメタル iSCSI ゲートウェイをアップグレードすることで、Red Hat Ceph Storage iSCSI ゲートウェイをローリング方式でアップグレードすることができます。

警告

Ceph OSD のアップグレードおよび再起動中に iSCSI ゲートウェイをアップグレードしないでください。OSD のアップグレードが完了し、ストレージクラスターが active+clean 状態になるまで待ちます。

前提条件

  • 稼働中の Ceph iSCSI ゲートウェイ。
  • 稼働中の Red Hat Ceph Storage クラスター
  • iSCSI ゲートウェイノードへの root アクセスがある。

手順

  1. iSCSI ゲートウェイパッケージを更新します。

    [root@iscsigw ~]# yum update ceph-iscsi
  2. iSCSI ゲートウェイデーモンを停止します。

    [root@iscsigw ~]# systemctl stop rbd-target-api
    [root@iscsigw ~]# systemctl stop rbd-target-gw
  3. iSCSI ゲートウェイデーモンが正常に停止していることを確認します。

    [root@iscsigw ~]# systemctl status rbd-target-gw
    1. rbd-target-gw サービスが正常に停止する場合は、手順 4 に進みます。
    2. rbd-target-gw サービスを停止できない場合は、以下の手順を実行します。

      1. targetcli パッケージがインストールされていない場合は、targetcli パッケージをインストールします。

        [root@iscsigw ~]# yum install targetcli
      2. 既存のターゲットオブジェクトを確認します。

        [root@iscsigw ~]# targetlci ls

        o- / ............................................................. [...]
        o- backstores .................................................... [...]
        | o- user:rbd ..................................... [Storage Objects: 0]
        o- iscsi .................................................. [Targets: 0]

        バックストア および ストレージオブジェクト が空の場合、iSCSI ターゲットは正常にシャットダウンされ、ステップ 4 に進むことができます。

      3. ターゲットオブジェクトがある場合は、以下のコマンドを使用してすべてのターゲットオブジェクトを強制的に削除します。

        [root@iscsigw ~]# targetlci clearconfig confirm=True
        警告

        複数のサービスが iSCSI ターゲットを使用している場合は、インタラクティブモードで targetcli を使用して、これらの特定のオブジェクトを削除します。

  4. tcmu-runner パッケージを更新します。

    [root@iscsigw ~]# yum update tcmu-runner
  5. tcmu-runner サービスを停止します。

    [root@iscsigw ~]# systemctl stop tcmu-runner
  6. iSCSI ゲートウェイサービスは、以下の順序で再起動します。

    [root@iscsigw ~]# systemctl start tcmu-runner
    [root@iscsigw ~]# systemctl start rbd-target-gw
    [root@iscsigw ~]# systemctl start rbd-target-api

7.11. iSCSI ゲートウェイの監視

Red Hat は、エクスポートされる Ceph ブロックデバイス(RBD)イメージのパフォーマンスを監視するために、Ceph iSCSI ゲートウェイ環境の追加ツールを提供します。

gwtop ツール は、iSCSI 経由でクライアントにエクスポートされる RBD イメージの集約されたパフォーマンスメトリックを表示する トップレベルのツールです。メトリックは、Performance Metrics Domain Agent(PMDA)から取得されます。Linux-IO ターゲット(LIO)PMDA からの情報は、エクスポートした各 RBD イメージを接続されたクライアントと関連する I/O メトリクスで一覧表示するために使用されます。

以下の手順は、iSCSI ゲートウェイノードで行います。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • Ceph iSCSI ゲートウェイソフトウェアのインストール
  • Ceph iSCSI ゲートウェイノードへのルートレベルのアクセス

手順

  1. ceph-iscsi-tools パッケージをインストールします。

    [root@iscsigw ~]# yum install ceph-iscsi-tools
  2. パフォーマンスの co-pilot パッケージをインストールします。

    [root@iscsigw ~]# yum install pcp
  3. LIO PMDA パッケージをインストールします。

    [root@iscsigw ~]# yum install pcp-pmda-lio
  4. Performance co-pilot サービスを有効にして開始します。

    [root@iscsigw ~]# systemctl enable pmcd
    [root@iscsigw ~]# systemctl start pmcd
  5. pcp-pmda-lio エージェントを登録します。

    [root@iscsigw ~]# cd /var/lib/pcp/pmdas/lio
    [root@iscsigw ~]# ./Install

    デフォルトでは、gwtop 、iSCSI ゲートウェイ設定オブジェクトが rbd プールの gateway.conf という RADOS オブジェクトに保存されていることを前提としています。この設定では、パフォーマンス統計の収集のために接続するための iSCSI ゲートウェイを定義します。この設定は、-g または - c フラグを使用して上書きできます。詳細は 、gwtop --help を参照して ください。

    LIO 設定は、パフォーマンスのコスロットから抽出するパフォーマンス統計のタイプを決定します。gwtop 起動すると、LIO 設定を確認し、ユーザー空間ディスクを見つけると、gwtop は LIO コレクターを自動的に 選択 します。

  6. gwtop ユーティリティーを 使用 して iSCSI ゲートウェイを監視します。ユーザーでサポートされるストレージ(TCMU)デバイスの場合:

    gwtop  2/2 Gateways   CPU% MIN:  4 MAX:  5    Network Total In:    2M  Out:    3M   10:20:00
    Capacity:   8G    Disks:   8   IOPS:  503   Clients:  1   Ceph: HEALTH_OK          OSDs:   3
    Pool.Image       Src    Size     iops     rMB/s     wMB/s   Client
    iscsi.t1703             500M        0      0.00      0.00
    iscsi.testme1           500M        0      0.00      0.00
    iscsi.testme2           500M        0      0.00      0.00
    iscsi.testme3           500M        0      0.00      0.00
    iscsi.testme5           500M        0      0.00      0.00
    rbd.myhost_1      T       4G      504      1.95      0.00   rh460p(CON)
    rbd.test_2                1G        0      0.00      0.00
    rbd.testme              500M        0      0.00      0.00

    Client 列で、(CON)iSCSI イニシエーター(クライアント) が現在 iSCSI ゲートウェイにログインしていることを意味します。-multi- が表示されると、複数のクライアントが単一の RBD イメージにマッピングされます。

    警告

    SCSI の永続的な予約はサポートされません。SCSI 永続予約に依存しないクラスター対応のファイルシステムまたはクラスタリングソフトウェアを使用している場合は、複数の iSCSI イニシエーターを RBD イメージにマッピングできます。たとえば、ATS を使用する VMware vSphere 環境はサポートされますが、Microsoft のクラスタリングサーバー(MSCS)を使用する構成はサポートされません。

その他のリソース

7.12. iSCSI 設定の削除

iSCSI 設定を削除するには、gwcli ユーティリティー を使用してホストおよびディスクを削除し、Ansible purge-iscsi-gateways.yml Playbook を使用して iSCSI ターゲット設定を削除します。

警告

purge-iscsi-gateways.yml Playbook の使用は、iSCSI ゲートウェイ環境に対する破壊的なアクションです。

+ 警告: RBD イメージにスナップショットまたはクローンがあり、Ceph iSCSI ゲートウェイ経由でエクスポートされる場合、Purge -iscsi-gateways.yml の使用試行は失敗します。

前提条件

  • すべての iSCSI イニシエーターを切断します。

    • Red Hat Enterprise Linux イニシエーター:

      構文

      iscsiadm -m node -T TARGET_NAME --logout

      TARGET_NAME は、設定した iSCSI ターゲット名に置き換えます。以下に例を示します。

      # iscsiadm -m node -T iqn.2003-01.com.redhat.iscsi-gw:ceph-igw --logout
      Logging out of session [sid: 1, target: iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw, portal: 10.172.19.21,3260]
      Logging out of session [sid: 2, target: iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw, portal: 10.172.19.22,3260]
      Logout of [sid: 1, target: iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw, portal: 10.172.19.21,3260] successful.
      Logout of [sid: 2, target: iqn.2003-01.com.redhat.iscsi-gw:iscsi-igw, portal: 10.172.19.22,3260] successful.

    • Windows イニシエーター:

      詳細は、Microsoft ドキュメント を参照してください。

    • VMware ESXi イニシエーター:

      詳細は、VMware ドキュメント を参照してください。

手順

  1. iSCSI ゲートウェイコマンドラインユーティリティーを実行します。

    [root@iscsigw ~]# gwcli
  2. ホストを削除します。

    構文

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

    TARGET_NAME を設定した iSCSI ターゲット名に置き換え、CLIENT_NAME を iSCSI イニシエーター名に置き換えます。以下に例を示します。

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

  3. ディスクを削除します。

    構文

    /> cd /disks/
    /disks> delete POOL_NAME.IMAGE_NAME

    POOL_NAME をプールの名前に置き換え、IMAGE_NAME をイメージの名前に置き換えます。以下に例を示します。

    /> cd /disks/
    /disks> delete rbd.disk_1

  4. iSCSI ゲートウェイパージ Ansible Playbook を実行します。

    [root@ansible ~]# cd /usr/share/ceph-ansible/
    [root@ansible ceph-ansible]# ansible-playbook purge-iscsi-gateways.yml
  5. プロンプトが表示されたら、パージのタイプを入力します。

    lio
    このモードでは、Linux iSCSI ターゲット設定は、定義されたすべての iSCSI ゲートウェイでパージされます。作成されたディスクは、Ceph ストレージクラスター内で変更されません。
    all
    これらが すべて 選択されると、Linux iSCSI ターゲット設定は、iSCSI ゲートウェイ環境内で定義された すべて の RBD イメージと共に削除されます。その他の関連のない RBD イメージは削除されません。この操作によりデータが削除されるため、正しいモードを選択してください。

    [root@rh7-iscsi-client ceph-ansible]# ansible-playbook purge-iscsi-gateways.yml
    Which configuration elements should be purged? (all, lio or abort) [abort]: all
    
    
    PLAY [Confirm removal of the iSCSI gateway configuration] *********************
    
    
    GATHERING FACTS ***************************************************************
    ok: [localhost]
    
    
    TASK: [Exit playbook if user aborted the purge] *******************************
    skipping: [localhost]
    
    
    TASK: [set_fact ] *************************************************************
    ok: [localhost]
    
    
    PLAY [Removing the gateway configuration] *************************************
    
    
    GATHERING FACTS ***************************************************************
    ok: [ceph-igw-1]
    ok: [ceph-igw-2]
    
    
    TASK: [igw_purge | purging the gateway configuration] *************************
    changed: [ceph-igw-1]
    changed: [ceph-igw-2]
    
    
    TASK: [igw_purge | deleting configured rbd devices] ***************************
    changed: [ceph-igw-1]
    changed: [ceph-igw-2]
    
    
    PLAY RECAP ********************************************************************
    ceph-igw-1                 : ok=3    changed=2    unreachable=0    failed=0
    ceph-igw-2                 : ok=3    changed=2    unreachable=0    failed=0
    localhost                  : ok=2    changed=0    unreachable=0    failed=0

7.13. その他のリソース

  • Red Hat Ceph Storage Dashboard を使用した iSCSI ゲートウェイの管理に関する詳細は、『Dashboard Guide for Red Hat Ceph Storage 4』の「 iSCSI functions 」セクションを参照してください。

付録A Ceph ブロックデバイス設定の参照

ストレージ管理者は、利用可能なさまざまなオプションを使用して、Ceph ブロックデバイスの動作を微調整できます。デフォルトの Ceph ブロックデバイスオプションや Ceph ブロックデバイスのキャッシュオプションなど、この参考情報を使用することができます。

A.1. 前提条件

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

A.2. ブロックデバイスのデフォルトオプション

イメージを作成するデフォルト設定を上書きすることができます。Ceph はフォーマットが 2 つでストライプ化されないイメージを作成します。

rbd_default_format
description
その他の形式が指定されていない場合のデフォルト形式(2)。形式 1 は、librbd および kernel モジュールのすべてのバージョンと互換性がありますが、クローン作成などの新機能には対応していません。形式 2 は、librbd でサポートされ、バージョン 3.11 以降のカーネルモジュールに対応しています(ストライプ化を除く)。形式 2 では、クローン作成のサポートが追加され、今後より多くの機能を許可することがより容易になります。
type
integer
デフォルト
2
rbd_default_order
description
その他の順序が指定されていない場合のデフォルト順序。
type
integer
デフォルト
22
rbd_default_stripe_count
description
その他のストライプ数が指定されていない場合は、デフォルトのストライプ数です。デフォルト値を変更するには、v2 機能のストライピングが必要です。
type
64 ビット符号なし整数
デフォルト
0
rbd_default_stripe_unit
description
その他のストライプユニットが指定されていない場合には、デフォルトのストライプユニットです。単位を 0 (オブジェクトサイズ)から変更するには、ストライピング v2 機能が必要です。
type
64 ビット符号なし整数
デフォルト
0
rbd_default_features
description

ブロックデバイスイメージの作成時に有効になっているデフォルトの機能。この設定は、フォーマット 2 イメージにのみ適用されます。設定は以下のとおりです。

1: レイヤーサポート。レイヤー化により、クローン作成を使用できます。

2: v2 のサポートを削除します。ストライピングは、データを複数のオブジェクトに分散します。ストライピングは、順次の読み取り/書き込みワークロードの並列処理に役立ちます。

4: 排他的ロックサポート有効にする場合は、書き込みを行う前にクライアントがオブジェクトのロックを取得する必要があります。

8: オブジェクトマップのサポート。ブロックデバイスはシンプロビジョニングされています。つまり、実際に存在するデータのみを保存します。オブジェクトマップのサポートは、どのオブジェクトが実際に存在するか(ドライブに保存されているデータ)を追跡するのに役立ちます。オブジェクトマップのサポートを有効にすると、クローン作成の I/O 操作が高速化されます。または、スパースに設定されるイメージのインポートおよびエクスポートが迅速化されます。

16: Fast-diff のサポートfast-diff のサポートは、オブジェクトマップのサポートと排他的ロックのサポートにより異なります。オブジェクトマップに別のプロパティーを追加します。これにより、イメージのスナップショット間の diff およびスナップショットの実際のデータ使用速度がより速くなります。

32: ディープフラット化サポート。ディープフラット化により、イメージ自体に加えて、イメージのすべてのスナップショットに対する rbd フラット化 が行われます。それ以外の場合には、イメージのスナップショットは親に依存するため、スナップショットが削除されるまで親は削除できません。ディープフラット化は、スナップショットがある場合でも、クローンから独立した親を作成します。

64: ジャーナリングのサポート。ジャーナリングは、イメージの変更の発生順序ですべての変更を記録します。これにより、リモートイメージのクラッシュ一貫性のあるミラーがローカルで利用可能になります。

有効な機能は、数値設定の合計です。

type
integer
デフォルト

61 - レイヤー化、排他的ロック、オブジェクトマップ、Fast-diff、および deep-flatten が有効になります。

重要

現在のデフォルト設定は、RBD カーネルドライバーや古い RBD クライアントとの互換性がありません。

rbd_default_map_options
description
ほとんどのオプションは、主にデバッグおよびベンチマークに役立ちます。詳細は、「 マップオプション 」の man rbd を参照してください。
type
string
デフォルト
""

A.3. ブロックデバイスの一般的なオプション

rbd_op_threads
description
ブロックデバイス操作スレッドの数。
type
integer
デフォルト
1
警告

rbd_op_threads のデフォルト値を変更しないでください。1 を超える数に設定すると、データが破損する可能性があります。

rbd_op_thread_timeout
description
ブロックデバイス操作スレッドのタイムアウト(秒単位)。
type
integer
デフォルト
60
rbd_non_blocking_aio
description
true の場合、Ceph はブロックを防ぐためにワーカースレッドからブロックデバイス非同期 I/O 操作を処理します。
type
ブール値
デフォルト
true
rbd_concurrent_management_ops
description
フライで同時管理操作の最大数(例: イメージの削除またはサイズ変更)。
type
integer
デフォルト
10
rbd_request_timed_out_seconds
description
メンテナンスリクエストがタイムアウトするまでの秒数。
type
integer
デフォルト
30
rbd_clone_copy_on_read
description
true に設定すると、Copy-on-read クローンが作成されます。
type
ブール値
デフォルト
false
rbd_enable_alloc_hint
description
true の場合、割り当てヒントが有効になり、ブロックデバイスは OSD バックエンドにヒントを発行し、予想されるサイズオブジェクトを示します。
type
ブール値
デフォルト
true
rbd_skip_partial_discard
description
true の場合、ブロックデバイスはオブジェクト内の範囲を破棄しようとすると範囲のゼロを省略します。
type
ブール値
デフォルト
false
rbd_tracing
description
Linux Trace Toolkit Next Generation User Space Tracer(LTTng-UST)トレースポイントを有効にするには、このオプションを true に設定します。詳細は、「 RADOS Block Device(RBD)Workloads with the RBD─ Feature」を 参照してください。
type
ブール値
デフォルト
false
rbd_validate_pool
description
RBD 互換性の空のプールを検証するには、このオプションを true に設定します。
type
ブール値
デフォルト
true
rbd_validate_names
description
イメージの指定を検証するには、このオプションを true に設定します。
type
ブール値
デフォルト
true

A.4. ブロックデバイスキャッシュオプション

Ceph ブロックデバイスのユーザー領域実装( librbd )は Linux ページキャッシュを利用できないため、RBD キャッシュと呼ばれるメモリー内キャッシュが含まれます。Ceph ブロックデバイスのキャッシュは、適切に動作したハードディスクのキャッシュと同じように動作します。オペレーティングシステムがバリアまたはフラッシュリクエストを送信すると、ダーティーデータはすべて Ceph OSD に書き込まれます。つまり、ライトバックキャッシュの使用は、フラッシュを適切に送信する仮想マシン(つまり Linux カーネルバージョン 2.6.32 以降)で適切に動作している物理ハードディスクを使用するのと同じように安全です。キャッシュは LRU(Least Recently Used)アルゴリズムを使用し、ライトバックモードでは、より優れたスループットのために連続したリクエストを結合できます。

Ceph ブロックデバイスはライトバックキャッシングをサポートします。ライトバックキャッシュを有効にするには、rbd_cache = true を Ceph 設定ファイルの [client] セクションに設定します。デフォルトでは、librbd はキャッシュを実行しません。書き込みおよび読み取りはストレージクラスターに直接送信され、データがすべてのレプリカのディスクにある場合にのみ返されます。キャッシュが有効になっていると、rbd_cache_max_dirty を超えるアンフラッシュバイトがない場合、書き込みは即座に返されます。この場合、書き込みは十分なバイトがフラッシュされるまで、ライトバックおよびブロックをトリガーします。

Ceph ブロックデバイスは、ライトスルーキャッシングをサポートします。キャッシュのサイズを設定でき、ターゲットおよび制限を設定して、ライトバックキャッシングからライトスルーキャッシングに切り替えることができます。書き込みスルーモードを有効にするには、rbd_cache_max_dirty を 0 に設定します。これは、データがすべてのレプリカのディスクにある場合にだけ書き込みが返されることを意味しますが、読み取りはキャッシュから返される可能性があります。このキャッシュはクライアント上のメモリーにあり、各 Ceph ブロックデバイスイメージには独自のものがあります。キャッシュはクライアントのローカルであるため、イメージにアクセスしている他は一貫性がありません。その他のファイルシステム(GFS、OCFS など)を Ceph ブロックデバイス上で実行しても、キャッシングが有効になっていると動作しません。

Ceph ブロックデバイスの Ceph 設定は、デフォルトでは /etc/ceph/ceph.conf の Ceph 設定ファイルの [client] セクションで設定する必要があります。

設定には以下が含まれます。

rbd_cache
description
RADOS Block Device(RBD)のキャッシュを有効にします。
type
ブール値
required
いいえ
デフォルト
true
rbd_cache_size
description
RBD キャッシュサイズ(バイト単位)。
type
64 ビット Integer
required
いいえ
デフォルト
32 MiB
rbd_cache_max_dirty
description
キャッシュがライトバックをトリガーするバイト単位の ダーティー 制限。0 の場合は、ライトスルーキャッシングを使用します。
type
64 ビット Integer
required
いいえ
制約
rbd キャッシュサイズ 以下である必要があります。
デフォルト
24 MiB
rbd_cache_target_dirty
description
キャッシュが データ ストレージへのデータの書き込みを開始する前にダーティーターゲット。キャッシュへの書き込みをブロックしません。
type
64 ビット Integer
required
いいえ
制約
rbd キャッシュの最大ダーティー 数である必要があります。
デフォルト
16 MiB
rbd_cache_max_dirty_age
description
ライトバックが開始される前にダーティーデータがキャッシュにある秒数。
type
float
required
いいえ
デフォルト
1.0
rbd_cache_max_dirty_object
description
オブジェクトのダーティー制限 - rbd_cache_size から自動計算するには 0 に設定します。
type
integer
デフォルト
0
rbd_cache_block_writes_upfront
description
true の場合、aio_write の呼び出し が完了するまでにキャッシュへの書き込みがブロックされます。false の場合、aio_completion が呼び出される前にブロックされます。
type
ブール値
デフォルト
false
rbd_cache_writethrough_until_flush
description
ライトスルーモードで開始し、最初のフラッシュリクエストの受信後にライトバックに切り替えます。これを有効にすることは、保守的なものですが、rbd で実行している仮想マシンが、2.6.32 より前の Linux の virtio ドライバーのようにフラッシュを送信するには古すぎる。
type
ブール値
required
いいえ
デフォルト
true

A.5. ブロックデバイスの親および子読み取りオプション

rbd_balance_snap_reads
description
通常、Ceph はプライマリー OSD からオブジェクトを読み取ります。読み取りは変更できないため、この機能を有効にして、プライマリー OSD とレプリカ間のスナップ読み取りのバランスを取ることができます。
type
ブール値
デフォルト
false
rbd_localize_snap_reads
description
一方、rbd_balance_snap_reads は、スナップショットを読み取るレプリカをランダム化します。rbd_localize_snap_reads を有効にすると、ブロックデバイスは CRUSH マップを検索し、スナップショットの読み取りに最も近い、またはローカルの OSD を見つけます。
type
ブール値
デフォルト
false
rbd_balance_parent_reads
description
通常、Ceph はプライマリー OSD からオブジェクトを読み取ります。読み取りは変更できないため、この機能を有効にして、プライマリー OSD とレプリカ間の親読み取りのバランスを取ることができます。
type
ブール値
デフォルト
false
rbd_localize_parent_reads
description
一方、rbd_balance_parent_reads は、親の読み取り用にレプリカをランダム化します。rbd_localize_parent_reads を有効にすると、ブロックデバイスは CRUSH マップを検索し、親の読み取りに最も近い、またはローカルの OSD を見つけます。
type
ブール値
デフォルト
true

A.6. ブロックデバイスの読み取り先オプション

RBD は、小さい連続した読み取りを最適化するために read-ahead/prefetching をサポートします。これは通常、仮想マシンの場合、ゲスト OS で処理する必要がありますが、ブートローダーが効率的な読み取りを発行しない可能性があります。キャッシュが無効になっていると、読み取り専用が自動的に無効になります。

rbd_readahead_trigger_requests
description
読み取りアヘッドをトリガーするのに必要な連続した読み取り要求の数。
type
integer
required
いいえ
デフォルト
10
rbd_readahead_max_bytes
description
read-ahead リクエストの最大サイズ。ゼロの場合、read-ahead は無効になります。
type
64 ビット Integer
required
いいえ
デフォルト
512 KiB
rbd_readahead_disable_after_bytes
description
この回数が RBD イメージから読み取られると、そのイメージの read-ahead は閉じられるまで無効になります。これにより、ゲスト OS が起動されると、読み取りアヘッドを引き継ぐことができます。ゼロの場合、read-ahead は有効のままになります。
type
64 ビット Integer
required
いいえ
デフォルト
50 MiB

A.7. ブロックデバイスのブラックリストオプション

rbd_blacklist_on_break_lock
description
ロックが破損したクライアントをブラックリストに登録するかどうか。
type
ブール値
デフォルト
true
rbd_blacklist_expire_seconds
description
blacklist の秒数 - OSD のデフォルトの場合は 0 に設定します。
type
integer
デフォルト
0

A.8. ブロックデバイスジャーナルのオプション

rbd_journal_order
description
ジャーナルオブジェクトの最大サイズを計算するために移行するビット数。値は 12 から 64 までです。
type
32 ビット符号なし整数
デフォルト
24
rbd_journal_splay_width
description
アクティブなジャーナルオブジェクトの数。
type
32 ビット符号なし整数
デフォルト
4
rbd_journal_commit_age
description
コミット時間間隔(秒単位)。
type
二重精度フローティングポイント番号
デフォルト
5
rbd_journal_object_flush_interval
description
ジャーナルオブジェクトごとの保留中のコミットの最大数。
type
integer
デフォルト
0
rbd_journal_object_flush_bytes
description
ジャーナルオブジェクトごとの保留中のバイトの最大数。
type
integer
デフォルト
0
rbd_journal_object_flush_age
description
保留中のコミットの最大間隔(秒単位)。
type
二重精度フローティングポイント番号
デフォルト
0
rbd_journal_pool
description
ジャーナルオブジェクトのプールを指定します。
type
string
デフォルト
""

付録B iSCSI ゲートウェイ変数

iSCSI ゲートウェイの一般的な変数

seed_monitor
目的
各 iSCSI ゲートウェイは、RADOS および RBD 呼び出しのために Ceph Storage クラスターにアクセスする必要があります。これは、iSCSI ゲートウェイに適切な /etc/ceph/ ディレクトリーが定義されている必要があることを意味します。iSCSI ゲートウェイの /etc/ceph/ ディレクトリーに設定するには、seed_monitor ホストを使用します。
gateway_keyring
目的
カスタムキーリング名を定義します。
perform_system_checks
目的
これは、各 iSCSI ゲートウェイでマルチパス設定および LVM 設定を確認するブール値です。multipathd デーモンと LVM が適切に設定されるようにするには、少なくとも 1 回実行する場合は true に設定する必要があります。

iSCSI ゲートウェイ RBD-TARGET-API 変数

api_user
目的
API のユーザー名。デフォルトは admin です。
api_password
目的
API を使用するためのパスワードデフォルトは admin です。
api_port
目的
API を使用するための TCP ポート番号。デフォルトは 5000 です。
api_secure
目的
値は true または false です。デフォルトは false です。
loop_delay
目的
iSCSI 管理オブジェクトをポーリングする間隔を秒単位で制御します。デフォルト値は 1 です。
trusted_ip_list
目的
API にアクセスできる IPv4 または IPv6 アドレスの一覧。デフォルトでは、iSCSI ゲートウェイノードのみがアクセスできます。

付録C iscsigws .yml ファイルのサンプル

# Variables here are applicable to all host groups NOT roles

# This sample file generated by generate_group_vars_sample.sh

# Dummy variable to avoid error because ansible does not recognize the
# file as a good configuration file when no variable in it.
dummy:

# You can override vars by using host or group vars

###########
# GENERAL #
###########
# Whether or not to generate secure certificate to iSCSI gateway nodes
#generate_crt: False

#iscsi_conf_overrides: {}
#iscsi_pool_name: rbd
#iscsi_pool_size: "{{ osd_pool_default_size }}"

#copy_admin_key: True

##################
# RBD-TARGET-API #
##################
# Optional settings related to the CLI/API service
#api_user: admin
#api_password: admin
#api_port: 5000
#api_secure: false
#loop_delay: 1
#trusted_ip_list: 192.168.122.1


##########
# DOCKER #
##########

# Resource limitation
# For the whole list of limits you can apply see: docs.docker.com/engine/admin/resource_constraints
# Default values are based from: https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/2/html/red_hat_ceph_storage_hardware_guide/minimum_recommendations
# These options can be passed using the 'ceph_mds_docker_extra_env' variable.

# TCMU_RUNNER resource limitation
#ceph_tcmu_runner_docker_memory_limit: "{{ ansible_memtotal_mb }}m"
#ceph_tcmu_runner_docker_cpu_limit: 1

# RBD_TARGET_GW resource limitation
#ceph_rbd_target_gw_docker_memory_limit: "{{ ansible_memtotal_mb }}m"
#ceph_rbd_target_gw_docker_cpu_limit: 1

# RBD_TARGET_API resource limitation
#ceph_rbd_target_api_docker_memory_limit: "{{ ansible_memtotal_mb }}m"
#ceph_rbd_target_api_docker_cpu_limit: 1