Red Hat Training

A Red Hat training course is available for Red Hat Ceph Storage

Ubuntu のオブジェクトゲートウェイガイド

Red Hat Ceph Storage 3

Ubuntu での Ceph Storage Object Gateway のインストール、設定および管理

概要

本書では、AMD64 および Intel 64 のアーキテクチャーで実行している Ubuntu 14.04 に Ceph Storage Object Gateway をインストール、設定、および管理する方法について説明します。

第1章 概要

Ceph Object Gateway は RADOS ゲートウェイ (RGW) としても知られている、librados 上に構築されたオブジェクトストレージインターフェースで、RESTful ゲートウェイを Ceph ストレージクラスターに提供します。Ceph Object Gateway は以下の 2 つのインターフェースをサポートします。

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

Ceph オブジェクトゲートウェイは、Ceph ストレージクラスターと対話するためのサーバーです。OpenStack Swift および Amazon S3 と互換性のあるインターフェースを提供するため、Ceph オブジェクトゲートウェイには独自のユーザー管理があります。Ceph オブジェクトゲートウェイは、Ceph ブロックデバイスクライアントからのデータを保存するために使用される同じ Ceph ストレージクラスターにデータを保存できますが、これには別個のプールが使用され、別の CRUSH 階層が組み込まれます。S3 と Swift API は共通の namespace を共有するため、ある API でデータを作成し、これを別の API で取得することができます。

gateway
警告

RGW で使用されるプールでは RADOS スナップショットを使用しないでください。これを実行すると、望ましくないデータの一貫性が発生する可能性があります。

第2章 設定

2.1. CivetWeb フロントエンド

デフォルトでは、Ceph Object Gateway は CivetWeb サーバーを使用して HTTP で RESTful インターフェースを公開します。Civetweb は、埋め込み可能な Web サーバーです。

関連情報

2.2. CivetWeb ポートの変更

Ansible を使用して Ceph Object Gateway をインストールすると、ポート 8080 で実行するように CivetWeb が設定されます。Ansible は、Ceph 設定ファイルに以下のような行を追加します。

rgw frontends = civetweb port=192.168.122.199:8080 num_threads=100
重要

Ceph 設定ファイルに rgw frontends = civetweb 行が含まれていない場合、Ceph Object Gateway はポート 7480 をリッスンします。rgw_frontends = civetweb 行が含まれているがポートが指定されていない場合、Ceph Object Gateway はポート 80 をリッスンします。

重要

Ansible は、ポート 8080 をリッスンするように Ceph Object Gateway を設定し、Red Hat Ceph Storage 3 のインストールをサポートする方法として ceph-ansible を使用するので、ポート 8080 は Red Hat Ceph Storage 3 ドキュメントのデフォルトポートとみなされます。

前提条件

  • 実行中の Red Hat Ceph Storage 3.3 クラスター
  • Ceph Object Gateway ノード

手順

  1. ゲートウェイノードで、/etc/ceph/ ディレクトリーで Ceph 設定ファイルを開きます。
  2. サンプルのような RGW クライアントセクションを検索します。

    [client.rgw.gateway-node1]
    host = gateway-node1
    keyring = /var/lib/ceph/radosgw/ceph-rgw.gateway-node1/keyring
    log file = /var/log/ceph/ceph-rgw-gateway-node1.log
    rgw frontends = civetweb port=192.168.122.199:8080 num_threads=100

    [client.rgw.gateway-node1] の見出しは、Ceph Storage Cluster クライアントを設定する時に Ceph 設定ファイルのこの部分を特定します。クライアントタイプは rgw で識別される Ceph Object Gateway で、ノードの名前は gateway-node1 です。

  3. デフォルトの Ansible 設定ポート 808080 に変更するには、rgw frontends 行を編集します。

    rgw frontends = civetweb port=192.168.122.199:80 num_threads=100

    rgw_frontends キーと値のペアの port=port-number の間に空白がないことを確認します。

    ポートを変更するその他のゲートウェイノードでこの手順を繰り返します。

  4. 各ゲートウェイノードから Ceph Object Gateway サービスを再起動して、新しいポート設定を有効にします。

    $ sudo systemctl restart ceph-radosgw.target
  5. 各ゲートウェイノードのファイアウォールで、設定したポートが開いていることを確認します。

    $ sudo iptables --list
  6. ポートが開かない場合は、ポートを追加します。

    $ sudo iptables -I INPUT 1 -i iface -p tcp -s IP_address/netmask --dport 80 -j ACCEPT

    iface 、IP_address 、およびnetmask を、Ceph Object Gateway ノードの関連する値に置き換えます。

    $ sudo iptables -I INPUT 1 -i eth0 -p tcp -s 192.168.122.199/255.255.255.0 --dport 80 -j ACCEPT

  7. 変更を永続的にして、Ceph Object Gateway ノードの再起動時に有効になります。

    $ sudo apt-get install iptables-persistent
  8. 端末 UI で yes を選択し、現在の IPv4 iptables ルールを /etc/iptables/rules.v4 に、現在の IPv6 iptables ルールを /etc/iptables/rules.v6 に保存します。
  9. オプション: iptables-persistent のインストール後に新規の IPv4 iptables ルールを追加する場合は、ルールファイルに追加します。このような場合は、root で以下のコマンドを実行します。

    $ iptables-save > /etc/iptables/rules.v4

関連情報

2.3. Civetweb での SSL の使用

Red Hat Ceph Storage 1 では、Ceph Object Gateway の Civetweb SSL サポートが HAProxy および keepalived に依存します。Red Hat Ceph Storage 2 以降のリリースでは、Civetweb は OpenSSL ライブラリーを使用して Transport Layer Security(TLS)を提供します。

重要

実稼働デプロイメントでは HAProxy および keepalived を使用して HAProxy で SSL 接続を終了する 必要があります。小規模から中規模の テストおよび実稼働前 デプロイメントに のみ、Civetweb で SSL を使用することが推奨されます。

Civetweb で SSL を使用するには、ゲートウェイノードのホスト名に一致する認証局(CA)から証明書を取得します。Red Hat は、subject alternate name フィールドがあり、S3-style サブドメインで使用するワイルドカードを持つ CA から証明書を取得することを推奨します。

Civetweb では、鍵、サーバー証明書、およびその他の認証局または中間証明書が 1 つの .pem ファイルに必要です。

重要

.pem ファイルには秘密鍵が含まれます。.pem ファイルを不正アクセスから保護します。

SSL にポートを設定するには、ポート番号を rgw_frontends に追加し、ポート番号に s を追加して、セキュアなポートであることを示します。さらに、.pem ファイルへのパスを含む ssl_certificate を追加します。以下に例を示します。

[client.rgw.{hostname}]
rgw_frontends = "civetweb port=443s ssl_certificate=/etc/ceph/private/server.pem"

2.4. Civetweb 設定オプション

以下の Civetweb 設定オプションは、RADOS Gateway の Ceph 設定ファイルの組み込み Web サーバーに渡すことができます。各オプションにはデフォルト値があり、値が指定されていない場合、デフォルト値は空になります。

オプション詳細デフォルト

access_log_file

アクセスログのパス。現在の作業ディレクトリーへのフルパスまたは相対。ない場合は(デフォルト)、アクセスはログに記録されません。

error_log_file

エラーログのファイルへのパス。現在の作業ディレクトリーへのフルパスまたは相対。ない場合は(デフォルト)、エラーはログに記録されません。

num_threads

ワーカースレッド数civetweb は、各受信接続を別のスレッドで処理します。したがって、このオプションの値は、Civetweb が処理できる同時 HTTP 接続の数になります。

512

request_timeout_ms

ネットワーク読み取りおよびネットワーク書き込み操作のタイムアウト(ミリ秒単位)。クライアントが長時間実行される接続を維持する場合は、この値を大きくするか(beter)、keep-alive メッセージを使用します。

30000

重要

num_threads を設定すると、rgw_thread_pool_size が上書きされますしたがって、両方を同じ値に設定したか、rgw_thread_pool_size のみを設定し 、num_threads を設定しないでください。デフォルトでは、両方の変数は ceph-ansible により 512 に設定されます。

このオプションの一部が設定された /etc/ceph/ceph.conf ファイルの例を以下に示します。

...

[client.rgw.node1]
rgw frontends = civetweb request_timeout_ms=30000 error_log_file=/var/log/radosgw/civetweb.error.log access_log_file=/var/log/radosgw/civetweb.access.log

2.5. Beast フロントエンドの使用

Ceph Object Gateway は、フロントエンドとして CivetWeb サーバーおよび Beast 埋め込み HTTP サーバーを提供します。Beast フロントエンドは、HTTP 解析に Boost.Beast ライブラリーを使用し、非同期ネットワーク I/O に Boost.Asio ライブラリーを使用します。CivetWeb はデフォルトのフロントエンドであるため、Beast フロントエンドは Red Hat Ceph Storage 設定ファイルの rgw_frontends パラメーターに指定します。

前提条件

  • Red Hat Ceph Storage クラスターが実行中である。
  • Ceph Object Gateway がインストールされている。

手順

  1. 管理サーバーの /etc/ceph/ceph.conf 設定ファイルを変更します。

    1. [client.rgw.<gateway-node>] というセクションを追加し、<gateway-node> を Ceph Object Gateway ノードの短いノード名に置き換えてください。
    2. hostname -s を使用して、ホストの短縮名を取得します。
    3. たとえば、ゲートウェイノード名が gateway-node1 の場合、/etc/ceph/ceph.conf ファイルの [global] セクションに以下のようなセクションを追加します。

      [client.rgw.gateway-node1]
      rgw frontends = beast endpoint=192.168.0.100:80
  2. 更新された設定ファイルを Ceph Object Gateway ノードおよびその他の Ceph ノードにコピーします。

    # scp /etc/ceph/ceph.conf <ceph-node>:/etc/ceph
  3. Ceph Object Gateway を再起動して、Beast フロントエンドを有効にします。

    # systemctl restart ceph-radosgw.target
  4. 設定したポートがノードのファイアウォールで開いていることを確認します。開かれていない場合は、ポートを追加し、ファイアウォール設定を再読み込みします。たとえば、Ceph Object Gateway ノードで、以下を実行します。

    # firewall-cmd --list-all
    # firewall-cmd --zone=public --add-port 80/tcp --permanent
    # firewall-cmd --reload

関連情報

2.6. Beast 設定オプション

以下の Beast 設定オプションは、RADOS Gateway の Ceph 設定ファイルの組み込み Web サーバーに渡すことができます。各オプションにはデフォルト値があります。値の指定がない場合は、デフォルト値は空になります。

オプション詳細デフォルト

endpoint および ssl_endpoint

address[:port] 形式のリスニングアドレスを設定します。アドレスはドット付き 10 進数形式の IPv4 アドレス文字列、または 16 進数表記の IPv6 アドレスが角括弧で囲まれている IPv6 アドレスです。任意のポートはデフォルトで、ssl_endpoint のエンドポイントの 80443 になります。endpoint=[::1] endpoint=192.168.0.100:8000 のように複数回指定できます。

ssl_certificate

SSL 対応のエンドポイントに使用する SSL 証明書ファイルへのパス。

ssl_private_key

SSL 対応エンドポイントに使用される秘密鍵ファイルへのオプションのパス。ssl_certificate で指定されているファイルがない場合は、秘密鍵として使用されます。

SSL を使用する Beast オプションのある /etc/ceph/ceph.conf ファイルの例:

...

[client.rgw.node1]
rgw frontends = beast ssl_endpoint=192.168.0.100:443 ssl_certificate=<path to SSL certificate>

関連情報

2.7. ワイルドカードの DNS への追加

S3 スタイルのサブドメイン (例: bucket-name.domain-name.com) で Ceph を使用するには、ceph-radosgw デーモンがドメイン名を解決するために使用する DNS サーバーの DNS レコードにワイルドカードを追加します。

dnsmasq の場合は、ホスト名の先頭にドット(.)を付けた以下のアドレス設定を追加します。

address=/.{hostname-or-fqdn}/{host-ip-address}

以下に例を示します。

address=/.gateway-node1/192.168.122.75

bind の場合は、ワイルドカードを DNS レコードに追加します。以下に例を示します。

$TTL    604800
@       IN      SOA     gateway-node1. root.gateway-node1. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      gateway-node1.
@       IN      A       192.168.122.113
*       IN      CNAME   @

DNS サーバーを再起動して、サブドメインを使用してサーバーに ping し、ceph-radosgw デーモンがサブドメイン要求を処理できるようにします。

ping mybucket.{hostname}

以下に例を示します。

ping mybucket.gateway-node1

DNS サーバーがローカルマシンにある場合は、ローカルマシンのネームサーバーエントリーを追加して /etc/resolv.conf を変更しないといけない場合があります。

最後に、rgw_dns_name = {hostname} 設定を使用して、Ceph 設定ファイルの適切な [client.rgw.{instance}] セクションに DNS サーバーのホスト名またはアドレスを指定します。以下に例を示します。

[client.rgw.rgw1]
...
rgw_dns_name = {hostname}
注記

ベストプラクティスとして、管理ノードや ceph-ansible などの一元的な場所で Ceph 設定ファイルを変更し、必要に応じて設定ファイルを再配布し、クラスター全体で一貫性を確保します。

最後に、Ceph オブジェクトゲートウェイを再起動して DNS 設定を有効にします。

2.8. ロギングの調整およびデバッグ出力

設定手順を完了したら、ロギングの出力を確認して、要件を満たすことを確認してください。設定に問題が発生した場合には、Ceph 設定ファイルの [global] セクションでメッセージおよびデバッグメッセージを増やし、ゲートウェイを再起動して設定の問題のトラブルシューティングを行うことができます。以下に例を示します。

[global]
#append the following in the global section.
debug ms = 1
debug rgw = 20
debug civetweb = 20

これらの設定は起動時に変更することもできます。以下に例を示します。

# ceph tell osd.0 injectargs --debug_civetweb 10/20

Ceph ログファイルは、デフォルトで /var/log/ceph に保存されています。

ロギングおよびデバッグの一般的な詳細は、『Configuration Guide for Red Hat Ceph Storage 3』の「Logging ConfigurationReference 」の章を参照してください。Ceph Object Gateway に固有のロギングに関する詳細は、本書の「ロギング設定リファレンス」の章の「Ceph https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html-single/configuration_guide/#the_ceph_object_gateway Object Gateway 」セクションを参照してください。

2.9. S3 API サーバー側暗号化

Ceph Object Gateway は、S3 API のアップロードしたオブジェクトのサーバー側の暗号化をサポートします。サーバー側の暗号化とは、S3 クライアントが暗号化されていない形式で HTTP 経由でデータを送信し、Ceph Object Gateway はそのデータを暗号化した形式で Ceph Storage Cluster に保存することを意味します。

注記

Red Hat は、SLO(Static Large Object) または DLO(Dynamic Large Object) の S3 オブジェクト暗号化をサポートしません。

重要

暗号化を使用するには、クライアントリクエストは、SSL 接続上でリクエストを送信する 必要があります。Red Hat は、Ceph Object Gateway が SSL を使用しない限り、クライアントからの S3 暗号化をサポートしません。ただし、テスト目的で、管理者は、ランタイム時に rgw_crypt_require_ssl 設定を false に設定し、Ceph 設定ファイルで false に設定して、Ansible 設定ファイルで false に設定し、Ceph Object Gateway の Ansible Playbook を再生して、テスト中に SSL を無効にすることができます。

暗号化キーの管理には、以下の 2 つのオプションがあります。

お客様提供のキー

お客様が提供する鍵を使用する場合、S3 クライアントは暗号鍵を各リクエストと共に渡して、暗号化されたデータの読み取りまたは書き込みを行います。これらのキーを管理するのは、お客様の責任です。各オブジェクトの暗号化に使用する Ceph Object Gateway の鍵を覚えておく必要があります。

Ceph Object Gateway は、Amazon SSE-C 仕様に従って、S3 API で顧客提供のキー動作を実装します。

お客様がキー管理を処理し、S3 クライアントはキーを Ceph Object Gateway に渡すため、Ceph Object Gateway ではこの暗号化モードをサポートするための特別な設定は必要ありません。

キー管理サービス

キー管理サービスを使用する場合、セキュアなキー管理サービスはキーを格納し、Ceph Object Gateway はデータの暗号化または復号の要求に対応するためにキーをオンデマンドで取得します。

Ceph Object Gateway は、Amazon SSE-KMS 仕様に従って S3 API にキー管理サービスの動作を実装します。

重要

現在、テスト済みの唯一のキー管理実装は OpenStack Barbican を使用します。ただし、OpenStack Barbican の使用は、まだ完全にサポートされていません。これを実稼働環境で使用する唯一の方法は、サポート例外を取得することです。詳細については、テクニカルサポート にお問い合わせください。

2.10. ゲートウェイのテスト

REST インターフェースを使用するには、まず S3 インターフェース用に初期 Ceph Object Gateway ユーザーを作成します。次に、Swift インターフェースのサブユーザーを作成します。その後、作成したユーザーがゲートウェイにアクセスできるかどうかを確認する必要があります。

2.10.1. S3 ユーザーの作成

ゲートウェイをテストするには、S3 ユーザーを作成し、ユーザーにアクセス権を付与します。man radosgw-admin コマンドは、追加のコマンドオプションに関する情報を提供します。

注記

マルチサイトのデプロイメントでは、マスターゾーングループのマスターゾーンにあるホストでユーザーを作成します。

前提条件

  • root または sudo アクセス
  • Ceph Object Gateway がインストールされている。

手順

  1. S3 ユーザーを作成します。

    radosgw-admin user create --uid=name --display-name="First User"

    name を、S3 ユーザーの名前に置き換えます。以下に例を示します。

    [root@master-zone]# radosgw-admin user create --uid="testuser" --display-name="First User"
    {
        "user_id": "testuser",
        "display_name": "First User",
        "email": "",
        "suspended": 0,
        "max_buckets": 1000,
        "auid": 0,
        "subusers": [],
        "keys": [
            {
                "user": "testuser",
                "access_key": "CEP28KDIQXBKU4M15PDC",
                "secret_key": "MARoio8HFc8JxhEilES3dKFVj8tV3NOOYymihTLO"
            }
        ],
        "swift_keys": [],
        "caps": [],
        "op_mask": "read, write, delete",
        "default_placement": "",
        "placement_tags": [],
        "bucket_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "user_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "temp_url_keys": [],
        "type": "rgw"
    }
  2. 出力を確認し、access_key および secret_key の値に JSON エスケープ文字 (\) が含まれていないことを確認します。これらの値はアクセスの検証に必要ですが、値に JSON エスケープ文字が含まれる場合、特定のクライアントは処理できません。この問題を修正するには、以下のアクションのいずれかを実行します。

    • JSON エスケープ文字を削除します。
    • 文字列を引用符で囲みます。
    • キーを再生成し、JSON エスケープ文字を含まないことを確認します。
    • キーおよびシークレットを手動で指定します。

    正引きスラッシュ / は有効な文字であるため、削除しないでください。

2.10.2. Swift ユーザーの作成

Swift インターフェースをテストするには、Swift サブユーザーを作成します。Swift ユーザーの作成は 2 つの手順です。最初のステップでは、ユーザーを作成します。次のステップでは、秘密鍵を作成します。

注記

マルチサイトのデプロイメントでは、マスターゾーングループのマスターゾーンにあるホストでユーザーを作成します。

前提条件

  • root または sudo アクセス
  • Ceph Object Gateway がインストールされている。

手順

  1. Swift ユーザーを作成します。

    radosgw-admin subuser create --uid=name --subuser=name:swift --access=full

    name を Swift ユーザーの名前に置き換えます。以下に例を示します。

    [root@master-zone]# radosgw-admin subuser create --uid=testuser --subuser=testuser:swift --access=full
    {
        "user_id": "testuser",
        "display_name": "First User",
        "email": "",
        "suspended": 0,
        "max_buckets": 1000,
        "auid": 0,
        "subusers": [
            {
                "id": "testuser:swift",
                "permissions": "full-control"
            }
        ],
        "keys": [
            {
                "user": "testuser",
                "access_key": "O8JDE41XMI74O185EHKD",
                "secret_key": "i4Au2yxG5wtr1JK01mI8kjJPM93HNAoVWOSTdJd6"
            }
        ],
        "swift_keys": [
            {
                "user": "testuser:swift",
                "secret_key": "13TLtdEW7bCqgttQgPzxFxziu0AgabtOc6vM8DLA"
            }
        ],
        "caps": [],
        "op_mask": "read, write, delete",
        "default_placement": "",
        "placement_tags": [],
        "bucket_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "user_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "temp_url_keys": [],
        "type": "rgw"
    }
  2. シークレットキーを作成します。

    radosgw-admin key create --subuser=name:swift --key-type=swift --gen-secret

    name を Swift ユーザーの名前に置き換えます。以下に例を示します。

    [root@master-zone]# radosgw-admin key create --subuser=testuser:swift --key-type=swift --gen-secret
    {
        "user_id": "testuser",
        "display_name": "First User",
        "email": "",
        "suspended": 0,
        "max_buckets": 1000,
        "auid": 0,
        "subusers": [
            {
                "id": "testuser:swift",
                "permissions": "full-control"
            }
        ],
        "keys": [
            {
                "user": "testuser",
                "access_key": "O8JDE41XMI74O185EHKD",
                "secret_key": "i4Au2yxG5wtr1JK01mI8kjJPM93HNAoVWOSTdJd6"
            }
        ],
        "swift_keys": [
            {
                "user": "testuser:swift",
                "secret_key": "a4ioT4jEP653CDcdU8p4OuhruwABBRZmyNUbnSSt"
            }
        ],
        "caps": [],
        "op_mask": "read, write, delete",
        "default_placement": "",
        "placement_tags": [],
        "bucket_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "user_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "temp_url_keys": [],
        "type": "rgw"
    }

2.10.3. S3 アクセスのテスト

S3 アクセスを検証するには、Python テストスクリプトを作成して実行する必要があります。S3 アクセステストスクリプトは radosgw に接続し、新規バケットを作成し、すべてのバケットを一覧表示します。aws_access_key_id および aws_secret_access_key の値は、radosgw_admin コマンドで返される access_key および secret_key の値から取得されます。

以下の手順を実行します。

  1. 共通リポジトリーを有効にします。

    # subscription-manager repos --enable=rhel-7-server-rh-common-rpms
  2. python-boto パッケージをインストールします。

    sudo yum install python-boto
  3. Python スクリプトを作成します。

    vi s3test.py
  4. このファイルに、以下の内容を追加します。

    import boto
    import boto.s3.connection
    
    access_key = $access
    secret_key = $secret
    
    boto.config.add_section('s3')
    
    conn = boto.connect_s3(
            aws_access_key_id = access_key,
            aws_secret_access_key = secret_key,
            host = 's3.<zone>.hostname',
            port = <port>,
            is_secure=False,
            calling_format = boto.s3.connection.OrdinaryCallingFormat(),
            )
    
    bucket = conn.create_bucket('my-new-bucket')
    for bucket in conn.get_all_buckets():
    	print "{name}\t{created}".format(
    		name = bucket.name,
    		created = bucket.creation_date,
    )
    1. <zone> を、ゲートウェイサービスを設定しているホストのゾーン名に置き換えます。つまり、gateway host です。ホスト設定が DNS で解決されていることを確認します。<port> をゲートウェイのポート番号に置き換えます。
    2. $access および $secret は、S3 ユーザーの作成セクションの access_key および secret_key の値に置き換えます。
  5. スクリプトを実行します。

    python s3test.py

    出力は以下のようになります。

    my-new-bucket 2015-02-16T17:09:10.000Z

2.10.4. Swift アクセスのテスト

Swift アクセスは、swift コマンドラインクライアントを使用して検証できます。man swift コマンドは、利用可能なコマンドラインオプションの詳細を提供します。

swift クライアントをインストールするには、以下のコマンドを実行します。

sudo yum install python-setuptools
sudo easy_install pip
sudo pip install --upgrade setuptools
sudo pip install --upgrade python-swiftclient

swift アクセスをテストするには、以下のコマンドを実行します。

swift -A http://{IP ADDRESS}:{port}/auth/1.0 -U testuser:swift -K '{swift_secret_key}' list

{IP ADDRESS} を、ゲートウェイサーバーのパブリック IP アドレスに置き換え、{swift_secret_key} を、swift ユーザーに対して実行した radosgw-admin key create コマンドの出力にある値に置き換えます。{port} を、Civetweb で使用しているポート番号に置き換えてください (例:デフォルトは 8080 です)。ポートを置き換えない場合、デフォルトはポート 80 になります。

以下に例を示します。

swift -A http://10.19.143.116:8080/auth/1.0 -U testuser:swift -K '244+fz2gSqoHwR3lYtSbIyomyPHf3i7rgSJrF/IA' list

出力は以下のようになります。

my-new-bucket

2.11. HAProxy/keepalived の設定

Ceph Object Gateway では、オブジェクトゲートウェイの多数のインスタンスを 1 つのゾーンに割り当てることができます。これにより、負荷が増大するとスケールアウトすることができます。つまり、同じゾーングループおよびゾーンとなりますが、HAProxy/keepalived を使用するためにフェデレーションされたアーキテクチャーは必要ありません。各オブジェクトゲートウェイインスタンスには独自の IP アドレスがあるため、HAProxy および keepalived を使用して Ceph Object Gateway サーバー全体で負荷を分散できます。

HAProxy および keepalived のもう 1 つのユースケースは、HAProxy サーバーで HTTPS を終了することです。Red Hat Ceph Storage(RHCS)1.3.x は Civetweb を使用し、RHCS 1.3.x の実装は HTTPS をサポートしません。HAProxy サーバーを使用して HAProxy サーバーで HTTPS を終了でき、HAProxy サーバーと Civetweb ゲートウェイインスタンスの間で HTTP を使用できます。

2.11.1. HAProxy/keepalived の要件

Ceph Object Gateway で HA プロキシーを設定するには、以下が必要です。

  • 実行中の Ceph クラスター
  • ポート 80 で実行されるように設定している同じゾーン内の少なくとも 2 つの Ceph Object Gateway サーバー。簡単なインストールの手順に従うと、ゲートウェイインスタンスはデフォルトで同じゾーングループとゾーンに存在します。フェデレーションされたアーキテクチャーを使用している場合は、インスタンスが同じゾーングループとゾーンにあることを確認します。
  • HAProxy および keepalived の場合は少なくとも 2 台のサーバー。
注記

本セクションでは、少なくとも 2 つの Ceph Object Gateway サーバーが実行されていることを前提とし、ポート 80 でテストスクリプトを実行する際に、このいずれかのサーバーからの有効な応答を取得していることを前提としています。

HAProxy および keepalived の詳細な説明は、『ロードバランサーの管理』を参照してください。

2.11.2. HAProxy ノードの準備

以下の設定は、haproxyhaproxy2 という名前の 2 つの HAProxy ノードと、rgw1rgw2 という名前の 2台の Ceph Object Gateway サーバーを前提としています。希望の命名規則を使用できます。2 つ以上の HAProxy ノードで以下の手順を実行します。

  1. RHEL 7.x をインストールします。
  2. ノードを登録します。

    [root@haproxy]# subscription-manager register
  3. RHEL サーバーのリポジトリーを有効にします。

    [root@haproxy]# subscription-manager repos --enable=rhel-7-server-rpms
  4. サーバーを更新します。

    [root@haproxy]# yum update -y
  5. 必要に応じて管理ツール (wgetvim など) をインストールします。
  6. ポート 80 を開きます。

    [root@haproxy]# firewall-cmd --zone=public --add-port 80/tcp --permanent
    [root@haproxy]# firewall-cmd --reload
  7. HTTPS の場合は、ポート 443 を開きます。

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

2.11.3. keepalived のインストールおよび設定

2 つ以上の HAProxy ノードで以下の手順を実行します。

前提条件

  • 最低でも 2 つの HAProxy ノード。
  • 最小 2 つの Object Gateway ノード。

手順

  1. keepalived をインストールします。

    [root@haproxy]# yum install -y keepalived
  2. 両方の HAProxy ノードで keepalived を設定します。

    [root@haproxy]# vim /etc/keepalived/keepalived.conf

    設定ファイルには、haproxy プロセスを確認するスクリプトがあります。

    vrrp_script chk_haproxy {
      script "killall -0 haproxy" # check the haproxy process
      interval 2 # every 2 seconds
      weight 2 # add 2 points if OK
    }

    次に、マスターロードバランサーとバックアップロードバランサーのインスタンスは、ネットワークインターフェイスとして eno1 を使用します。また、仮想 IP アドレス (192.168.1.20) も割り当てます。

    マスターロードバランサーノード

    vrrp_instance RGW {
        state MASTER # might not be necessary. This is on the Master LB node.
        @main interface eno1
        priority 100
        advert_int 1
        interface eno1
        virtual_router_id 50
        @main unicast_src_ip 10.8.128.43 80
        unicast_peer {
               10.8.128.53
               }
        authentication {
            auth_type PASS
            auth_pass 1111
        }
        virtual_ipaddress {
            192.168.1.20
        }
        track_script {
          chk_haproxy
        }
    }
    virtual_server 192.168.1.20 80 eno1 { #populate correct interface
        delay_loop 6
        lb_algo wlc
        lb_kind dr
        persistence_timeout 600
        protocol TCP
        real_server 10.8.128.43 80 { # ip address of rgw2 on physical interface, haproxy listens here, rgw listens to localhost:8080 or similar
            weight 100
            TCP_CHECK { # perhaps change these to a HTTP/SSL GET?
                connect_timeout 3
            }
        }
        real_server 10.8.128.53 80 { # ip address of rgw3 on physical interface, haproxy listens here, rgw listens to localhost:8080 or similar
            weight 100
            TCP_CHECK { # perhaps change these to a HTTP/SSL GET?
                connect_timeout 3
            }
        }
    }

    ロードバランサーノードのバックアップ

    vrrp_instance RGW {
        state BACKUP # might not be necessary?
        priority 99
        advert_int 1
        interface eno1
        virtual_router_id 50
        unicast_src_ip 10.8.128.53 80
        unicast_peer {
               10.8.128.43
               }
        authentication {
            auth_type PASS
            auth_pass 1111
        }
        virtual_ipaddress {
            192.168.1.20
        }
        track_script {
          chk_haproxy
        }
    }
    virtual_server 192.168.1.20 80 eno1 { #populate correct interface
        delay_loop 6
        lb_algo wlc
        lb_kind dr
        persistence_timeout 600
        protocol TCP
        real_server 10.8.128.43 80 { # ip address of rgw2 on physical interface, haproxy listens here, rgw listens to localhost:8080 or similar
            weight 100
            TCP_CHECK { # perhaps change these to a HTTP/SSL GET?
                connect_timeout 3
            }
        }
        real_server 10.8.128.53 80 { # ip address of rgw3 on physical interface, haproxy listens here, rgw listens to localhost:8080 or similar
            weight 100
            TCP_CHECK { # perhaps change these to a HTTP/SSL GET?
                connect_timeout 3
            }
        }
    }

  3. keepalived サービスを有効にして開始します。

    [root@haproxy]# systemctl enable keepalived
    [root@haproxy]# systemctl start keepalived

関連情報

2.11.4. HAProxy のインストールおよび設定

2 つ以上の HAProxy ノードで以下の手順を実行します。

  1. haproxy をインストールします。

    [root@haproxy]# yum install haproxy
  2. SELinux および HTTP に対して haproxy を設定します。

    [root@haproxy]# vim /etc/firewalld/services/haproxy-http.xml

    以下の行を追加します。

    <?xml version="1.0" encoding="utf-8"?>
    <service>
    <short>HAProxy-HTTP</short>
    <description>HAProxy load-balancer</description>
    <port protocol="tcp" port="80"/>
    </service>

    root として、正しい SELinux コンテキストとファイルパーミッションを haproxy-http.xml ファイルに割り当てます。

    [root@haproxy]# cd /etc/firewalld/services
    [root@haproxy]# restorecon haproxy-http.xml
    [root@haproxy]# chmod 640 haproxy-http.xml
  3. HTTPS を使用する場合は、SELinux および HTTPS に対して haproxy を設定します。

    [root@haproxy]# vim /etc/firewalld/services/haproxy-https.xml

    以下の行を追加します。

    <?xml version="1.0" encoding="utf-8"?>
    <service>
    <short>HAProxy-HTTPS</short>
    <description>HAProxy load-balancer</description>
    <port protocol="tcp" port="443"/>
    </service>

    root で、正しい SELinux コンテキストとファイルパーミッションを haproxy-https.xml ファイルに割り当てます。

    # cd /etc/firewalld/services
    # restorecon haproxy-https.xml
    # chmod 640 haproxy-https.xml
  4. HTTPS を使用する場合は、SSL のキーを生成します。証明書がない場合は、自己署名証明書を使用できます。キーを生成するには、Red Hat Enterprise Linux 7 の『システム管理者のガイド』「新しい鍵および証明書の生成」セクションを参照してください。

    最後に、証明書と鍵を PEM ファイルに格納します。

    [root@haproxy]# cat example.com.crt example.com.key > example.com.pem
    [root@haproxy]# cp example.com.pem /etc/ssl/private/
  5. haproxy を設定します。

    [root@haproxy]# vim /etc/haproxy/haproxy.cfg

    global および defaults は変更しない可能性があります。defaults セクションの後に、frontend セクションおよび backend セクションを設定する必要があります。以下に例を示します。

    frontend http_web *:80
        mode http
        default_backend rgw
    
    frontend rgw­-https
      bind *:443 ssl crt /etc/ssl/private/example.com.pem
      default_backend rgw
    
    backend rgw
        balance roundrobin
        mode http
        server  rgw1 10.0.0.71:80 check
        server  rgw2 10.0.0.80:80 check

    HAProxy 設定の詳細な説明は、「HAProxy 設定」を参照してください。

  6. haproxy の有効化/起動

    [root@haproxy]# systemctl enable haproxy
    [root@haproxy]# systemctl start haproxy

2.11.5. HAProxy 設定のテスト

HAProxy ノードで、keepalived 設定からの仮想 IP アドレスが表示されることを確認します。

[root@haproxy]# ip addr show

calamari ノードで、ロードバランサー設定を使用してゲートウェイノードに到達できるかどうかを確認してください。以下に例を示します。

[root@haproxy]# wget haproxy

上記のコマンドの結果は以下のコマンドと同じになるはずです。

[root@haproxy]# wget rgw1

以下の内容を含む index.html ファイルを返す場合は、次のコマンドを実行します。

<?xml version="1.0" encoding="UTF-8"?>
	<ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
		<Owner>
			<ID>anonymous</ID>
			<DisplayName></DisplayName>
		</Owner>
		<Buckets>
		</Buckets>
	</ListAllMyBucketsResult>

その後、設定が適切に機能します。

2.12. 静的 Web ホスティングのゲートウェイの設定

従来の Web ホストには、Web サイトごとに Web サーバーをセットアップする必要があります。これは、コンテンツを動的に変更しない場合にリソースを効率よく使用できます。Ceph Object Gateway は、S3 バケットで静的 Web サイトをホストすることができます。つまり、PHP、サーブレット、データベース、nodejs などのサーバー側のサービスを使用しないサイトです。このアプローチは、各サイトに Web サーバーを使用する仮想マシンを設定するよりも大きな経済です。

2.12.1. 静的 Web ホスティングの前提条件

静的 Web ホストには、少なくとも 1 つの Ceph Storage クラスター、および静的 Web サイト用に 2 つ以上の Ceph Object Gateway インスタンスが必要です。Red Hat は、各ゾーンに複数のゲートウェイインスタンスが HAProxy/keepalived によって負荷分散されることを前提としています。

注記

Red Hat は、Ceph Object Gateway インスタンスを使用した標準の S3/Swift API と静的 Web ホストの両方を同時にデプロイすることはサポート されません

2.12.2. 静的 Web ホスティングの要件

静的 Web をホストする機能は独自の API を使用するので、S3 バケットで静的 Web サイトを使用するようにゲートウェイを設定するには、以下が必要です。

  1. S3 静的 Web ホストでは、標準の S3/Swift API のユースケースに使用されるインスタンスとは別の Ceph Object Gateway インスタンスを使用します。
  2. S3 静的 Web サイトをホストするゲートウェイインスタンスには、標準の S3/Swift API ゲートウェイインスタンスから別のドメイン名オーバーしないドメイン名がなければなりません。
  3. S3 静的 Web サイトをホストするゲートウェイインスタンスは、標準の S3/Swift API ゲートウェイインスタンスとは異なるパブリック向け IP アドレスを使用する必要があります。
  4. S3 静的 Web サイトの負荷分散をホストするゲートウェイインスタンス。また、必要な場合には HAProxy/keepalived を使用して SSL を終了します。

2.12.3. 静的 Web ホスティングゲートウェイの設定

静的 Web ホストのゲートウェイを有効にするには、Ceph 設定ファイルを編集して、以下の設定を追加します。

[client.rgw.<STATIC-SITE-HOSTNAME>]
...
rgw_enable_static_website = true
rgw_enable_apis = s3, s3website
rgw_dns_name = objects-zonegroup.domain.com
rgw_dns_s3website_name = objects-website-zonegroup.domain.com
rgw_resolve_cname = true
...

rgw_enable_static_website 設定は true にする必要があります。rgw_enable_apis 設定 は s3website API を有効にする必要があります。rgw_dns_name 設定および rgw_dns_s3website_name 設定は、完全修飾ドメインを提供する必要があります。サイトが標準的な名前の拡張子を使用する場合は、rgw_resolve_cnametrue に設定します。

重要

rgw_dns_name および rgw_dns_s3website_name の完全修飾ドメイン名は重複 しないでください

2.12.4. 静的 Web ホスティング DNS 設定

以下は、想定される DNS 設定の例です。最初の 2 つの行は、標準の S3 インターフェースを使用してゲートウェイインスタンスのドメインを指定し、IPv4 と IPv6 アドレスをそれぞれ指定します。3 行目は、正規名の拡張を使用して S3 バケットのワイルドカード CNAME 設定を提供します。4 行目と 5 番目の行は、S3 Web サイトインターフェースを使用してゲートウェイインスタンスのドメインを指定し、IPv4 と IPv6 アドレスを参照します。

objects-zonegroup.domain.com. IN    A 192.0.2.10
objects-zonegroup.domain.com. IN AAAA 2001:DB8::192:0:2:10
*.objects-zonegroup.domain.com. IN CNAME objects-zonegroup.domain.com.
objects-website-zonegroup.domain.com. IN    A 192.0.2.20
objects-website-zonegroup.domain.com. IN AAAA 2001:DB8::192:0:2:20
注記

最初の 2 つの行の IP アドレスは、4 行目と 5 行目の IP アドレスとは異なります。

マルチサイト設定で Ceph Object Gateway を使用する場合は、ルーティングソリューションを使用して、クライアントに最も近いゲートウェイにトラフィックをルーティングすることを検討してください。

Amazon Web Service(AWS)では、静的 Web ホストバケットがホスト名と一致する必要があります。Ceph は DNS を設定するいくつかの方法を提供し、プロキシーに適合する証明書がある場合に HTTPS は機能します

サブドメインのバケットへのホスト名

AWS スタイルの S3 サブドメインを使用するには、DNS エントリーでワイルドカードを使用し、要求をすべてのバケットにリダイレクトできます。DNS エントリーは以下のようになります。

*.objects-website-zonegroup.domain.com. IN CNAME objects-website-zonegroup.domain.com.

以下の方法でバケット名にアクセスします。

http://bucket1.objects-website-zonegroup.domain.com

バケット名は bucket1 です。

一致するバケットへのホスト名

Ceph は、要求にバケット名を含めずに、ドメイン名からバケットへのマッピングをサポートします。これは、Ceph Object Gateway に固有のものです。ドメイン名を使用してバケットにアクセスするには、ドメイン名をバケット名にマッピングします。DNS エントリーは以下のようになります。

www.example.com. IN CNAME bucket2.objects-website-zonegroup.domain.com.

バケット名は bucket2 です。

次の方法でバケットにアクセスします。

http://www.example.com

Hostname to Long Bucket with CNAME

AWS は通常、バケット名が一致する必要があります。CNAME を使用して静的 Web ホストの DNS を設定するには、DNS エントリーは以下のようになります。

www.example.com. IN CNAME www.example.com.objects-website-zonegroup.domain.com.

次の方法でバケットにアクセスします。

http://www.example.com

CNAME のない Long バケットへのホスト名

DNS 名には、SOANSMXTXT などの他の非 CNAME レコードが含まれている場合、DNS レコードはドメイン名を IP アドレスに直接マップする必要があります。以下に例を示します。

www.example.com. IN A 192.0.2.20
www.example.com. IN AAAA 2001:DB8::192:0:2:20

次の方法でバケットにアクセスします。

http://www.example.com

2.12.5. 静的 Web ホスティングサイトの作成

静的 Web サイトを作成するには、以下の手順を行います。

  1. S3 バケットを作成します。バケット名は Web サイトのドメイン名と同じです。たとえば、mysite.com のバケット名は mysite.com になります。これは AWS で必要ですが、Ceph には必要ありません。詳細は「DNS 設定」を参照してください。
  2. 静的 Web サイトのコンテンツをバケットにアップロードします。コンテンツには、HTML、CSS、クライアント側の JavaScript、イメージ、音声/ビデオコンテンツなどのダウンロード可能なファイルが含まれます。Web サイトには index.html ファイルが必要で、error.html ファイルも利用できます。
  3. Web サイトの内容を確認します。この時点で、バケットの作成者のみがコンテンツにアクセスできます。
  4. ファイルに権限を設定し、それらが一般的に読み取り可能になるようにします。

2.13. 名前空間の NFS-Ganesha へのエクスポート

Red Hat Ceph Storage 3 では、Ceph Object Gateway は、実稼働システムに NFS バージョン 3 および NFS バージョン 4.1 を使用して S3 オブジェクトの名前空間をエクスポートする機能を提供します。

注記

NFS Ganesha 機能は汎用性ではなく、S3 クラウドのみへの移行用です。

この実装は、UNIX 形式のパス名を S3 バケットおよびオブジェクトにマップする Amazon Web Services(AWS)階層 namespace 規則に準拠します。NFSv4 擬似ルートに含まれる接続済み名前空間の最上位は、Ceph Object Gateway S3 バケットで構成されます。バケットは NFS ディレクトリーとして表現されます。バケット内のオブジェクトは、NFS ファイルとディレクトリー階層(S3 規則に従う)として提示されます。ファイルおよびディレクトリーを作成する操作がサポートされています。

注記

ハードリンクまたはソフトリンクの作成または削除はサポートされません。バケットまたはディレクトリーの名前が NFS によってサポートされるようにする一方、ディレクトリー内で、ディレクトリー内で、またファイルシステムと NFS マウントの間にサポートされるファイルの名前は変更されます。ファイルの名前変更操作は、NFS 上で行う場合、ターゲットディレクトリーを変更し、通常は完全な readdir を強制的に更新するため、コストが高くなります。

注記

NFS マウントでファイルを編集することはサポートされていません。

注記

Ceph Object Gateway では、アプリケーションがオフセット 0 からファイルの最後に連続して書き込む必要があります。順序を外すと、アップロード操作が失敗します。この問題を回避するには、ファイルを NFS 領域にコピーする際に、cpcatrsync などのユーティリティーを使用します。常に sync オプションでマウントします。

NFS を使用する Ceph Object Gateway は、ゲートウェイサーバーのインプロセスライブラリーパッケージと、NFS-Ganesha NFS サーバー用の File System Abstraction Layer(FSAL)ネームスペースドライバーに基づいています。ランタイム時に、Ceph Object Gateway デーモンのインスタンスは、完全な Ceph Object Gateway デーモンと、Civetweb HTTP サービスなしで単一プロセスの NFS-Ganesha インスタンスの組み合わせです。この機能を使用するには、NFS-Ganesha バージョン 2.3.2 以降をデプロイします。

NFS-Ganesha (nfs-ganesha-rgw) インスタンスを含むホストで「作業を開始する前に」および「NFS-Ganesha インスタンス」 のステップを実行します。

複数の NFS ゲートウェイの実行

各 NFS-Ganesha インスタンスは完全なゲートウェイエンドポイントとして機能し、現在は NFS-Ganesha インスタンスを HTTP サービスをエクスポートするように設定することはできません。通常のゲートウェイインスタンスの場合のように、任意の数の NFS-Ganesha インスタンスを開始し、クラスターから同じまたは異なるリソースをエクスポートします。これにより、NFS-Ganesha インスタンスのクラスタリングが可能になります。ただし、これは高可用性を意味するものではありません。

通常のゲートウェイインスタンスおよび NFS-Ganesha インスタンスが同じデータリソースを重複させると、これらのインスタンスは標準の S3 API と NFS-Ganesha インスタンスの両方からエクスポートされます。NFS-Ganesha インスタンスを同じホストに Ceph Object Gateway インスタンスと同じ場所に配置することができます。

作業を開始する前に

  1. NFS-Ganesha を実行する前に、NFS-Ganesha を実行するホストで実行中のカーネル NFS サービスインスタンスをすべて無効にします。NFS-Ganesha は、別の NFS インスタンスが実行している場合は起動しません。
  2. rpcbind サービスが実行していることを確認します。

    # systemctl start rpcbind
    注記

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

    NFS の rpcbind の使用方法の詳細は、Red Hat Enterprise Linux 7 の『ストレージ管理ガイド』の「必要なサービス」セクションを参照してください。

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

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

NFS-Ganesha インスタンスの設定

  1. nfs-ganesha-rgw パッケージをインストールします。

    $ sudo apt-get install nfs-ganesha-rgw
  2. Ceph Monitor ノードから NFS-Ganesha ホストの /etc/ceph/ ディレクトリーに Ceph 設定ファイルをコピーし、必要に応じて編集します。

    # scp <mon-host>:/etc/ceph/ceph.conf <nfs-ganesha-rgw-host>:/etc/ceph
    注記

    Ceph 構成ファイルには、有効な [client.rgw.{instance-name}] セクションと、rgw_datakeyringrgw_frontends など、必要なさまざまな Gateway 設定変数が含まれている必要があります。有効な S3 バケットの命名要件に準拠していない Swift コンテナーをエクスポートする場合は、Ceph 設定ファイルの [client.rgw] セクションで rgw_relaxed_s3_bucket_namestrue に設定します。たとえば、Swift コンテナー名にアンダースコアが含まれる場合、これは有効な S3 バケット名ではなく、rgw_relaxed_s3_bucket_namestrue に設定されていない限り同期されません。NFS 外にオブジェクトおよびバケットを追加すると、これらのオブジェクトは、デフォルトで rgw_nfs_namespace_expire_secs によって設定された時間に NFS 名前空間に表示されます。デフォルトでは約 5 分です。Ceph 設定ファイルの rgw_nfs_namespace_expire_secs のデフォルト値を上書きして、更新レートを変更します。

  3. NFS-Ganesha 設定ファイルを開きます。

    # vim /etc/ganesha/ganesha.conf
  4. FSAL (File System Abstraction Layer) ブロックを使用して EXPORT セクションを設定します。ID、S3 ユーザー ID、S3 アクセスキー、およびシークレットを指定します。NFSv4 の場合、以下のようになります。

    EXPORT
    {
            Export_ID={numeric-id};
            Path = "/";
            Pseudo = "/";
            Access_Type = RW;
            SecType = "sys";
            NFS_Protocols = 4;
            Transport_Protocols = TCP;
            Squash = No_Root_Squash;
    
            FSAL {
                    Name = RGW;
                    User_Id = {s3-user-id};
                    Access_Key_Id ="{s3-access-key}";
                    Secret_Access_Key = "{s3-secret}";
            }
    }

    Path オプションは、エクスポートを見つける場所を Ganesha に指示します。VFS FSAL の場合、これはサーバーの名前空間内の場所です。他の FSAL の場合、その FSAL の名前空間によって管理されるファイルシステム内の場所となる場合があります。たとえば、CephFSAL を使用して CephFS ボリューム全体をエクスポートする場合、Path/ になります。

    Pseudo オプションは、Ganesha に対して NFS v4 の擬似ファイルシステムの名前空間内にエクスポートを配置するよう指示します。NFS v4 は、サーバーは擬似名前空間を構築します。これは、実際にエクスポートの場所に対応しておらず、その擬似ファイルシステムの一部が NFS サーバーのレルム内にのみ存在する可能性があり、いずれの物理ディレクトリーに対応しているとは限りません。さらに、NFS v4 サーバーは、そのすべてのエクスポートを 1 つの namespace 内に配置します。擬似ファイルシステムルートとしてエクスポート 1 つをエクスポートできますが、擬似ファイルシステムに複数のエクスポートを配置する方がはるかに一般的です。従来の VFS では、多くの場合、Pseudo の場所は Path の場所と同じです。/Path として使用して CephFS エクスポート例に戻る場合、複数のエクスポートが必要な場合は、エクスポートに Pseudo オプションが他にない可能性があります。たとえば、/ceph です。

    NFSv3 に対応する EXPORT ブロックには、NFS_Protocols 設定でバージョン 3 を含める必要があります。さらに、NFSv3 は、UDP トランスポートに対応する最新のメジャーバージョンです。標準の UDP が含まれる初期のバージョンは、RFC 7530 でその使用を禁止します。UDP を有効にするには、Transport_Protocols 設定に追加します。以下に例を示します。

    EXPORT {
    ...
        NFS_Protocols = 3,4;
        Transport_Protocols = UDP,TCP;
    ...
    }

    SecType = sys; を設定することで、クライアントは Kerberos 認証なしで接続できます。

    Squash = No_Root_Squash; を設定すると、ユーザーは NFS マウント内のディレクトリー所有権を変更できます。

    従来の OS ネイティブ NFS 4.1 クライアントを使用する NFS クライアントは通常、移行先サーバーの pseudofs root で定義されるエクスポートされたファイルシステムのフェデレーションされた名前空間を表示します。Ceph Object Gateway はいくつでもエクスポートすることができます。

    各エクスポートには、nameUser_IdAccess_Key、および Secret_Access_Key という独自のタプルがあり、指定されたユーザーが確認できるオブジェクトの名前空間のプロキシーを作成します。

    ganesha.conf のエクスポートには、NFSV4 ブロックを含めることもできます。Red Hat Ceph Storage では、idmapper プログラムを設定する代わりに、Allow_Numeric_Owners パラメーターおよび Only_Numberic_Owners パラメーターサポートされます。

    NFSV4 {
        Allow_Numeric_Owners = true;
        Only_Numeric_Owners = true;
    }
  5. NFS_CORE_PARAM ブロックを設定します。

    NFS_CORE_PARAM{
        mount_path_pseudo = true;
    }

    mount_path_pseudo 構成設定は、true に設定すると、NFS v3 および NFS v4.x のマウントが同じサーバー側パスを使用してエクスポートに到達させます。

        mount -o vers=3 <IP ADDRESS>:/export /mnt
        mount -o vers=4 <IP ADDRESS>:/export /mnt
    Path            Pseudo          Tag     Mechanism   Mount
    /export/test1   /export/test1   test1   v3 Pseudo   mount -o vers=3 server:/export/test1
    /export/test1   /export/test1   test1   v3 Tag      mount -o vers=3 server:test1
    /export/test1   /export/test1   test1   v4 Pseudo   mount -o vers=4 server:/export/test1
    /               /export/ceph1   ceph1   v3 Pseudo   mount -o vers=3 server:/export/ceph1
    /               /export/ceph1   ceph1   v3 Tag      mount -o vers=3 server:ceph1
    /               /export/ceph1   ceph1   v4 Pseudo   mount -o vers=4 server:/export/ceph1
    /               /export/ceph2   ceph2   v3 Pseudo   mount -o vers=3 server:/export/ceph2
    /               /export/ceph2   ceph2   v3 Tag      mount -o vers=3 server:ceph2
    /               /export/ceph2   ceph2   v4 Pseudo   mount -o vers=4

    mount_path_pseudo の構成設定を false に設定すると、NFS v3 は Path オプションを使用し、NFS v4.x マウントは Pseudo オプションを使用します。

    Path            Pseudo          Tag     Mechanism   Mount
    /export/test1   /export/test1   test1   v3 Path     mount -o vers=3 server:/export/test1
    /export/test1   /export/test1   test1   v3 Tag      mount -o vers=3 server:test1
    /export/test1   /export/test1   test1   v4 Pseudo   mount -o vers=4 server:/export/test1
    /               /export/ceph1   ceph1   v3 Path     mount -o vers=3 server:/
    /               /export/ceph1   ceph1   v3 Tag      mount -o vers=3 server:ceph1
    /               /export/ceph1   ceph1   v4 Pseudo   mount -o vers=4 server:/export/ceph1
    /               /export/ceph2   ceph2   v3 Path     not accessible
    /               /export/ceph2   ceph2   v3 Tag      mount -o vers=3 server:ceph2
    /               /export/ceph2   ceph2   v4 Pseudo   mount -o vers=4 server:/export/ceph2
  6. RGW セクションを設定します。インスタンスの名前を指定し、Ceph 設定ファイルへのパスを指定し、初期化引数を指定します。

    RGW {
        name = "client.rgw.{instance-name}";
        ceph_conf = "/etc/ceph/ceph.conf";
        init_args = "--{arg}={arg-value}";
    }
  7. /etc/ganesha/ganesha.conf 設定ファイルを保存します。
  8. nfs-ganesha サービスを有効にして開始します。

    # systemctl enable nfs-ganesha
    # systemctl start nfs-ganesha
  9. 擬似ディレクトリーが非常に大きい場合には、ceph.conf ファイルの設定可能なパラメーター rgw_nfs_s3_fast_attrstrue に設定して、名前をイミュータブルかつ加速します。

    rgw_nfs_s3_fast_attrs= true
  10. 各ゲートウェイノードから Ceph Object Gateway サービスを再起動します。

    # systemctl restart ceph-radosgw.target

NFSv4 クライアントの設定

namespace にアクセスするには、設定済みの NFS-Ganesha エクスポートをローカルの POSIX namespace の必要な場所にコピーします。前述のように、この実装にはいくつかの一意な制限があります。

  • NFS 4.1 以降のプロトコルフレーバーのみがサポートされます。
  • 書き込み順序を設定するには、sync マウントオプションを使用します。

NFS-Ganesha エクスポートをマウントするには、クライアントホストの /etc/fstab ファイルに以下のエントリーを追加します。

<ganesha-host-name>:/ <mount-point> nfs noauto,soft,nfsvers=4.1,sync,proto=tcp 0 0

NFS-Ganesha ホスト名およびクライアントのマウントポイントへのパスを指定します。

注記

NFS-Ganesha エクスポートを正常にマウントするには、クライアントに /sbin/mount.nfs ファイルが存在する必要があります。nfs-tools パッケージはこのファイルを提供します。多くの場合、パッケージはデフォルトでインストールされます。ただし、nfs-tools パッケージがクライアントにインストールされていることを確認し、インストールされていない場合はインストールします。

NFS の詳細は、Red Hat Enterprise Linux 7 の『ストレージ管理ガイド』の「ネットワークファイルシステム (NFS)」の章を参照してください。

NFSv3 クライアントの設定

マウントオプションとして nfsvers=3 および noacl を指定して、Linux クライアントが NFSv3 でマウントされるように設定できます。UDP をトランスポートとして使用するには、proto=udp をマウントオプションに追加します。ただし、TCP が優先されるプロトコルです。

<ganesha-host-name>:/ <mount-point> nfs noauto,noacl,soft,nfsvers=3,sync,proto=tcp 0 0
注記

NFS Ganesha EXPORT ブロックの Protocols 設定をバージョン 3 に設定し、マウントがバージョン 3 を UDP で使用する場合は Transports 設定を UDP に設定します。

NFSv3 は、クライアント OPEN および CLOSE 操作はファイルサーバーに通信しないため、RGW NFS はこれらの操作を使用してファイルアップロードトランザクションの最初と最後をマークすることはできません。その代わりに、最初の書き込みがオフセット 0 のファイルに送信されると、RGW NFS は新しいアップロードを開始しようとします。そして、ファイルへの新規書き込みが一定期間確認されない場合に、アップロードが確定します。​デフォルトでは 10 秒かかります。この値を変更するには、Ceph 設定ファイルの RGW セクションに rgw_nfs_write_completion_interval_s の値を設定します。

第3章 管理

管理者は、radosgw-admin コマンドラインインターフェースを使用して Ceph Object Gateway を管理できます。

3.1. 管理データストレージ

Ceph Object Gateway は、インスタンスのゾーン設定で定義された一連のプールに管理データを格納します。たとえば、後のセクションで説明したバケット、ユーザー、ユーザークォータ、および使用状況の統計は Ceph Storage クラスターのプールに保存されます。デフォルトでは、Ceph Object Gateway は以下のプールを作成し、それらをデフォルトゾーンにマッピングします。

  • .rgw
  • .rgw.control
  • .rgw.gc
  • .log
  • .intent-log
  • .usage
  • .users
  • .users.email
  • .users.swift
  • .users.uid

CRUSH ルールセットと配置グループの数を設定することができるように、これらのプールを手動で作成することを検討する必要があります。通常の設定では、Ceph Object Gateway の管理データを保存するプールは、多くの場合、同じ CRUSH ルールセットを使用して、管理データ用に 10 個のプールがあるため、より少ない配置グループを使用します。詳細は、Red Hat CephStorage 3 の「プールおよびストレージ戦略 ガイド 」を参照してください。

また、配置グループの計算の詳細については、Ceph Placement Groups(PGs)per Pool Calculator も参照してください。mon_pg_warn_max_per_osd 設定は、プールに過剰な配置グループを割り当てると警告します (つまりデフォルトでは 300)。この値は、ニーズやハードウェアの能力に合わせて調整することができ、n は OSD あたりの PG の最大数です。

mon_pg_warn_max_per_osd = n

3.2. ストレージポリシーの作成

Ceph Object Gateway は、配置ターゲットを特定し、配置先に関連付けられたプールにバケットおよびオブジェクトを保存して、クライアントバケットおよびオブジェクトデータを保存します。配置ターゲットを設定しておらず、インスタンスのゾーン設定内のプールにマッピングすると、Ceph Object Gateway はデフォルトのターゲットとプールを使用します (例: default_placement)。

ストレージポリシーにより、Ceph Object Gateway クライアントにストレージストラテジーへのアクセス方法が表示されます。つまり、SSD、SAS ドライブ、SATA ドライブなど、特定タイプのストレージをターゲットにすることができます。持続性、レプリケーション、イレイジャーコーディングなどを保証する特定の方法。詳細は、Red Hat CephStorage 3 の『ストレージ戦略 』を参照してください。

ストレージポリシーを作成するには、以下の手順に従います。

  1. 必要なストレージストラテジーを使用して、新しいプールの .rgw.buckets.special を作成します。たとえば、イレイジャーコーディング、特定の CRUSH ルールセット、レプリカ数、および pg_num 数および pgp_num 数でカスタマイズしたプールなどです。
  2. ゾーングループの設定を取得して、これをファイルに保存します (例: zonegroup.json)。

    構文

    [root@master-zone]# radosgw-admin zonegroup --rgw-zonegroup=<zonegroup_name> get > zonegroup.json

    [root@master-zone]# radosgw-admin zonegroup --rgw-zonegroup=default get > zonegroup.json

  3. zonegroup.json ファイルの placement_target の下に、特別な special-placement を追加します。

    {
    	"name": "default",
    	"api_name": "",
    	"is_master": "true",
    	"endpoints": [],
    	"hostnames": [],
    	"master_zone": "",
    	"zones": [{
    		"name": "default",
    		"endpoints": [],
    		"log_meta": "false",
    		"log_data": "false",
    		"bucket_index_max_shards": 5
    	}],
    	"placement_targets": [{
    		"name": "default-placement",
    		"tags": []
    	}, {
    		"name": "special-placement",
    		"tags": []
    	}],
    	"default_placement": "default-placement"
    }
  4. 変更された zonegroup.json ファイルでゾーングループを設定します。

    [root@master-zone]# radosgw-admin zonegroup set < zonegroup.json
  5. ゾーン設定を取得して、これをファイル (例: zone.json) に保存します。

    [root@master-zone]# radosgw-admin zone get > zone.json
  6. ゾーンファイルを編集し、placement_pool に新しい配置ポリシーキーを追加します。

    {
    	"domain_root": ".rgw",
    	"control_pool": ".rgw.control",
    	"gc_pool": ".rgw.gc",
    	"log_pool": ".log",
    	"intent_log_pool": ".intent-log",
    	"usage_log_pool": ".usage",
    	"user_keys_pool": ".users",
    	"user_email_pool": ".users.email",
    	"user_swift_pool": ".users.swift",
    	"user_uid_pool": ".users.uid",
    	"system_key": {
    		"access_key": "",
    		"secret_key": ""
    	},
    	"placement_pools": [{
    		"key": "default-placement",
    		"val": {
    			"index_pool": ".rgw.buckets.index",
    			"data_pool": ".rgw.buckets",
    			"data_extra_pool": ".rgw.buckets.extra"
    		}
    	}, {
    		"key": "special-placement",
    		"val": {
    			"index_pool": ".rgw.buckets.index",
    			"data_pool": ".rgw.buckets.special",
    			"data_extra_pool": ".rgw.buckets.extra"
    		}
    	}]
    }
  7. 新しいゾーン設定を指定します。

    [root@master-zone]# radosgw-admin zone set < zone.json
  8. ゾーングループマップを更新します。

    [root@master-zone]# radosgw-admin period update --commit

    special-placement エントリーは placement_target として一覧表示されます。

要求の実行時にストレージポリシーを指定するには、以下を実行します。

たとえば、以下のようになります。

$ curl -i http://10.0.0.1/swift/v1/TestContainer/file.txt -X PUT -H "X-Storage-Policy: special-placement" -H "X-Auth-Token: AUTH_rgwtxxxxxx"

3.3. インデックスレスバケットの作成

作成されたバケットがバケットインデックスを使用してオブジェクトインデックス(インデックスレスバケット)を保存しない配置ターゲットを設定できます。データのレプリケーションまたはリストを使用しない配置ターゲットは、インデックスレスバケットを実装する可能性があります。

インデックスレスバケットは、配置ターゲットが特定のバケットのオブジェクトを追跡しないメカニズムを提供します。これにより、オブジェクトの書き込みが行われるたびに発生するリソース競合がなくなり、Ceph Object Gateway が Ceph Storage クラスターに必要なラウンドトリップの数が減ります。これにより、同時操作と、オブジェクト書き込みのパフォーマンスが小さい場合に正の効果を持たせることができます。

配置ターゲットをインデックスなしのものとして指定するには、以下の手順に従います。

  1. zone.json の設定を取得します。

    $ radosgw-admin zone get --rgw-zone=<zone> > zone.json
  2. 新しい配置対象を追加するか、既存の配置対象を変更して "index_type": 1 を持つようにすることで、zone.json を変更します。たとえば以下のようになります。

    "placement_pools": [
        {
          "key": "default-placement",
          "val": {
            "index_pool": "default.rgw.buckets.index",
            "data_pool": "default.rgw.buckets.data",
            "data_extra_pool": "default.rgw.buckets.non-ec",
            "index_type": 1,
            "compression": ""
          }
        },
        {
          "key": "indexless",
          "val": {
            "index_pool": "default.rgw.buckets.index",
            "data_pool": "default.rgw.buckets.data",
            "data_extra_pool": "default.rgw.buckets.non-ec",
            "index_type": 1
          }
        }
      ],
  3. zone.json の設定を設定します。

    $ radosgw-admin zone set --rgw-zone=<zone> --infile zone.json
  4. 新しい配置ターゲットを作成している場合は、zonegroup が新しい配置ターゲットを参照していることを確認します。

    $ radosgw-admin zonegroup get --rgw-zonegroup=<zonegroup> > zonegroup.json
  5. ゾーングループの default_placement を設定します。

    $ radosgw-admin zonegroup placement default --placement-id indexless
  6. 必要に応じて zonegroup.json を変更します。以下に例を示します。

      "placement_targets": [
        {
          "name": "default-placement",
          "tags": []
        },
        {    "name": "indexless",
    		     "tags": []
        }
      ],
      "default_placement": "default-placement",
    $ radosgw-admin zonegroup set --rgw-zonegroup=<zonegroup> < zonegroup.json
  7. クラスターがマルチサイト設定にある場合は、更新およびコミットします。

    $ radosgw-admin period update --commit

この例では、"indexless" ターゲットで作成されたバケットはインデックスレスバケットです。

重要

バケットインデックスはバケットの正しい状態を反映しず、これらのバケットはオブジェクトの一覧を正しく返しません。これは複数の機能に影響します。具体的には、バケットインデックスは変更情報を保存するために使用されないため、これらのバケットはマルチゾーン環境に同期されません。この機能にはバケットインデックスが必要なため、インデックスレスバケットで S3 オブジェクトのバージョン管理を使用することは推奨されません。

注記

インデックスレスバケットを使用すると、単一バケットのオブジェクトの最大数の上限が削除されます。

注記

インデックスのないバケットのオブジェクトを NFS から一覧表示できない

3.4. バケットシャードの設定

Ceph Object Gateway は、バケットインデックスデータをインデックスプール (index_pool) に格納します。デフォルトは .rgw.buckets.index です。クライアントが、多くのオブジェクトから何万万ものオブジェクトを挿入すると、バケットごとにクォータを設定しなくても、インデックスプールはパフォーマンスが大幅に低下する可能性があります。

バケットインデックスのシャーディング は、バケットあたりのオブジェクト数が多い場合のパフォーマンスのボトルネックを防ぐのに役立ちます。

新規バケットにバケットインデックスシャーディングを設定したり、既存のバケットのインデックスを変更したりできます。

バケットインデックスシャーディングを設定するには、以下を実行します。

バケットを再度シャード化するには、以下を実行します。

3.4.1. バケットシャードの制限

重要

注意して、以下の制限を使用してください。お使いのハードウェアの選択には影響があるため、この要件を Red Hat アカウントチームと常に相談してください。

  • シャードが必要になる前に 1 つのバケット内のオブジェクトの最大数: Red Hat は、バケットインデックスのシャードごとに最大 102,400 個のオブジェクトを推奨しています。シャーディングを完全に活用するには、Ceph Object Gateway バケットインデックスプールに十分な数の OSD を提供して最大並列処理を取得します。
  • シャード化の使用時の最大オブジェクト数: 以前のテストに基づき、現在サポートされているバケットインデックスシャードの数は 65521 です。Red Hat の品質保証は、バケットのシャーディングで完全なスケーラビリティーテストを実施していません。

3.4.2. 簡易設定でのバケットインデックスシャード化の設定

すべての新規バケットでバケットインデックスシャードを有効にし、設定するには、rgw_override_bucket_index_max_shards パラメーターを使用します。パラメーターを以下のように設定します。

  • バケットインデックスシャード化を無効にする場合は 0。これがデフォルト値になります。
  • 0 より大きい値を有効にすると、バケットシャード化が有効になり、シャードの最大数が設定されます。

手順

  1. 推奨されるシャード数を計算します。これを行うには、以下の式を使用します。

    number of objects expected in a bucket / 100,000

    シャードの最大数は 65521 です。

  2. Ceph 設定ファイルに rgw_override_bucket_index_max_shards を追加します。

    rgw_override_bucket_index_max_shards = value

    value を、直前の手順で計算したシャードの推奨数に置き換えます。以下に例を示します。

    rgw_override_bucket_index_max_shards = 10
    • Ceph Object Gateway のすべてのインスタンスにバケットインデックスシャードを設定するには、[global] セクションに rgw_override_bucket_index_max_shards を追加します。
    • Ceph Object Gateway の特定のインスタンスに対してのみバケットインデックスのシャーディングを設定するには、インスタンスの下に rgw_override_bucket_index_max_shards を追加します。
  3. Ceph Object Gateway を再起動します。

    $ sudo service radosgw restart id=rgw.hostname

    hostname を、Ceph Object Gateway が実行されているノードの短縮ホスト名に置き換えてください。

3.4.3. マルチサイト設定でのバケットインデックスシャード化の設定

マルチサイト設定では、各ゾーンには、フェイルオーバーを管理するためのさまざまな index_pool 設定を指定できます。1 つのゾーングループのゾーンに一貫性のあるシャード数を設定するには、そのゾーングループの設定に bucket_index_max_shards を設定します。パラメーターを以下のように設定します。

  • バケットインデックスシャード化を無効にする場合は 0。これがデフォルト値になります。
  • 0 より大きい値を有効にすると、バケットシャード化が有効になり、シャードの最大数が設定されます。
注記

インデックスプール(各ゾーンについて)を SSD ベースの OSD の CRUSH ルールセットにマッピングすると、バケットインデックスのパフォーマンスにも役立つ場合があります。

手順

  1. 推奨されるシャード数を計算します。これを行うには、以下の式を使用します。

    number of objects expected in a bucket / 100,000

    シャードの最大数は 65521 です。

  2. ゾーングループ設定を zonegroup.json ファイルに展開します。

    $ radosgw-admin zonegroup get > zonegroup.json
  3. zonegroup.json ファイルで、名前付きゾーンごとに bucket_index_max_shards 設定を設定します。

    bucket_index_max_shards = value

    value を、直前の手順で計算したシャードの推奨数に置き換えます。以下に例を示します。

    bucket_index_max_shards = 10
  4. ゾーングループをリセットします。

    $ radosgw-admin zonegroup set < zonegroup.json
  5. 期間を更新します。

    $ radosgw-admin period update --commit

3.4.4. 動的バケットインデックスのリシャード化

動的バケットの再シャード化のプロセスは、すべての Ceph Object Gateway バケットを定期的にチェックし、再シャード化を必要とするバケットを検出します。バケットが rgw_max_objs_per_shard パラメーターで指定された値よりも大きい場合、Ceph Object Gateway はバックグラウンドでバケットを動的に再シャードします。rgw_max_objs_per_shard のデフォルト値は、シャードごとに 100k オブジェクトです。

重要

現時点で、Red Hat はマルチサイト設定での動的バケットの再シャード化をサポートしていません。このような設定でシャードバケットのインデックスを再作成するには、「マルチサイトを使用した手動によるバケットのリシャード化 」を参照してください。

手順

  • 動的バケットインデックスの再シャード化を有効にするには、以下を実行します。

    1. Ceph 設定ファイルの rgw_dynamic_resharding 設定を true (デフォルト値) に設定します。
    2. 任意です。必要に応じて、Ceph 設定ファイルの以下のパラメーターを変更します。

      • rgw_reshard_num_logs: 再シャードログのシャードの数。デフォルト値は 16 です。
      • rgw_reshard_bucket_lock_duration: リシャード中にバケットのロックの期間。デフォルト値は 120 秒です。
      • rgw_dynamic_resharding: 動的リシャードを有効または無効にします。デフォルト値は true です。
      • rgw_max_objs_per_shard: シャードごとのオブジェクトの最大数。デフォルト値は、シャードごとに 100000 オブジェクトです。
      • rgw_reshard_thread_interval: 再シャード処理のラウンド間の最大時間。デフォルト値は 600 秒です。
  • バケットを再シャード化キューに追加するには、以下を実行します。

    radosgw-admin reshard add --bucket BUCKET_NAME --num-shards NUMBER

    以下を置き換えます。

    • BUCKET_NAME は、再シャード化するバケットの名前に置き換えます。
    • NUMBER (新しいシャードの数)

    たとえば、以下のようになります。

    $ radosgw-admin reshard add --bucket data --num-shards 10

  • 再シャード化キューを一覧表示するには、以下を実行します。

    $ radosgw-admin reshard list
  • バケットの再シャード化のステータスを確認するには、以下を実行します。

    radosgw-admin reshard status --bucket BUCKET_NAME

    以下を置き換えます。

    • BUCKET_NAME を、再シャード化するバケットの名前に置き換えます。

    たとえば、以下のようになります。

    $ radosgw-admin reshard status --bucket data

    注記

    radosgw-admin reshard status コマンドは、以下のステータス識別子のいずれかを表示します。

    • not-resharding
    • in-progress
    • done
  • 再シャード化キューのエントリーをすぐに処理するには、以下を実行します。

    $ radosgw-admin reshard process
  • 保留中のバケットの再シャード化をキャンセルするには、以下を実行します。

    radosgw-admin reshard cancel --bucket BUCKET_NAME

    以下を置き換えます。

    • BUCKET_NAME を、保留中のバケットの名前に置き換えます。

    たとえば、以下のようになります。

    $ radosgw-admin reshard cancel --bucket data

    重要

    保留中 の再シャード操作のみをキャンセルできます。継続中 のリシャード操作をキャンセルしないでください。

  • Red Hat Ceph Storage 3.1 以前のバージョンを使用している場合、「再シャード化後の古いインスタンスのクリーニング」で説明されているように、古いバケットエントリーを削除します

3.4.5. Manual Bucket Index Resharding

バケットのサイズが初期設定に対して最適化されている場合は、radosgw-admin bucket reshard コマンドを使用してバケットインデックスプールを再シャードします。上記のコマンドでは、以下のようになります。

  • 指定されたバケットのバケットインデックスオブジェクトの新規セットを作成します。
  • これらのバケットインデックスオブジェクト間でオブジェクトエントリーを分散します。
  • 新規バケットインスタンスを作成します。
  • 新規バケットインスタンスをバケットとリンクし、すべての新規インデックス操作が新規バケットインデックスを通過するようにします。
  • 古いバケット ID と新しいバケット ID をコマンドの出力に出力します。

手順

  1. 元のバケットインデックスをバックアップします。

    radosgw-admin bi list --bucket=BUCKET > BUCKET.list.backup

    以下を置き換えます。

    • 再シャード化するバケットの名前を含む BUCKET

    たとえば、data という名前のバケットの場合は、以下を入力します。

    $ radosgw-admin bi list --bucket=data > data.list.backup
  2. バケットインデックスを再度シャード化します。

    radosgw-admin bucket reshard --bucket=BUCKET --num-shards=NUMBER

    以下を置き換えます。

    • 再シャード化するバケットの名前を含む BUCKET
    • NUMBER (新しいシャードの数)

    たとえば、data という名前のバケットと、必要なシャード数が 100 の場合は、次のコマンドを実行します。

    $ radosgw-admin bucket reshard --bucket=data --num-shards=100
  3. Red Hat Ceph Storage 3.1 以前のバージョンを使用している場合、「再シャード化後の古いインスタンスのクリーニング」で説明されているように、古いバケットエントリーを削除します

3.4.6. 再シャード化後の古いインスタンスのクリーニング

Red Hat Ceph Storage 3.1 以前のバージョンでは、再シャード化プロセスでは、バケットエントリーの古いインスタンスが自動的にクリーンアップされません。これらの古いインスタンスは、手動でクリーンアップされていない場合には、クラスターのパフォーマンスに影響を与える可能性があります。

重要

この手順は、マルチサイトクラスターに含まれていない単純な設定でのみ使用します。

前提条件

  • Ceph Object Gateway がインストールされている。

手順

  1. 古いインスタンスを一覧表示します。

    $ radosgw-admin reshard stale-instances list
  2. 古いインスタンスをクリーンアップします。

    $ radosgw-admin reshard stale-instances rm

3.5. 圧縮の有効化

Ceph Object Gateway は、Ceph の圧縮プラグインのいずれかを使用してアップロードしたオブジェクトのサーバー側の圧縮をサポートします。これには、以下が含まれます。

  • zlib: サポート対象。
  • snappy: テクノロジープレビュー。
  • zstd: テクノロジープレビュー。
注記

圧縮プラグイン snappy および zstd はテクノロジープレビュー機能であり、Red Hat が品質保証テストを完了していないため、完全にはサポートされていません。

設定

ゾーンの配置ターゲットで圧縮を有効にするには、--compression=<type> オプションを radosgw-admin zone placement modify コマンドに指定します。圧縮 type は、新しいオブジェクトデータの書き込み時に使用する圧縮プラグインの名前を指します。

圧縮された各オブジェクトは圧縮タイプを保存します。設定を変更しても、既存の圧縮オブジェクトを圧縮する機能も、Ceph Object Gateway で既存オブジェクトを圧縮させることはありません。

この圧縮設定は、この配置ターゲットを使用してバケットにアップロードされたすべての新規オブジェクトに適用されます。

ゾーンの配置ターゲットで圧縮を無効にするには、--compression=<type> オプションを radosgw-admin zone placement modify コマンドに指定して、空の文字列または none を指定します。

以下に例を示します。

$ radosgw-admin zone placement modify --rgw-zone=default --placement-id=default-placement --compression=zlib
{
...
    "placement_pools": [
        {
            "key": "default-placement",
            "val": {
                "index_pool": "default.rgw.buckets.index",
                "data_pool": "default.rgw.buckets.data",
                "data_extra_pool": "default.rgw.buckets.non-ec",
                "index_type": 0,
                "compression": "zlib"
            }
        }
    ],
...
}

圧縮の有効化または無効化後に、Ceph Object Gateway インスタンスを再起動して、変更を有効にします。

注記

Ceph Object Gateway は デフォルト ゾーンとプールのセットを作成します。実稼働デプロイメントの場合は、『実稼働用Ceph Object Gateway』 の「レルムの作成 」セクションを参照してください。Multisite も参照してください。

統計

既存のコマンドおよび API は、圧縮されていないデータに基づいてオブジェクトおよびバケットサイズを引き続き報告しますが、radosgw-admin bucket stats コマンドには指定されたバケットの圧縮統計が含まれます。

$ radosgw-admin bucket stats --bucket=<name>
{
...
    "usage": {
        "rgw.main": {
            "size": 1075028,
            "size_actual": 1331200,
            "size_utilized": 592035,
            "size_kb": 1050,
            "size_kb_actual": 1300,
            "size_kb_utilized": 579,
            "num_objects": 104
        }
    },
...
}

size_utilized フィールドおよび size_kb_utilized フィールドは、それぞれ圧縮データの合計サイズをバイト単位で表します。

3.6. ユーザー管理

Ceph Object Storage ユーザー管理とは、Ceph Object Storage サービスのクライアントアプリケーションであるユーザーを指します。Ceph Object Gateway を Ceph Storage クラスターのクライアントアプリケーションとしてではなく、このユーザーも使用します。クライアントアプリケーションが Ceph Object Gateway サービスと対話できるように、ユーザー、アクセスキー、およびシークレットを作成する必要があります。

ユーザータイプは 2 つあります。

  • User: 「user」という用語は、S3 インターフェースのユーザーを反映しています。
  • Subuser: 「subuser」という用語は、Swift インターフェースのユーザーを反映しています。サブユーザーがユーザーに関連付けられます。

ユーザーとサブユーザーの作成、変更、表示、一時停止、および削除が可能です。

重要

マルチサイトデプロイメントでユーザーを管理する場合は、常にマスターゾーングループのマスターゾーン内の Ceph Object Gateway ノードで radosgw-admin コマンドを実行して、ユーザーがマルチサイトクラスター全体で同期するようにします。セカンダリーゾーンまたはセカンダリーゾーングループから、マルチサイトクラスターでユーザーを作成、変更、または削除しないでください。このドキュメントでは、マスターゾーングループのマスターゾーンにあるホストのコマンドライン規則として [root@master-zone]# を使用しています。

ユーザーおよびサブユーザー ID を作成する他に、ユーザーに表示名およびメールアドレスを追加できます。キーおよびシークレットを指定したり、キーとシークレットを自動的に生成したりできます。キーを生成または指定する際には、ユーザー ID が S3 キータイプに対応していることに注意してください。サブユーザー ID は swift 鍵のタイプに対応します。Swift キーには、アクセスレベルの readwritereadwrite、および full もあります。

ユーザー管理コマンドライン構文は、通常、パターン user <command> <user-id> に従います。ここで、<user-id> は、--uid= オプションの後にユーザーID (S3) が続くか、--subuser= オプションの後にユーザー名 (Swift) が続きます。以下に例を示します。

[root@master-zone]# radosgw-admin user <create|modify|info|rm|suspend|enable|check|stats> <--uid={id}|--subuser={name}> [other-options]

実行するコマンドによっては、追加のオプションが必要になる場合があります。

3.6.1. マルチテナンシー

Red Hat Ceph Storage 2 以降では、Ceph Object Gateway は S3 および Swift API の両方のマルチテナンシーをサポートします。 マルチテナンシーは、複数のテナントが「test」、「main」などの共通のバケット名を使用する場合に namespace の競合を防ぎます。

テナント下の各ユーザーおよびバケット。後方互換性を確保するため、空の名前の「レガシー」テナントが追加されます。テナントを具体的に指定せずにバケットを参照するたびに、Swift API は「レガシー」テナントを想定します。既存ユーザーはレガシーテナントでも保存されるため、これらのユーザーは以前のリリースと同じ方法でバケットとオブジェクトにアクセスします。

テナントには、それらに対する操作がありません。ユーザーが管理されると、必要に応じて表示や非表示が表示されます。明示的なテナントを持つユーザーを作成、変更、および削除するには、追加のオプション --tenant を指定するか、radosgw-admin コマンドのパラメーターで構文 "<tenant>$<user>" を使用します。

S3 用のユーザー testx$tester を作成するには、以下を実行します。

[root@master-zone]# radosgw-admin --tenant testx --uid tester \
                    --display-name "Test User" --access_key TESTER \
                    --secret test123 user create

Swift のユーザー testx$tester を作成するには、以下のいずれかを実行します。

[root@master-zone]# radosgw-admin --tenant testx --uid tester \
                    --display-name "Test User" --subuser tester:swift \
                    --key-type swift --access full subuser create

[root@master-zone]# radosgw-admin key create --subuser 'testx$tester:swift' \
                    --key-type swift --secret test123
注記

明示的なテナントを持つサブユーザーは、シェルで引用符で囲む必要があります。

3.6.2. ユーザーの作成

user create コマンドを使用して S3-interface ユーザーを作成します。ユーザー ID と表示名を指定する必要があります。メールアドレスを指定することもできます。key または secret を指定しないと、radosgw-admin によって自動的に生成されます。ただし、生成されたキー/シークレットのペアを使用しない場合は、キーまたはシークレットを指定することもできます。

[root@master-zone]# radosgw-admin user create --uid=<id> \
[--key-type=<type>] [--gen-access-key|--access-key=<key>]\
[--gen-secret | --secret=<key>] \
[--email=<email>] --display-name=<name>

以下に例を示します。

[root@master-zone]# radosgw-admin user create --uid=janedoe --display-name="Jane Doe" --email=jane@example.com
{ "user_id": "janedoe",
  "display_name": "Jane Doe",
  "email": "jane@example.com",
  "suspended": 0,
  "max_buckets": 1000,
  "auid": 0,
  "subusers": [],
  "keys": [
        { "user": "janedoe",
          "access_key": "11BS02LGFB6AL6H1ADMW",
          "secret_key": "vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY"}],
  "swift_keys": [],
  "caps": [],
  "op_mask": "read, write, delete",
  "default_placement": "",
  "placement_tags": [],
  "bucket_quota": { "enabled": false,
      "max_size_kb": -1,
      "max_objects": -1},
  "user_quota": { "enabled": false,
      "max_size_kb": -1,
      "max_objects": -1},
  "temp_url_keys": []}
重要

キーの出力を確認します。radosgw-admin が JSON エスケープ (\) 文字を生成することがあり、一部のクライアントは JSON エスケープ文字の処理方法を知りません。対処法には、JSON エスケープ文字 (\) の削除、文字列の引用符でのカプセル化、キーの再生成、JSON エスケープ文字が含まれていないことの確認、またはキーとシークレットの手動指定が含まれます。

3.6.3. サブユーザーの作成

サブユーザー (Swiftインターフェース) を作成するには、ユーザーID (--uid={username})、サブユーザー ID、およびサブユーザーのアクセスレベルを指定する必要があります。key または secret を指定しないと、radosgw-admin によって自動的に生成されます。ただし、生成されたキー/シークレットのペアを使用しない場合は、キーまたはシークレットを指定することもできます。

注記

アクセス制御ポリシーも含まれるため、fullreadwrite ではありません。

[root@master-zone]# radosgw-admin subuser create --uid={uid} --subuser={uid} --access=[ read | write | readwrite | full ]

以下に例を示します。

[root@master-zone]# radosgw-admin subuser create --uid=janedoe --subuser=janedoe:swift --access=full
{ "user_id": "janedoe",
  "display_name": "Jane Doe",
  "email": "jane@example.com",
  "suspended": 0,
  "max_buckets": 1000,
  "auid": 0,
  "subusers": [
        { "id": "janedoe:swift",
          "permissions": "full-control"}],
  "keys": [
        { "user": "janedoe",
          "access_key": "11BS02LGFB6AL6H1ADMW",
          "secret_key": "vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY"}],
  "swift_keys": [],
  "caps": [],
  "op_mask": "read, write, delete",
  "default_placement": "",
  "placement_tags": [],
  "bucket_quota": { "enabled": false,
      "max_size_kb": -1,
      "max_objects": -1},
  "user_quota": { "enabled": false,
      "max_size_kb": -1,
      "max_objects": -1},
  "temp_url_keys": []}

3.6.4. ユーザー情報の取得

ユーザーに関する情報を取得するには、user info および user ID(--uid={username})を指定する必要があります。

# radosgw-admin user info --uid=janedoe

3.6.5. ユーザー情報の変更

ユーザーに関する情報を変更するには、ユーザーID (--uid={username}) と変更する属性を指定する必要があります。通常の変更は、キーおよびシークレット、メールアドレス、表示名およびアクセスレベルです。以下に例を示します。

[root@master-zone]# radosgw-admin user modify --uid=janedoe / --display-name="Jane E. Doe"

サブユーザーの値を変更するには、subuser modify とサブユーザー ID を指定します。以下に例を示します。

[root@master-zone]# radosgw-admin subuser modify --subuser=janedoe:swift / --access=full

3.6.6. ユーザーの有効化および一時停止

ユーザーを作成すると、ユーザーはデフォルトで有効になります。ただし、ユーザー権限を一時停止し、後で再度有効にすることができます。ユーザーを一時停止するには、user suspend とユーザー ID を指定します。

[root@master-zone]# radosgw-admin user suspend --uid=johndoe

一時停止ユーザーを再度有効にするには、user enable とユーザー ID を指定します。

[root@master-zone]# radosgw-admin user enable --uid=johndoe
注記

ユーザーを無効にすると、サブユーザーが無効になります。

3.6.7. ユーザーの削除

ユーザーを削除すると、ユーザーとサブユーザーがシステムから削除されます。ただし、必要に応じてサブユーザーだけを削除できます。ユーザー (およびサブユーザー) を削除するには、user rm とユーザー ID を指定します。

[root@master-zone]# radosgw-admin user rm --uid=<uid> [--purge-keys] [--purge-data]

以下に例を示します。

[root@master-zone]# radosgw-admin user rm --uid=johndoe --purge-data

サブユーザーのみを削除するには、subuser rm およびサブユーザー名を指定します。

[root@master-zone]# radosgw-admin subuser rm --subuser=johndoe:swift --purge-keys

オプションには以下が含まれます。

  • データのパージ: --purge-data オプションは、UID に関連付けられたすべてのデータをパージします。
  • Purge Keys: --purge-keys オプションは、UID に関連付けられたすべてのキーをパージします。

3.6.8. サブユーザーの削除

サブユーザーを削除すると、Swift インターフェースへのアクセスが削除されます。ユーザーはシステムに残ります。Ceph Object Gateway: サブユーザーを削除するには、subuser rm およびサブユーザー ID を指定します。

[root@master-zone]# radosgw-admin subuser rm --subuser=johndoe:test

オプションには以下が含まれます。

  • Purge Keys: --purge-keys オプションは、UID に関連付けられたすべてのキーをパージします。

3.6.9. ユーザーの名前変更

ユーザーの名前を変更するには、radosgw-admin user rename コマンドを使用します。このコマンドにかかる時間は、ユーザーが持つバケットおよびオブジェクトの数によって異なります。この数字が大きい場合、Red Hat は、screen パッケージが提供する Screen ユーティリティーでコマンドを使用することを推奨します。

前提条件

  • 稼働中の Ceph クラスター
  • root または sudo アクセス
  • Installed Ceph Object Gateway

手順

  1. ユーザーの名前を変更します。

    radosgw-admin user rename --uid=current-user-name --new-uid=new-user-name

    たとえば、名前 user1user2 に変更するには、以下を実行します。

    # radosgw-admin user rename --uid=user1 --new-uid=user2
    
    {
        "user_id": "user2",
        "display_name": "user 2",
        "email": "",
        "suspended": 0,
        "max_buckets": 1000,
        "auid": 0,
        "subusers": [],
        "keys": [
            {
                "user": "user2",
                "access_key": "59EKHI6AI9F8WOW8JQZJ",
                "secret_key": "XH0uY3rKCUcuL73X0ftjXbZqUbk0cavD11rD8MsA"
            }
        ],
        "swift_keys": [],
        "caps": [],
        "op_mask": "read, write, delete",
        "default_placement": "",
        "placement_tags": [],
        "bucket_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "user_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "temp_url_keys": [],
        "type": "rgw"
    }

    ユーザーがテナント内にある場合は、tenant$user-name 形式を使用します。

    radosgw-admin user rename --uid=tenant$current-user-name --new-uid=tenant$new-user-name

    たとえば、test テナント内の user1 の名前を user2 に変更するには、以下を実行します。

    # radosgw-admin user rename --uid=test$user1 --new-uid=test$user2
    
    1000 objects processed in tvtester1. Next marker 80_tVtester1_99
    2000 objects processed in tvtester1. Next marker 64_tVtester1_44
    3000 objects processed in tvtester1. Next marker 48_tVtester1_28
    4000 objects processed in tvtester1. Next marker 2_tVtester1_74
    5000 objects processed in tvtester1. Next marker 14_tVtester1_53
    6000 objects processed in tvtester1. Next marker 87_tVtester1_61
    7000 objects processed in tvtester1. Next marker 6_tVtester1_57
    8000 objects processed in tvtester1. Next marker 52_tVtester1_91
    9000 objects processed in tvtester1. Next marker 34_tVtester1_74
    9900 objects processed in tvtester1. Next marker 9_tVtester1_95
    1000 objects processed in tvtester2. Next marker 82_tVtester2_93
    2000 objects processed in tvtester2. Next marker 64_tVtester2_9
    3000 objects processed in tvtester2. Next marker 48_tVtester2_22
    4000 objects processed in tvtester2. Next marker 32_tVtester2_42
    5000 objects processed in tvtester2. Next marker 16_tVtester2_36
    6000 objects processed in tvtester2. Next marker 89_tVtester2_46
    7000 objects processed in tvtester2. Next marker 70_tVtester2_78
    8000 objects processed in tvtester2. Next marker 51_tVtester2_41
    9000 objects processed in tvtester2. Next marker 33_tVtester2_32
    9900 objects processed in tvtester2. Next marker 9_tVtester2_83
    {
        "user_id": "test$user2",
        "display_name": "User 2",
        "email": "",
        "suspended": 0,
        "max_buckets": 1000,
        "auid": 0,
        "subusers": [],
        "keys": [
            {
                "user": "test$user2",
                "access_key": "user2",
                "secret_key": "123456789"
            }
        ],
        "swift_keys": [],
        "caps": [],
        "op_mask": "read, write, delete",
        "default_placement": "",
        "placement_tags": [],
        "bucket_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "user_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "temp_url_keys": [],
        "type": "rgw"
    }
  2. ユーザーの名前が変更されたことを確認します。

    radosgw-admin user info --uid=new-user-name

    以下に例を示します。

    # radosgw-admin user info --uid=user2

    ユーザーがテナント内にある場合は、tenant$user-name 形式を使用します。

    radosgw-admin user info --uid=tenant$new-user-name
    # radosgw-admin user info --uid=test$user2

関連情報

  • man ページの screen(1)

3.6.10. キーの作成

ユーザーのキーを作成するには、key create を指定する必要があります。ユーザーには、ユーザー ID と s3 キータイプを指定します。サブユーザーのキーを作成するには、サブユーザー ID と swift キータイプを指定する必要があります。以下に例を示します。

[root@master-zone]# radosgw-admin key create --subuser=johndoe:swift --key-type=swift --gen-secret
{ "user_id": "johndoe",
  "rados_uid": 0,
  "display_name": "John Doe",
  "email": "john@example.com",
  "suspended": 0,
  "subusers": [
     { "id": "johndoe:swift",
       "permissions": "full-control"}],
  "keys": [
    { "user": "johndoe",
      "access_key": "QFAMEDSJP5DEKJO0DDXY",
      "secret_key": "iaSFLDVvDdQt6lkNzHyW4fPLZugBAI1g17LO0+87"}],
  "swift_keys": [
    { "user": "johndoe:swift",
      "secret_key": "E9T2rUZNu2gxUjcwUBO8n\/Ev4KX6\/GprEuH4qhu1"}]}

3.6.11. アクセスキーの追加および削除

ユーザーとサブユーザーには、S3 および Swift インターフェースを使用するためのアクセスキーが必要です。ユーザーまたはサブユーザーを作成し、アクセスキーおよびシークレットを指定しない場合、キーおよびシークレットは自動的に生成されます。キーを作成し、アクセスキーまたはシークレットのいずれかを指定または生成することができます。アクセスキーおよびシークレットを削除することもできます。オプションには以下が含まれます。

  • --secret=<key> は、秘密鍵を指定します (例: 手動で生成)。
  • --geen-access-key は、ランダムなアクセスキーを生成します (デフォルトでは S3 ユーザー用)。
  • --geen-secret は、ランダムな秘密鍵を生成します。
  • --key-type=<type> は、キータイプを指定します。オプション: swift、s3

キーを追加するには、ユーザーを指定します。

[root@master-zone]# radosgw-admin key create --uid=johndoe --key-type=s3 --gen-access-key --gen-secret

キーとシークレットを指定することもできます。

アクセスキーを削除するには、ユーザーとキーを指定する必要があります。

  1. 特定ユーザーのアクセスキーを検索します。

    [root@master-zone]# radosgw-admin user info --uid=<testid>

    アクセスキーは、出力の "access_key" 値になります。以下に例を示します。

    $ radosgw-admin user info --uid=johndoe
    {
        "user_id": "johndoe",
        ...
        "keys": [
            {
                "user": "johndoe",
                "access_key": "0555b35654ad1656d804",
                "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
            }
        ],
        ...
    }
  2. 前の手順からユーザー ID とアクセスキーを指定して、アクセスキーを削除します。

    [root@master-zone]# radosgw-admin key rm --uid=<user_id> --access-key <access_key>

    以下に例を示します。

    [root@master-zone]# radosgw-admin key rm --uid=johndoe --access-key 0555b35654ad1656d804

3.6.12. 管理機能の追加と削除

Ceph Storage Cluster は、ユーザーが REST API 経由で管理機能を実行できるようにする管理 API を提供します。デフォルトでは、ユーザー DO はこの API にアクセスできません。ユーザーが管理機能を実行できるようにするには、ユーザーに管理機能を提供します。

ユーザーに管理機能を追加するには、以下を実行します。

[root@master-zone]# radosgw-admin caps add --uid={uid} --caps={caps}

ユーザー、バケット、メタデータ、および使用(ユーティリティー)に読み取り、書き込み、またはすべての機能を追加できます。以下に例を示します。

--caps="[users|buckets|metadata|usage|zone]=[*|read|write|read, write]"

以下に例を示します。

[root@master-zone]# radosgw-admin caps add --uid=johndoe --caps="users=*"

ユーザーから管理機能を削除するには、以下を実行します。

[root@master-zone]# radosgw-admin caps rm --uid=johndoe --caps={caps}

3.7. クォータ管理

Ceph Object Gateway では、ユーザーが所有するユーザーおよびバケットにクォータを設定できます。クォータには、バケットのオブジェクトの最大数と、メガバイト単位のストレージの最大サイズが含まれます。

  • Bucket: --bucket オプションでは、ユーザーが所有するバケットのクォータを指定できます。
  • Maximum Objects: --max-objects 設定では、オブジェクトの最大数を指定できます。負の値を設定すると、この設定が無効になります。
  • Maximum Size: --max-size オプションでは、バイトの最大数のクォータを指定できます。負の値を設定すると、この設定が無効になります。
  • Quota Scope: --quota-scope オプションは、クォータのスコープを設定します。オプションは bucketuser です。バケットクォータは、ユーザーが所有するバケットに適用されます。ユーザークォータはユーザーに適用されます。
重要

多数のオブジェクトを持つバケットは、パフォーマンスに深刻な問題を引き起こす可能性があります。1 つのバケット内のオブジェクトの推奨最大数は 100,000 です。この数を増やすには、バケットインデックスのシャード化を設定します。詳しくは、「バケットシャードの設定」 を参照してください。

3.7.1. ユーザークォータの設定

クォータを有効にする前に、まずクォータパラメーターを設定する必要があります。以下に例を示します。

[root@master-zone]# radosgw-admin quota set --quota-scope=user --uid=<uid> [--max-objects=<num objects>] [--max-size=<max size>]

以下に例を示します。

radosgw-admin quota set --quota-scope=user --uid=johndoe --max-objects=1024 --max-size=1024

num オブジェクトの負の値および / または最大サイズは、特定のクォータ属性チェックが無効になっていることを意味します。

3.7.2. ユーザークォータの有効化と無効化

ユーザークォータを設定したら、これを有効にできます。以下に例を示します。

[root@master-zone]# radosgw-admin quota enable --quota-scope=user --uid=<uid>

有効なユーザークォータを無効にすることができます。以下に例を示します。

[root@master-zone]# radosgw-admin quota disable --quota-scope=user --uid=<uid>

3.7.3. バケットクォータの設定

バケットクォータは、指定された uid が所有するバケットに適用されます。ユーザーからは独立しています。

[root@master-zone]# radosgw-admin quota set --uid=<uid> --quota-scope=bucket [--max-objects=<num objects>] [--max-size=<max size]

num オブジェクトの負の値および / または最大サイズは、特定のクォータ属性チェックが無効になっていることを意味します。

3.7.4. バケットクォータの有効化および無効化

バケットクォータを設定したら、これを有効にできます。以下に例を示します。

[root@master-zone]# radosgw-admin quota enable --quota-scope=bucket --uid=<uid>

有効なバケットクォータを無効にするには、以下を実行します。

[root@master-zone]# radosgw-admin quota disable --quota-scope=bucket --uid=<uid>

3.7.5. クォータ設定の取得

ユーザー情報 API を使用して各ユーザーのクォータ設定にアクセスできます。CLI インターフェースを使用してユーザークォータの設定情報を読み取るには、以下を実行します。

# radosgw-admin user info --uid=<uid>

3.7.6. クォータ統計の更新

クォータ統計は非同期で更新されます。すべてのユーザーおよびすべてのバケットのクォータ統計を手動で更新して、最新のクォータ統計を取得できます。

[root@master-zone]# radosgw-admin user stats --uid=<uid> --sync-stats

3.7.7. ユーザークォータ使用統計値の取得

ユーザーが消費したクォータの量を表示するには、以下を実行します。

# radosgw-admin user stats --uid=<uid>
注記

最新のデータを受け取るには、--sync-stats オプションを指定して radosgw-admin user stats を実行する必要があります。

3.7.8. クォータキャッシュ

クォータの統計は各 Ceph Gateway インスタンスについてキャッシュされます。インスタンスが複数ある場合には、各インスタンスはクォータのビューが異なるため、キャッシュはクォータを明示的に強制できます。これを制御するオプションは、rgw bucket quota ttlrgw user quota bucket sync interval、および rgw user quota sync interval です。これらの値が大きいほどクォータ操作はより効率的になりますが、同期されていない複数のインスタンスが非同期になります。これらの値が小さいほど、perfect を適用すると複数のインスタンスが実行されます。3 つすべてが 0 の場合、クォータキャッシュは事実上、クォータキャッシュは事実上は無効になり、複数のインスタンスにはクォータの強制適用が行われます。これらのオプションの詳細については、4章設定リファレンス を参照してください。

3.7.9. グローバルクォータの読み取りおよび書き込み

zonegroup マップでクォータ設定を読み取りおよび書き込みできます。zonegroup マップを取得するには、次のコマンドを実行します。

[root@master-zone]# radosgw-admin global quota get

グローバルクォータ設定は、quota setquota enable、および quota disable コマンドに対応する global quota で操作できます。次に例を示します。

[root@master-zone]# radosgw-admin global quota set --quota-scope bucket --max-objects 1024
[root@master-zone]# radosgw-admin global quota enable --quota-scope bucket
注記

レルムと期間が存在するマルチサイト構成では、グローバルクォータへの変更は、period update --commit を使用してコミットする必要があります。期間がない場合は、変更を有効にするために Ceph Object Gateway を再起動する必要があります。

3.8. 用途

Ceph Object Gateway は、各ユーザーの使用状況をログに記録します。日付範囲内のユーザー使用状況も追跡できます。

オプションには以下が含まれます。

  • 開始日: --start-date オプションを使用すると、特定の開始日から使用統計をフィルタリングできます (形式: yyyy-mm-dd[HH:MM:SS])。
  • 終了日: --end-date オプションを使用すると、特定の日付までの使用をフィルタリングできます (形式: yyyy-mm-dd[HH:MM:SS])。
  • ログエントリー: --show-log-entries オプションを使用すると、ログエントリーを使用統計に含めるかどうかを指定できます (オプション: true | false)。
注記

分と秒で時間を指定できますが、1 時間の解決で保存されます。

3.8.1. 使用方法の表示

使用状況の統計を表示するには、usage show を指定します。ユーザーの使用状況を表示するには、ユーザー ID を指定する必要があります。開始日、終了日、ログエントリーを表示するかどうかを指定することもできます。

# radosgw-admin usage show \
                --uid=johndoe --start-date=2012-03-01 \
                --end-date=2012-04-01

ユーザー ID を省略することで、すべてのユーザーの使用情報の概要を表示することもできます。

# radosgw-admin usage show --show-log-entries=false

3.8.2. トリムでの使用

大きな使用のために、使用ログはストレージ領域を占めるように開始できます。全ユーザーおよび特定のユーザーの使用ログは、トリミングすることができます。トリミング操作の日付範囲を指定することもできます。

[root@master-zone]# radosgw-admin usage trim --start-date=2010-01-01 \
                    --end-date=2010-12-31

[root@master-zone]# radosgw-admin usage trim --uid=johndoe
[root@master-zone]# radosgw-admin usage trim --uid=johndoe --end-date=2013-12-31

3.8.3. Orphan オブジェクトの検索

通常、正常なストレージクラスターでは、オブジェクトのリークは持たせないはずですが、状況によっては、オブジェクトに漏えいする可能性があります。たとえば、RADOS Gateway が操作の途中でダウンしている場合、RADOS オブジェクトが孤立する可能性がありました。また、不明なバグにより、これらの孤立したオブジェクトが発生する場合があります。radosgw-admin コマンドは、これらの孤立したオブジェクトを検索し、クリーンアップするツールを提供します。--pool オプションを使用すると、リーク RADOS オブジェクトについてスキャンするプールを指定できます。--num-shards オプションを使用すると、一時的なスキャンデータを保持するために使用するシャードの数を指定できます。

  1. 新しいログプールを作成します。

    # rados mkpool .log

  2. 孤立したオブジェクトを検索します。

    構文

    # radosgw-admin orphans find --pool=<data_pool> --job-id=<job_name> [--num-shards=<num_shards>] [--orphan-stale-secs=<seconds>]

    # radosgw-admin orphans find --pool=.rgw.buckets --job-id=abc123

  3. 検索データのクリーンアップ

    構文

    # radosgw-admin orphans finish --job-id=<job_name>

    # radosgw-admin orphans finish --job-id=abc123

3.9. バケット管理

ストレージ管理者は、Ceph Object Gateway を使用する場合、それらをユーザー間で移動し、名前を変更してバケットを管理することができます。

3.9.1. バケットの移動

radosgw-admin bucket ユーティリティーは、ユーザー間でバケットを移行する機能を提供します。これを実行するには、バケットを新規ユーザーにリンクし、バケットの所有権を新規ユーザーに変更します。

バケットを移動できます。

3.9.1.1. 前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • Ceph Object Gateway がインストールされている。
  • バケット
  • さまざまなテナント化されたユーザーおよびテナントのないユーザー

3.9.1.2. テナントを持たないユーザー間でのバケットの移動

radosgw-admin bucket chown コマンドは、バケットとそれに含まれるすべてのオブジェクトの所有権をあるユーザーから別のユーザーに変更する機能を提供します。これを実行するには、現在のユーザーからバケットのリンクを解除し、これを新規ユーザーにリンクし、バケットの所有権を新規ユーザーに変更します。

手順

  1. バケットを新規ユーザーにリンクします。

    radosgw-admin bucket link --uid=user --bucket=bucket

    以下を置き換えます。

    • user を、バケットをリンクするユーザーのユーザー名に
    • bucket を、名前を持つバケットに

    たとえば、data バケットを user2 という名前のユーザーにリンクするには、以下を実行します。

    # radosgw-admin bucket link --uid=user2 --bucket=data
  2. バケットが user2 に正常にリンクされていることを確認します。

    # radosgw-admin bucket list --uid=user2
    [
        "data"
    ]
  3. バケットの所有権を新規ユーザーに変更します。

    radosgw-admin bucket chown --uid=user --bucket=bucket

    以下を置き換えます。

    • user を、バケットの所有権を変更するユーザーのユーザー名に
    • bucket を、名前を持つバケットに

    たとえば、データ バケットの所有権を user2 に変更するには、以下を実行します。

    # radosgw-admin bucket chown --uid=user2 --bucket=data
  4. 次のコマンドの出力で owner 行を確認して、data バケットの所有権が正常に変更されたことを確認します。

    # radosgw-admin bucket list --bucket=data

3.9.1.3. テナントされたユーザー間のバケットの移動

テナント化したユーザー間でバケットを移動できます。

手順

  1. バケットを新規ユーザーにリンクします。

    radosgw-admin bucket link --bucket=current-tenant/bucket --uid=new-tenant$user

    置き換え:

    • current-tenant を、バケットのテナントの名前に
    • bucket リンクするバケットの名前に
    • new-tenant を、新規ユーザーがあるテナントの名前に置き換えます。
    • user を、新しいユーザーのユーザー名に

    たとえば、data バケットを、test テナントから、test2 テナントの user2 という名前のユーザーにリンクします。

    # radosgw-admin bucket link --bucket=test/data --uid=test2$user2
  2. バケットが user2 に正常にリンクされていることを確認します。

    # radosgw-admin bucket list --uid=test$user2
    [
        "data"
    ]
  3. バケットの所有権を新規ユーザーに変更します。

    radosgw-admin bucket chown --bucket=new-tenant/bucket --uid=new-tenant$user

    以下を置き換えます。

    • bucket リンクするバケットの名前に
    • new-tenant を、新規ユーザーがあるテナントの名前に置き換えます。
    • user を、新しいユーザーのユーザー名に

    たとえば、data バケットの所有権を test2 テナント内の user2 に変更するには、次のようにします。

    # radosgw-admin bucket chown --bucket='test2/data' --uid='test$tuser2'
  4. 次のコマンドの出力で owner 行を確認して、data バケットの所有権が正常に変更されたことを確認します。

    # radosgw-admin bucket list --bucket=test2/data

3.9.1.4. バケットをテナントを持たないユーザーからテナント化したユーザーに移動する

テナントを持たないユーザーからテナント指定されたユーザーにバケットを移行できます。

手順

  1. 任意です。まだ複数のテナントがない場合は、rgw_keystone_implicit_tenants を有効にして、外部テナントから Ceph Object Gateway にアクセスすることでテナントを作成できます。

    Ceph 設定ファイル (デフォルトでは /etc/ceph/ceph.conf) を開き、編集します。rgw_keystone_implicit_tenants オプションを有効にします。

    rgw_keystone_implicit_tenants = true

    s3cmd コマンドまたは swift コマンドのいずれかを使用して、一時テナントから Ceph Object Gateway にアクセスします。

    # swift list

    または、s3cmd を使用します。

    # s3cmd ls

    外部テナントからの最初のアクセスは、同等の Ceph Object Gateway ユーザーを作成します。

  2. バケットをテナント化したユーザーに移動します。

    radosgw-admin bucket link --bucket=/bucket --uid='tenant$user'

    置き換え:

    • bucket を、名前を持つバケットに
    • tenant を、新規ユーザーがあるテナントの名前に
    • user を、新しいユーザーのユーザー名に

    たとえば、data バケットを test テナント内の tenanted-user に移動するには、以下を実行します。

    # radosgw-admin bucket link --bucket=/data --uid='test$tenanted-user'
  3. data バケットが tenanted-user に正常にリンクされていることを確認します。

    # radosgw-admin bucket list --uid='test$tenanted-user'
    [
        "data"
    ]
  4. バケットの所有権を新規ユーザーに変更します。

    radosgw-admin bucket chown --bucket='tenant/bucket name' --uid='tenant$user'

    置き換え:

    • bucket を、名前を持つバケットに
    • tenant を、新規ユーザーがあるテナントの名前に
    • user を、新しいユーザーのユーザー名に

    たとえば、data バケットの所有権を、test テナント内にある tenanted-user に変更するには、以下を実行します。

    # radosgw-admin bucket chown --bucket='test/data' --uid='test$tenanted-user'
  5. 次のコマンドの出力で owner 行を確認して、data バケットの所有権が正常に変更されたことを確認します。

    # radosgw-admin bucket list --bucket=test/data

3.9.2. バケットの名前変更

バケットの名前を変更できます。

前提条件

  • Red Hat Ceph Storage クラスターが実行中である。
  • Ceph Object Gateway がインストールされている。
  • バケット。

手順

  1. バケットを一覧表示します。

    radosgw-admin bucket list

    たとえば、出力からのバケットを書き留めておきます。

    # radosgw-admin bucket list
    [
        "34150b2e9174475db8e191c188e920f6/swcontainer",
        "s3bucket1",
        "34150b2e9174475db8e191c188e920f6/swimpfalse",
        "c278edd68cfb4705bb3e07837c7ad1a8/ec2container",
        "c278edd68cfb4705bb3e07837c7ad1a8/demoten1",
        "c278edd68cfb4705bb3e07837c7ad1a8/demo-ct",
        "c278edd68cfb4705bb3e07837c7ad1a8/demopostup",
        "34150b2e9174475db8e191c188e920f6/postimpfalse",
        "c278edd68cfb4705bb3e07837c7ad1a8/demoten2",
        "c278edd68cfb4705bb3e07837c7ad1a8/postupsw"
    ]
  2. バケットの名前を変更します。

    radosgw-admin bucket link --bucket=original-name --bucket-new-name=new-name --uid=user-ID

    たとえば、s3bucket1 バケットの名前を s3newb に変更するには、以下を実行します。

    # radosgw-admin bucket link --bucket=s3bucket1 --bucket-new-name=s3newb --uid=testuser

    バケットがテナント内にある場合は、テナントも指定します。

    radosgw-admin bucket link --bucket=tenant/original-name --bucket-new-name=new-name --uid=tenant$user-ID

    以下に例を示します。

    # radosgw-admin bucket link --bucket=test/s3bucket1 --bucket-new-name=s3newb --uid=test$testuser
  3. バケットの名前が変更されたことを確認します。

    radosgw-admin bucket list

    たとえば、s3newb という名前のバケットが存在するようになりました。

    # radosgw-admin bucket list
    [
        "34150b2e9174475db8e191c188e920f6/swcontainer",
        "34150b2e9174475db8e191c188e920f6/swimpfalse",
        "c278edd68cfb4705bb3e07837c7ad1a8/ec2container",
        "s3newb",
        "c278edd68cfb4705bb3e07837c7ad1a8/demoten1",
        "c278edd68cfb4705bb3e07837c7ad1a8/demo-ct",
        "c278edd68cfb4705bb3e07837c7ad1a8/demopostup",
        "34150b2e9174475db8e191c188e920f6/postimpfalse",
        "c278edd68cfb4705bb3e07837c7ad1a8/demoten2",
        "c278edd68cfb4705bb3e07837c7ad1a8/postupsw"
    ]

3.9.3. 関連情報

3.10. Ceph Object Gateway のガベージコレクションを最適化します。

新規データオブジェクトがストレージクラスターに書き込まれる際に、Ceph Object Gateway はこれらの新規オブジェクトのストレージをすぐに割り当てます。ストレージクラスターのデータオブジェクトを削除または上書きした後に、Ceph Object Gateway はバケットインデックスからこれらのオブジェクトを削除します。その後、Ceph Object Gateway は、オブジェクトをストレージクラスターに保存する際に使用した領域をパージします。削除されたオブジェクトデータをストレージクラスターからパージするプロセスは、Garbage Collection または GC と呼ばれます。

ガベッジコレクションの操作は通常バックグラウンドで実行されます。これらの操作は継続的に実行するように設定するか、低アクティビティーおよび軽量のワークロードの間隔でのみ実行することができます。デフォルトでは、Ceph Object Gateway は GC 操作を継続的に実行します。GC 操作は Ceph Object Gateway 操作の通常の部分であるため、ガベージコレクションの対象となる削除されたオブジェクトはほとんどの場合存在します。

3.10.1. ガベッジコレクションキューの表示

削除および上書きされたオブジェクトをストレージクラスターからパージする前に、radosgw-admin を使用して、ガベージコレクションを待機しているオブジェクトを表示します。

前提条件

  • Red Hat Ceph Storage クラスターが実行中である。
  • Ceph Object Gateway へのルートレベルのアクセス。

手順

  1. ガベッジコレクションを待機中のオブジェクトのキューを表示するには、以下を実行します。

    [root@rgw ~] radosgw-admin gc list

注記

有効期限が切れていないエントリを含む、キュー内のすべてのエントリを表示するには、--include-all オプションを使用します。

3.10.2. 削除負荷についてのガベージコレクションの調整

一部のワークロードでは、ガベッジコレクション(GC)アクティビティーの速度を一時的にまたは完全に引き起こす可能性があります。これは特に delete-heavy ワークロードで、多くのオブジェクトが短期間保存され、その後削除されます。これらのタイプのワークロードでは、他の操作との関連でガベージコレクション操作の優先度を高くすることを検討してください。Ceph Object Gateway Garbage Collection に関するその他の質問は、Red Hat サポートにお問い合わせください。

前提条件

  • Red Hat Ceph Storage クラスターが実行中である。
  • ストレージクラスター内のすべてのノードへの root レベルのアクセス。

手順

  1. /etc/ceph/ceph.conf を開いて編集します。
  2. rgw_gc_max_concurrent_io の値を 20 に設定し、rgw_gc_max_trim_chunk の値を 64 に設定します。

    rgw_gc_max_concurrent_io = 20
    rgw_gc_max_trim_chunk = 64
  3. ファイルを保存してから閉じます。
  4. Ceph Object Gateway を再起動して、変更された設定を有効にします。
  5. GC アクティビティー時にストレージクラスターを監視し、増加した値がパフォーマンスに悪影響を与えることがないことを確認します。
重要

実行中のクラスターの rgw_gc_max_objs オプションの値を変更しないでください。この値を変更するのは、RGW ノードをデプロイする前にのみ行う必要があります。

第4章 設定リファレンス

次の設定は、[client.rgw.<instance_name>] セクションの下の Ceph 構成ファイル (通常は ceph.conf) に追加できます。設定にはデフォルト値が含まれる場合があります。Ceph 設定ファイル内の各設定を指定しない場合、デフォルト値が自動的に設定されます。

[client.rgw.<instance_name>] セクションで設定された構成変数は、コマンドで instance_name が指定されていない rgw または radosgw-admin コマンドには適用されません。したがって、すべての Ceph Object Gateway インスタンスまたはすべての radosgw-admin コマンドに適用されることを意図した変数を [global] セクションまたは [client] セクションに配置して、instance_name 指定を回避できます。

4.1. 一般設定

名前説明タイプデフォルト

rgw_data

Ceph Object Gateway のデータファイルの場所を設定します。

文字列

/var/lib/ceph/radosgw/$cluster-$id

rgw_enable_apis

指定された API を有効にします。

文字列

s3、swift、swift_auth、admin すべての API

rgw_cache_enabled

Ceph Object Gateway キャッシュが有効かどうか。

ブール値

true

rgw_cache_lru_size

Ceph Object Gateway キャッシュのエントリー数。

整数

10000

rgw_socket_path

ドメインソケットのソケットパス。FastCgiExternalServer はこのソケットを使用します。ソケットパスを指定しない場合、Ceph Object Gateway は外部サーバーとして実行されません。ここで指定するパスは、rgw.conf ファイルで指定されたパスと同じである必要があります。

文字列

該当なし

rgw_host

Ceph Object Gateway インスタンスのホスト。IP アドレスまたはホスト名を指定できます。

文字列

0.0.0.0

rgw_port

インスタンスが要求をリッスンするポート指定しない場合、Ceph Object Gateway は外部の FastCGI を実行します。

文字列

なし

rgw_dns_name

提供されるドメインの DNS 名。ゾーングループ内での hostnames の設定も参照してください。

文字列

なし

rgw_script_uri

リクエストで設定されていない場合は SCRIPT_URI の代替値。

文字列

なし

rgw_request_uri

リクエストで設定されていない場合は REQUEST_URI の代替値。

文字列

なし

rgw_print_continue

稼働中の場合は 100-continue を有効にします。

ブール値

true

rgw_remote_addr_param

リモートアドレスパラメーター。たとえば、リモートアドレスを含む HTTP フィールド、またはリバースプロキシが動作している場合は X-Forwarded-For アドレス。

文字列

REMOTE_ADDR

rgw_op_thread_timeout

オープンスレッドのタイムアウト(秒単位)。

整数

600

rgw_op_thread_suicide_timeout

Ceph Object Gateway プロセスが終了するまでの timeout 時間 (秒単位)。0 に設定すると無効です。

整数

0

rgw_thread_pool_size

スレッドプールのサイズ。この変数は、設定されている場合に num_threads によって上書きされます。詳細は「Civetweb 設定オプション 」を参照してください。

整数

512

rgw_num_control_oids

異なる rgw インスタンス間でキャッシュの同期に使用される通知オブジェクトの数。

整数

8

rgw_init_timeout

Ceph Object Gateway が初期化する前の秒数。

整数

30

rgw_mime_types_file

MIME タイプのパスおよび場所。Swift のオブジェクトタイプの自動検出に使用されます。

文字列

/etc/mime.types

rgw_gc_max_objs

1 つのガベッジコレクション処理サイクルでガべージコレクションによって処理される可能性のあるオブジェクトの最大数。

整数

32

rgw_gc_obj_min_wait

ガベッジコレクション処理によってオブジェクトが削除され、処理される前の最小待機時間。

整数

2 * 3600

rgw_gc_processor_max_time

2 回連続したガベージコレクション処理サイクルの開始間の最大時間。

整数

3600

rgw_gc_processor_period

ガベージコレクション処理のサイクル時間。

整数

3600

rgw_s3 success_create_obj_status

create-obj の代替成功ステータス応答。

整数

0

rgw_resolve_cname

rgw が要求ホスト名フィールドの DNS CNAME レコードを使用するべきかどうか (ホスト名が rgw_dns 名と等しくない場合)。

ブール値

false

rgw_object_stripe_size

Ceph Object Gateway オブジェクトのオブジェクトストライプのサイズ。

整数

4 << 20

rgw_extended_http_attrs

オブジェクトに設定できる属性の新しいセットを追加します。これらの追加属性は、オブジェクトを配置する際に HTTP ヘッダーフィールドを使用して設定できます。設定された場合、オブジェクトで GET/HEAD を実行する際にこれらの属性が HTTP フィールドとして返されます。

文字列

なし。例: "content_foo, content_bar"

rgw_exit_timeout_secs

プロセスが無条件を終了するまで待機する秒数。

整数

120

rgw_get_obj_window_size

単一のオブジェクト要求のウィンドウサイズ(バイト単位)。

整数

16 << 20

rgw_get_obj_max_req_size

Ceph Storage クラスターに送信される単一の取得操作の最大リクエストサイズ。

整数

4 << 20

rgw_relaxed_s3_bucket_names

ゾーングループバケットの緩和された S3 バケット名ルールを有効にします。

ブール値

false

rgw_list buckets_max_chunk

ユーザーバケットを一覧表示する際に単一操作で取得するバケットの最大数。

整数

1000

rgw_override_bucket_index_max_shards

バケットインデックスオブジェクトのシャード数。値が 0 の場合は、シャード化がないことを示します。Red Hat では、バケットの一覧のコストを増やすため、大きすぎる値 (1000など) を設定することは推奨されません。

この変数は、 [client] セクションまたは [global] セクションで設定して、radosgw-admin コマンドに自動的に適用されるようにする必要があります。

整数

0

rgw_num_zone_opstate_shards

inter-zonegroup コピーの進捗情報を維持するためのシャードの最大数。

整数

128

rgw_opstate_ratelimit_sec

単一アップロードで opstate を更新する間隔の最小時間。0 レート制限を無効にします。

整数

30

rgw_curl_wait_timeout_ms

特定の curl 呼び出しのタイムアウト (ミリ秒単位)。

整数

1000

rgw_copy_obj_progress

長いコピー操作中のオブジェクト進捗の出力を有効にします。

ブール値

true

rgw_copy_obj_progress_every_bytes

コピーの進捗出力との間の最小バイト。

整数

1024 * 1024

rgw_admin_entry

管理要求 URL のエントリーポイント。

文字列

admin

rgw_content_length_compat

CONTENT_LENGTH および HTTP_CONTENT_LENGTH セットで、FCGI 要求の互換性性処理を有効にします。

ブール値

false

rgw_bucket_default_quota_max_objects

デフォルトのバケットごとのオブジェクトの最大数。この値は、他のクォータが指定されていない場合に、新規ユーザーに設定されます。既存ユーザーには影響しません。

この変数は、 [client] セクションまたは [global] セクションで設定して、radosgw-admin コマンドに自動的に適用されるようにする必要があります。

整数

-1

rgw_bucket_quota_ttl

キャッシュされたクォータ情報の秒数は信頼されます。このタイムアウト後、クォータ情報はクラスターから再度フェッチされます。

整数

600

rgw_user_quota_bucket_sync_interval

クラスターへの同期前にバケットクォータ情報が累積される時間(秒単位)。この間、他の RGW インスタンスは、このインスタンスに対する操作からのバケットクォータ統計の変更は表示されません。

整数

180

rgw_user_quota_sync_interval

ユーザークォータ情報がクラスターへの同期前に累積される時間(秒単位)。この間、他の RGW インスタンスは、このインスタンスに対する操作からユーザークォータの統計の変更を表示しません。

整数

3600 * 24

4.2. プールについて

Ceph ゾーンは、一連の Ceph Storage クラスタープールにマッピングします。

手動で作成されたプールと 生成されたプール

Ceph Object Gateway のユーザーキーに書き込み機能が含まれる場合、ゲートウェイではプールを自動的に作成する機能があります。これは、使い始めるのに便利です。ただし、Ceph Object Storage クラスターは、Ceph 設定ファイルに設定されていない限り、配置グループのデフォルト値を使用します。さらに、Ceph はデフォルトの CRUSH 階層を使用します。これらの設定は、実稼働システムに適して いません

実稼働システムを設定するには、「CephObject Gateway for Production guide for Production guide for Red Hat Ceph Storage 3」を参照してください。ストレージ戦略は、『実稼働用 Ceph Object Gateway 』の「ストレージ戦略の開発 」セクションを参照してください。

Ceph Object Gateway のデフォルトゾーンのデフォルトプールには、以下が含まれます。

  • .rgw.root
  • .default.rgw.control
  • .default.rgw.gc
  • .default.log
  • .default.intent-log
  • .default.usage
  • .default.users
  • .default.users.email
  • .default.users.swift
  • .default.users.uid

Ceph Object Gateway は、ゾーンごとにプールを作成します。プールを手動で作成する場合は、ゾーン名の先頭に追加します。システムプールは、システム制御、ガベージコレクション、ロギング、ユーザー情報、使用方法などに関連するオブジェクトを保存します。通常、これらのプール名の前にプール名が追加されます。

  • .<zone-name>.rgw.control: コントロールプール。
  • .<zone-name>.rgw.gc: 削除するオブジェクトのハッシュバケットが含まれるガベージコレクションプール。
  • .<zone-name>.log: ログプールには、すべてのバケット/コンテナーのログおよび create、read、update、および delete などのオブジェクトアクションが含まれます。
  • .<zone-name>.intent-log: 要求が失敗した場合に備えるオブジェクト更新要求のコピーが含まれます。
  • .<zone-name>.users.uid: ユーザー ID プールには、一意のユーザー ID のマップが含まれます。
  • .<zone-name>.users.keys: キープールには、各ユーザー ID のアクセスキーおよびシークレットキーが含まれます。
  • .<zone-name>.users.email: 電子メールプールには、ユーザー ID に関連付けられたメールアドレスが含まれます。
  • .<zone-name>.users.swift: Swift プールには、ユーザー ID の Swift サブユーザー情報が含まれます。
  • .<zone-name>.usage: 使用率プールには、ユーザーごとに使用ログが含まれます。

Ceph Object Gateways は、配置プールにバケットインデックス (index_pool) およびバケットデータ (data_pool) のデータを保存します。これらは重複する可能性があります。つまり、インデックスとデータに同じプールを使用できます。デフォルト配置のインデックスプールは {zone-name}.rgw.buckets.index であり、デフォルト配置のデータプールのインデックスプールは {zone-name}.rgw.buckets です。

名前説明タイプデフォルト

rgw_zonegroup_root_pool

すべてのゾーングループ固有の情報を保存するプール。

文字列

.rgw.root

rgw_zone_root_pool

ゾーン固有の情報を保存するプール。

文字列

.rgw.root

4.3. Swift 設定

名前説明タイプデフォルト

rgw_enforce_swift_acls

Swift アクセス制御リスト(ACL)設定を強制します。

ブール値

true

rgw_swift_token_expiration

Swift トークンの有効期限が切れるまでの時間(秒単位)。

整数

24 * 3600

rgw_swift_url

Ceph Object Gateway Swift API の URL。

文字列

なし

rgw_swift_url_prefix

Swift API の URL プレフィックス (例: http://fqdn.com/swift)。

swift

該当なし

rgw_swift_auth_url

v1 認証トークンの検証に使用するデフォルトの URL(内部 Swift 認証を使用しない場合)。

文字列

なし

rgw_swift_auth_entry

Swift 認証 URL のエントリーポイント。

文字列

auth

4.4. ログ設定

名前説明タイプデフォルト

rgw_log_nonexistent_bucket

Ceph Object Gateway を有効にして、存在しないバケットの要求をログに記録します。

ブール値

false

rgw_log_object_name

オブジェクト名のロギング形式。フォーマット指定子の詳細は、man ページの date を参照してください。

Date

%y-%m-%d-%H-%i-%n

rgw_log_object_name_utc

ログに記録されたオブジェクト名に UTC 時間が含まれるかどうか。false の場合はローカルタイムを使用します。

ブール値

false

rgw_usage_max_shards

使用ロギング用のシャードの最大数。

整数

32

rgw_usage_max_user_shards

単一ユーザーの使用ロギングに使用されるシャードの最大数。

整数

1

rgw_enable_ops_log

成功した各 Ceph Object Gateway 操作のロギングを有効にします。

ブール値

false

rgw_enable_usage_log

usage ログを有効にします。

ブール値

false

rgw_ops_log_rados

操作ログが Ceph Storage クラスターのバックエンドに書き込まれるかどうか。

ブール値

true

rgw_ops_log_socket_path

操作ログを書き込む Unix ドメインソケット。

文字列

なし

rgw_ops_log_data-backlog

Unix ドメインソケットに書き込まれた操作ログのデータバックログの最大バックログサイズ。

整数

5 << 20

rgw_usage_log_flush_threshold

同期的にフラッシュする前に、使用ログのダーティーマージエントリーの数。

整数

1024

rgw_usage_log_tick_interval

保留中の使用量のログデータを n 秒ごとにフラッシュします。

整数

30

rgw_intent_log_object_name

目的ログオブジェクト名のロギング形式。フォーマット指定子の詳細は、man ページの date を参照してください。

Date

%y-%m-%d-%i-%n

rgw_intent_log_object_name_utc

目的ログオブジェクト名に UTC 時間が含まれるかどうか。false の場合はローカルタイムを使用します。

ブール値

false

rgw_data_log_window

データログエントリーウインドウ(秒単位)。

整数

30

rgw_data_log_changes_size

データ変更ログを保持するインメモリーエントリーの数。

整数

1000

rgw_data_log_num_shards

データの変更ログを保持するシャード(オブジェクト)の数。

整数

128

rgw_data_log_obj_prefix

データログのオブジェクト名のプレフィックス。

文字列

data_log

rgw_replica_log_obj_prefix

レプリカログのオブジェクト名接頭辞。

文字列

replica log

rgw_md_log_max_shards

メタデータログのシャードの最大数。

整数

64

4.5. Keystone の設定

名前説明タイプデフォルト

rgw_keystone_url

Keystone サーバーの URL。

文字列

なし

rgw_keystone_admin_token

Keystone 管理トークン(共有シークレット)

文字列

なし

rgw_keystone_accepted_roles

要求を提供するのに必要なロール。

文字列

Member, admin

rgw_keystone_token_cache_size

各 Keystone トークンキャッシュのエントリーの最大数。

整数

10000

rgw_keystone_revocation_interval

トークン失効チェックの間隔(秒単位)。

整数

15 * 60

4.6. LDAP 設定

名前説明タイプ

rgw_ldap_uri

URI 形式の LDAP サーバーのスペース区切りの一覧。

文字列

ldaps://<ldap.your.domain>

rgw_ldap_searchdn

ベースドメインとも呼ばれる LDAP 検索ドメイン名。

文字列

cn=users,cn=accounts,dc=example,dc=com

rgw_ldap_binddn

ゲートウェイはこの LDAP エントリー(ユーザー一致)とバインドします。

文字列

uid=admin,cn=users,dc=example,dc=com

rgw_ldap_secret

rgw_ldap_binddn の認証情報を含むファイル

文字列

/etc/openldap/secret

rgw_ldap_dnattr

Ceph オブジェクトゲートウェイのユーザー名が含まれる LDAP 属性(binddns の形式)。

文字列

uid

第5章 マルチサイト

単一ゾーン構成は通常、1 つのゾーンと 1 つ以上の ceph-radosgw インスタンスを含む 1 つのゾーングループで構成され、インスタンス間でゲートウェイクライアント要求の負荷を分散できます。単一のゾーン設定では、通常複数のゲートウェイインスタンスは単一の Ceph ストレージクラスターを参照します。ただし、Red Hat は、Ceph Object Gateway に複数の複数サイトの設定オプションをサポートしています。

  • マルチゾーン: より高度な構成は、1 つのゾーングループと複数のゾーンで構成され、各ゾーンには 1 つ以上の ceph-radosgw インスタンスがあります。それぞれのゾーンは、独自の Ceph Storage クラスターによってサポートされます。ゾーングループの複数のゾーンにより、ゾーングループに対する障害復旧が行われ、ゾーングループでは大きな障害が発生する可能性があります。Red Hat Ceph Storage 2 以降のリリースでは、各ゾーンはアクティブになり、書き込み操作を受け取る可能性があります。障害復旧に加えて、複数のアクティブなゾーンがコンテンツ配信ネットワークの基盤としても機能します。レプリケーションなしで複数のゾーンを設定するには、「レプリケーションなしの複数ゾーンの設定」 を参照してください。
  • Multi-zone-group: 「regions」と呼ばれ、Ceph Object Gateway は、1 つ以上のゾーングループ(各ゾーングループ)をサポートすることもできます。同じレルム内のゾーングループに保存されるオブジェクトは、グローバル namespace を共有し、ゾーングループとゾーン全体で一意のオブジェクト ID を確保します。
  • 複数レルム - Red Hat Ceph Storage 2 以降のリリースでは、Ceph Object Gateway はレルムの概念をサポートします。これは、単一ゾーングループまたは複数のゾーングループで、またレルムのグローバル一意の namespace です。複数のレルムは、さまざまな設定と namespace をサポートする機能を提供します。
gateway realm

5.1. 要件および前提条件

マルチサイトの設定には、2 つ以上の Ceph Storage クラスターと、2 つ以上の Ceph オブジェクトゲートウェイインスタンス(Ceph Storage クラスターごとに 1 つ以上)が必要です。

本ガイドでは、地理的に別々の場所に 2 つ以上の Ceph Storage クラスターがあることを前提としていますが、この設定は同じ物理サイトで機能します。本ガイドでは、rgw1rgw2rgw3、および rgw4 という名前の 4 つの Ceph オブジェクトゲートウェイサーバーをそれぞれ前提としています。

マルチサイト構成では、マスターゾーングループとマスターゾーンが必要です。さらに、各ゾーングループにはマスターゾーンが必要です。ゾーングループには、1 つ以上のセカンダリーまたはマスター以外のゾーンを指定できます。

重要

レルムのマスターゾーングループ内のマスターゾーンは、(radosgw-admin CLI によって作成された) ユーザー、クォータ、バケットを含むレルムのメタデータのマスターコピーを保存する役割を果たします。このメタデータはセカンダリーゾーンとセカンダリーゾーングループに自動的に同期されます。radosgw-admin CLI で実行されるメタデータ操作は、セカンダリーゾーングループおよびゾーンに確実に同期されるように、マスターゾーングループのマスターゾーン内のホストで 実行する必要 があります。現在、セカンダリゾーンとゾーングループでメタデータ操作を実行することは 可能です が、同期 されず ため、メタデータが断片化されるため、推奨されません

次の例では、rgw1 ホストがマスターゾーングループのマスターゾーンとして機能します。rgw2 ホストは、マスターゾーングループのセカンダリーゾーンとして機能します。rgw3 ホストは、セカンダリーゾーングループのマスターゾーンとして機能します。rgw4 ホストは、セカンダリーゾーングループのセカンダリーゾーンとして機能します。

5.2. プール

Red Hatは、Ceph 配置グループのプールごとの計算機 を使用して、ceph-radosgw デーモンが作成するプールに適した配置グループの数を計算することを推奨します。Ceph 設定ファイルのデフォルト値として計算された値を設定します。以下に例を示します。

osd pool default pg num = 50
osd pool default pgp num = 50
注記

ストレージクラスターの Ceph 設定ファイルにこの変更を行ってから、構成へのランタイムの変更を行い、ゲートウェイインスタンスがプールを作成する際にこれらのデフォルトを使用するようにします。

または、プールを手動で作成します。プールの作成に関する詳細は 、『ストラテジー戦略ガイド 』の「プール」の章を参照してください。

ゾーンに固有のプール名は、命名規則 {zone-name}.pool-name に従います。たとえば、us-east という名前のゾーンには以下のプールがあります。

  • .rgw.root
  • us-east.rgw.control
  • us-east.rgw.data.root
  • us-east.rgw.gc
  • us-east.rgw.log
  • us-east.rgw.intent-log
  • us-east.rgw.usage
  • us-east.rgw.users.keys
  • us-east.rgw.users.email
  • us-east.rgw.users.swift
  • us-east.rgw.users.uid
  • us-east.rgw.buckets.index
  • us-east.rgw.buckets.data

5.3. Object Gateway のインストール

Ceph Object Gateway をインストールするには、『Red Hat Ceph Storage 3Installation Guide for Ubuntu 』を参照してください。

すべての Ceph Object Gateway ノードは、「Red Hat Ceph Storage のインストール要件」セクションにリストされているタスクに従う必要があります。

Ansible は、Ceph Object Gateway を Ceph Storage クラスターで使用できるようにインストールおよび設定することができます。マルチサイトおよびマルチサイトグループのデプロイメントの場合、各ゾーンに Ansible 設定が必要です。

Ansible を使用して Ceph Object Gateway をインストールすると、Ansible Playbook は初期設定を処理します。Ansible を使用して Ceph Object Gateway をインストールするには、ホストを /etc/ansible/hosts ファイルに追加します。[rgws] セクションの下に Ceph Object Gateway ホストを追加して、Ansible に対するそのロールを識別します。ホストに連続的な命名がある場合は、範囲を使用できます。以下に例を示します。

[rgws]
<rgw-host-name-1>
<rgw-host-name-2>
<rgw-host-name[3..10]>

ホストを追加したら、Ansible Playbook を再実行できます。

注記

Ansible はゲートウェイが実行されていることを確認し、デフォルトのゾーンおよびプールを手動で削除する必要がある場合があります。本ガイドでは、以下の手順について説明します。

非同期更新で既存のマルチサイトクラスターを更新する場合は、更新のインストール手順に従います。次に、ゲートウェイインスタンスを再起動します。

注記

インスタンスの再起動に必要な順序はありません。Red Hat は、まずマスターゾーングループとマスターゾーンを再起動し、その後にセカンダリーゾーングループとセカンダリーゾーンを再起動することを推奨します。

5.4. 複数サイトレルムの確立

クラスターのすべてのゲートウェイには設定があります。マルチサイトレルムでは、これらのゲートウェイは異なるゾーングループとゾーンに存在する場合があります。一方で、レルム内で連携する必要があります。マルチサイトレルムでは、すべてのゲートウェイインスタンスは、マスターゾーングループおよびマスターゾーン内のホスト上の ceph-radosgw デーモンから構成を取得する 必要があります

そのため、マルチサイトクラスターの作成における最初の手順では、レルム、マスターゾーングループ、およびマスターゾーンを確立する必要があります。マルチサイト構成でゲートウェイを構成するには、レルム構成、マスターゾーングループ、およびマスターゾーンを保持する ceph-radosgw インスタンスを選択します。

5.4.1. レルムの作成

レルムには、ゾーングループおよびゾーンのマルチサイト設定が含まれ、またレルム内でグローバルに一意の namespace を適用することにも対応します。

マスターゾーングループおよびゾーンで指定するように識別されたホストでコマンドラインインターフェースを開いて、マルチサイト設定の新しいレルムを作成します。次に、以下のコマンドを実行します。

[root@master-zone]# radosgw-admin realm create --rgw-realm={realm-name} [--default]

以下に例を示します。

[root@master-zone]# radosgw-admin realm create --rgw-realm=movies --default

クラスターに単一のレルムがある場合は、--default フラグを指定します。--default が指定されている場合、radosgw-admin はデフォルトでこのレルムを使用します。--default が指定されていない場合に、ローングループおよびゾーンを追加するには、--rgw-realm フラグまたは --realm-id フラグのいずれかを指定して、ゾーングループおよびゾーンを追加するときにレルムを識別する必要があります。

レルムの作成後、radosgw-admin はレルム設定を返します。以下に例を示します。

{
    "id": "0956b174-fe14-4f97-8b50-bb7ec5e1cf62",
    "name": "movies",
    "current_period": "1950b710-3e63-4c41-a19e-46a715000980",
    "epoch": 1
}
注記

Ceph はレルムに一意の ID を生成します。これにより、必要に応じてレルムの名前を変更することができます。

5.4.2. マスターゾーングループの作成

レルムには、少なくとも 1 つのゾーングループが必要です。このグループは、レルムのマスターゾーングループとして機能します。

マスターゾーングループとゾーンで提供されるように識別されたホストでコマンドラインインターフェースを開いて、マルチサイト設定の新規マスターゾーングループを作成します。次に、以下のコマンドを実行します。

[root@master-zone]# radosgw-admin zonegroup create --rgw-zonegroup={name} --endpoints={url} [--rgw-realm={realm-name}|--realm-id={realm-id}] --master --default

以下に例を示します。

[root@master-zone]# radosgw-admin zonegroup create --rgw-zonegroup=us --endpoints=http://rgw1:80 --rgw-realm=movies --master --default

レルムにゾーングループが 1 つしかない場合は、--default フラグを指定します。--default が指定されている場合、radosgw-admin はデフォルトでこのゾーングループを使用します。--default が指定されていない場合に、ゾーンを追加または変更するときにゾーングループを識別するには、--rgw-zonegroup フラグまたは --zonegroup-id フラグのいずれかが必要になります。

マスターゾーングループの作成後、radosgw-admin はゾーングループの設定を返します。以下に例を示します。

{
    "id": "f1a233f5-c354-4107-b36c-df66126475a6",
    "name": "us",
    "api_name": "us",
    "is_master": "true",
    "endpoints": [
        "http:\/\/rgw1:80"
    ],
    "hostnames": [],
    "hostnames_s3webzone": [],
    "master_zone": "",
    "zones": [],
    "placement_targets": [],
    "default_placement": "",
    "realm_id": "0956b174-fe14-4f97-8b50-bb7ec5e1cf62"
}

5.4.3. マスターゾーンの作成

重要

ゾーンは、ゾーン内にある Ceph Object Gateway ノードに作成する必要があります。

マスターゾーングループおよびゾーンで指定するように識別されたホストでコマンドラインインターフェースを開いて、マルチサイト設定のマスターゾーンを作成します。次に、以下のコマンドを実行します。

[root@master-zone]# radosgw-admin zone create
                            --rgw-zonegroup={zone-group-name} \
                            --rgw-zone={zone-name} \
                            --master --default \
                            --endpoints={http://fqdn:port}[,{http://fqdn:port}]

以下に例を示します。

[root@master-zone]# radosgw-admin zone create --rgw-zonegroup=us \
                            --rgw-zone=us-east \
                            --master --default \
                            --endpoints={http://fqdn:port}[,{http://fqdn:port}]
注記

--access-key および --secret を指定しません。次のセクションにユーザーを作成すると、これらの設定はゾーンに追加されます。

重要

以下の手順は、まだデータを保存していない、新たにインストールしたシステムを使用するマルチサイトの設定を想定しています。default ゾーンとそのプールをすでにデータの保存に使用している場合は、削除しないでください。削除すると、データが削除されて回復できなくなります。

5.4.4. デフォルトゾーングループおよびゾーンの削除

default ゾーンが存在する場合は削除します。必ず default ゾーングループから削除してください。

[root@master-zone]# radosgw-admin zonegroup remove --rgw-zonegroup=default --rgw-zone=default
[root@master-zone]# radosgw-admin period update --commit
[root@master-zone]# radosgw-admin zone delete --rgw-zone=default
[root@master-zone]# radosgw-admin period update --commit
[root@master-zone]# radosgw-admin zonegroup delete --rgw-zonegroup=default
[root@master-zone]# radosgw-admin period update --commit

最後に、Ceph ストレージクラスターの default プールが存在する場合は削除します。

重要

以下の手順は、現在データを保存していない、新たにインストールしたシステムを使用するマルチサイトの設定を想定しています。データを保存するために default ゾーングループを使用している場合は、このゾーングループを削除しないでください。

# rados rmpool default.rgw.control default.rgw.control --yes-i-really-really-mean-it
# rados rmpool default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-it
# rados rmpool default.rgw.gc default.rgw.gc --yes-i-really-really-mean-it
# rados rmpool default.rgw.log default.rgw.log --yes-i-really-really-mean-it
# rados rmpool default.rgw.users.uid default.rgw.users.uid --yes-i-really-really-mean-it

5.4.5. システムユーザーの作成

ceph-radosgw デーモンは、レルムおよび期間情報をプルする前に認証する必要があります。マスターゾーンで、デーモン間の認証を容易にするためにシステムユーザーを作成します。

[root@master-zone]# radosgw-admin user create --uid="{user-name}" --display-name="{Display Name}" --system

以下に例を示します。

[root@master-zone]# radosgw-admin user create --uid="synchronization-user" --display-name="Synchronization User" --system

セカンダリーゾーンではマスターゾーンでの認証が必要になるため、access_keysecret_key をメモしておきます。

最後に、マスターゾーンにシステムユーザーを追加します。

[root@master-zone]# radosgw-admin zone modify --rgw-zone=us-east --access-key={access-key} --secret={secret}
[root@master-zone]# radosgw-admin period update --commit

5.4.6. 期間の更新

マスターゾーン設定の更新後に、期間を更新します。

# radosgw-admin period update --commit
注記

期間を更新すると、他のゾーンが更新された設定を受け取るようにします。

5.4.7. Ceph 設定ファイルを更新します。

rgw_zone 構成オプションとマスターゾーンの名前をインスタンスエントリーに追加して、マスターゾーンホスト上の Ceph 構成ファイルを更新します。

[client.rgw.{instance-name}]
...
rgw_zone={zone-name}

以下に例を示します。

[client.rgw.rgw1]
host = rgw1
rgw frontends = "civetweb port=80"
rgw_zone=us-east

5.4.8. ゲートウェイの開始

オブジェクトゲートウェイホストで、Ceph Object Gateway サービスを開始して有効にします。

$ sudo systemctl start ceph-radosgw@rgw.`hostname -s`
$ sudo systemctl enable ceph-radosgw@rgw.`hostname -s`

サービスがすでに実行中の場合は、サービスを起動して有効にするのではなく、サービスを再起動します。

$ sudo systemctl restart ceph-radosgw@rgw.`hostname -s`

5.5. セカンダリーゾーンの確立

ゾーングループ内のゾーンはすべてデータを複製して、各ゾーンが同じデータを持つようにします。セカンダリーゾーンを作成するときは、セカンダリーゾーンにサービスを提供するように識別されたホストで すべてradosgw-admin zone 操作を実行します。

注記

ゾーンを追加するには、セカンダリーゾーンの追加と同じ手順に従います。別のゾーン名を使用してください。

重要

マスター zonegroup のマスターゾーン内のホストで、ユーザーの作成やクォータなどのメタデータ操作を実行する必要があります。マスターゾーンとセカンダリーゾーンは RESTful API からバケット操作を受信できますが、セカンダリーゾーンはバケット操作をマスターゾーンにリダイレクトします。マスターゾーンがダウンしている場合、バケット操作は失敗します。radosgw-admin CLI を使用してバケットを作成する場合は、マスターゾーングループのマスターゾーン内のホストでバケットを実行する必要があります。そうしないと、バケットは他のゾーングループおよびゾーンに同期されません。

5.5.1. レルムのプル

URL パスを使用し、マスターゾーングループのマスターゾーンのアクセスキーおよびシークレットを使用して、レルムをホストにプルします。デフォルト以外のレルムをプルするには、--rgw-realm 設定または --realm-id 設定オプションを使用してレルムを指定します。

# radosgw-admin realm pull --url={url-to-master-zone-gateway} --access-key={access-key} --secret={secret}

このレルムがデフォルトのレルムまたは唯一のレルムである場合は、レルムをデフォルトのレルムにします。

# radosgw-admin realm default --rgw-realm={realm-name}

5.5.2. 期間のプル

URL パスを使用し、マスターゾーングループのマスターゾーンのアクセスキーおよびシークレットを使用して、ホストに期間をプルします。デフォルト以外のレルムから期間をプルするには、--rgw-realm または --realm-id 構成オプションを使用してレルムを指定します。

# radosgw-admin period pull --url={url-to-master-zone-gateway} --access-key={access-key} --secret={secret}
注記

期間をプルすると、レルムのゾーングループおよびゾーン設定の最新バージョンを取得します。

5.5.3. セカンダリーゾーンの作成

重要

ゾーンは、ゾーン内にある Ceph Object Gateway ノードに作成する必要があります。

複数サイト設定のセカンダリーゾーンを作成するには、セカンダリーゾーンを提供するために識別されたホストでコマンドラインインターフェースを開きます。ゾーンのゾーングループ ID、新しいゾーン名とエンドポイントを指定します。--master フラグまたは --default フラグを使用 しないでください。Red Hat Ceph Storage 2 では、すべてのゾーンはデフォルトでアクティブ/アクティブ設定で実行されます。つまり、ゲートウェイクライアントはデータを任意のゾーンに書き込む可能性があり、ゾーンはゾーングループ内の他のすべてのゾーンにデータを複製します。セカンダリゾーンが書き込み操作を受け入れない場合は、--read-only フラグを指定して、マスターゾーンとセカンダリゾーンの間にアクティブ-パッシブ構成を作成します。さらに、マスターゾーングループのマスターゾーンに格納されている、生成されたシステムユーザーの access_key および secret_key を指定します。以下のコマンドを実行します。

[root@second-zone]# radosgw-admin zone create \
                           --rgw-zonegroup={zone-group-name}\
                           --rgw-zone={zone-name} --endpoints={url} \
                           --access-key={system-key} --secret={secret}\
                           --endpoints=http://{fqdn}:80 \
                           [--read-only]

以下に例を示します。

[root@second-zone]# radosgw-admin zone create --rgw-zonegroup=us \
                            --rgw-zone=us-west \
                            --access-key={system-key} --secret={secret} \
                            --endpoints=http://rgw2:80
重要

以下の手順は、データを格納していない新たにインストールされたシステムを使用するマルチサイトの設定を想定しています。default ゾーンとそのプールをすでにデータの保存に使用している場合は、削除しないでください。削除すると、データが失われ、回復できなくなります。

必要に応じてデフォルトゾーンを削除します。

[root@second-zone]# radosgw-admin zone delete --rgw-zone=default

最後に、必要に応じて Ceph Storage クラスターのデフォルトプールを削除します。

# rados rmpool default.rgw.control default.rgw.control --yes-i-really-really-mean-it
# rados rmpool default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-it
# rados rmpool default.rgw.gc default.rgw.gc --yes-i-really-really-mean-it
# rados rmpool default.rgw.log default.rgw.log --yes-i-really-really-mean-it
# rados rmpool default.rgw.users.uid default.rgw.users.uid --yes-i-really-really-mean-it

5.5.4. 期間の更新

マスターゾーン設定の更新後に、期間を更新します。

# radosgw-admin period update --commit
注記

期間を更新すると、他のゾーンが更新された設定を受け取るようにします。

5.5.5. Ceph 設定ファイルを更新します。

インスタンスエントリーに rgw_zone 構成オプションとセカンダリーゾーンの名前を追加して、セカンダリゾーンホストの Ceph 構成ファイルを更新します。

[client.rgw.{instance-name}]
...
rgw_zone={zone-name}

以下に例を示します。

[client.rgw.rgw2]
host = rgw2
rgw frontends = "civetweb port=80"
rgw_zone=us-west

5.5.6. ゲートウェイの開始

オブジェクトゲートウェイホストで、Ceph Object Gateway サービスを開始して有効にします。

$ sudo systemctl start ceph-radosgw@rgw.`hostname -s`
$ sudo systemctl enable ceph-radosgw@rgw.`hostname -s`

サービスがすでに実行中の場合は、サービスを起動して有効にするのではなく、サービスを再起動します。

$ sudo systemctl restart ceph-radosgw@rgw.`hostname -s`

5.6. フェイルオーバーおよび障害復旧

マスターゾーンが失敗する場合、障害復旧のためにセカンダリーゾーンにフェイルオーバーします。

  1. マスターゾーンとデフォルトゾーンをセカンダリーゾーンにします。以下に例を示します。

    # radosgw-admin zone modify --rgw-zone={zone-name} --master --default

    デフォルトでは、Ceph Object Gateway はアクティブ/アクティブ設定で実行されます。クラスターがアクティブ/パッシブ構成で実行されるように設定されている場合には、セカンダリーゾーンは読み取り専用ゾーンになります。ゾーンが書き込み操作を受け取れるように --read-only ステータスを削除します。以下に例を示します。

    # radosgw-admin zone modify --rgw-zone={zone-name} --master --default
  2. 変更を反映するために期間を更新します。

    # radosgw-admin period update --commit
  3. 最後に、Ceph Object Gateway を再起動します。

    $ sudo systemctl restart ceph-radosgw@rgw.`hostname -s`

以前のマスターゾーンが回復した場合は、操作に戻ります。

  1. 復元されたゾーンから、現在のマスターゾーンからレルムをプルします。

    # radosgw-admin realm pull --url={url-to-master-zone-gateway} \
                                --access-key={access-key} --secret={secret}
  2. マスターとデフォルトゾーンを回復したゾーンに設定します。

    # radosgw-admin zone modify --rgw-zone={zone-name} --master --default
  3. 変更を反映するために期間を更新します。

    # radosgw-admin period update --commit
  4. その後、リカバリーしたゾーンで Ceph Object Gateway を再起動します。

    $ sudo systemctl restart ceph-radosgw@rgw.`hostname -s`
  5. セカンダリーゾーンを読み取り専用設定する必要がある場合は、セカンダリーゾーンを更新します。

    # radosgw-admin zone modify --rgw-zone={zone-name} --read-only
  6. 変更を反映するために期間を更新します。

    # radosgw-admin period update --commit
  7. 最後に、セカンダリーゾーンで Ceph Object Gateway を再起動します。

    $ sudo systemctl restart ceph-radosgw@rgw.`hostname -s`

5.7. 単一サイトシステムの複数サイトへの移行

default ゾーングループとゾーンを持つシングルサイトシステムからマルチサイトシステムに移行するには、次の手順を使用します。

  1. レルムを作成します。<name> を、レルム名に置き換えます。

    [root@master-zone]# radosgw-admin realm create --rgw-realm=<name> --default
  2. デフォルトゾーンおよび zonegroup の名前を変更します。<name> を、ゾーングループまたはゾーン名に置き換えます。

    [root@master-zone]# radosgw-admin zonegroup rename --rgw-zonegroup default --zonegroup-new-name=<name>
    [root@master-zone]# radosgw-admin zone rename --rgw-zone default --zone-new-name us-east-1 --rgw-zonegroup=<name>
  3. マスター zonegroup を設定します。<name> を、レルムまたはゾーングループ名に置き換えます。<fqdn> を、ゾーングループの完全修飾ドメイン名に置き換えます。

    [root@master-zone]# radosgw-admin zonegroup modify --rgw-realm=<name> --rgw-zonegroup=<name> --endpoints http://<fqdn>:80 --master --default
  4. マスターゾーンを設定します。<name> を、レルム、ゾーングループ、またはゾーン名に置き換えます。<fqdn> を、ゾーングループの完全修飾ドメイン名に置き換えます。

    [root@master-zone]# radosgw-admin zone modify --rgw-realm=<name> --rgw-zonegroup=<name> \
                                --rgw-zone=<name> --endpoints http://<fqdn>:80 \
                                --access-key=<access-key> --secret=<secret-key> \
                                --master --default
  5. システムユーザーを作成します。<user-id> を、ユーザー名に置き換えます。<display-name> を、表示名に置き換えます。スペースを含めることができます。

    [root@master-zone]# radosgw-admin user create --uid=<user-id> \
                                --display-name="<display-name>" \
                                --access-key=<access-key> --secret=<secret-key> \ --system
  6. 更新された設定をコミットします。

    # radosgw-admin period update --commit
  7. 最後に、Ceph Object Gateway を再起動します。

    $ sudo systemctl restart ceph-radosgw@rgw.`hostname -s`

この手順を完了したら、「セカンダリゾーンの確立」に進み、マスターゾーングループにセカンダリゾーンを作成します。

5.8. マルチサイトのコマンドラインの使用

5.8.1. レルム

レルムは、1 つ以上のゾーンが含まれる 1 つ以上のゾーングループと、バケットを含むゾーングループで構成されるグローバル一意の namespace を表し、オブジェクトが含まれます。レルムにより、Ceph Object Gateway が同じハードウェアで複数の名前空間とその設定に対応できます。

レルムには、ピリオドの概念が含まれます。各期間は、ゾーングループとゾーン設定の状態を表します。zonegroup または zone に変更を加えるたびに、期間を更新してコミットします。

デフォルトでは、Ceph Object Gateway バージョン 2 は、バージョン 1.3 以前のバージョンとの後方互換性を確保するためにレルムを作成しません。ただし、ベストプラクティスとして、Red Hat は新規クラスターのレルムを作成することを推奨します。

5.8.1.1. レルムの作成

レルムを作成するには、realm create を実行してレルム名を指定します。レルムがデフォルトの場合は、--default を指定します。

[root@master-zone]# radosgw-admin realm create --rgw-realm={realm-name} [--default]

以下に例を示します。

[root@master-zone]# radosgw-admin realm create --rgw-realm=movies --default

--default を指定すると、--rgw-realm とレルム名が明示的に指定されていない限り、各 radosgw-admin 呼び出しでレルムが暗黙的に呼び出されます。

5.8.1.2. レルムのデフォルトの設定

レルム一覧に含まれるレルムは、デフォルトのレルムである必要があります。デフォルトのレルムは 1 つのみです。レルムが 1 つのみで、作成時にデフォルトのレルムとして指定されていない場合は、デフォルトのレルムにしてください。または、デフォルトであるレルムを変更するには、以下を実行します。

[root@master-zone]# radosgw-admin realm default --rgw-realm=movies
注記

レルムがデフォルトの場合、コマンドラインでは --rgw-realm=<realm-name> を引数と想定します。

5.8.1.3. レルムの削除

レルムを削除するには、realm delete を実行し、レルム名を指定します。

[root@master-zone]# radosgw-admin realm delete --rgw-realm={realm-name}

以下に例を示します。

[root@master-zone]# radosgw-admin realm delete --rgw-realm=movies

5.8.1.4. レルムの取得

レルムを取得するには、realm get を実行してレルム名を指定します。

# radosgw-admin realm get --rgw-realm=<name>

以下に例を示します。

# radosgw-admin realm get --rgw-realm=movies [> filename.json]

CLI はレルムプロパティーで JSON オブジェクトを echo します。

{
    "id": "0a68d52e-a19c-4e8e-b012-a8f831cb3ebc",
    "name": "movies",
    "current_period": "b0c5bbef-4337-4edd-8184-5aeab2ec413b",
    "epoch": 1
}

> と出力ファイル名を使用して、JSON オブジェクトをファイルに出力します。

5.8.1.5. レルムの設定

レルムを設定するには、realm set を実行し、レルム名を指定し、--infile= を入力ファイル名で指定します。

[root@master-zone]# radosgw-admin realm set --rgw-realm=<name> --infile=<infilename>

以下に例を示します。

[root@master-zone]# radosgw-admin realm set --rgw-realm=movies --infile=filename.json

5.8.1.6. レルムの一覧表示

レルムを一覧表示するには、realm list を実行します。

# radosgw-admin realm list

5.8.1.7. レルム期間の一覧表示

レルムの期間を一覧表示するには、realm list-periods を実行します。

# radosgw-admin realm list-periods

5.8.1.8. レルムのプル

マスターゾーングループとマスターゾーンを含むノードからセカンダリゾーングループまたはゾーンを含むノードにレルムをプルするには、レルム構成を受け取るノードで realm pull を実行します。

# radosgw-admin realm pull --url={url-to-master-zone-gateway} --access-key={access-key} --secret={secret}

5.8.1.9. レルムの名前変更

レルムはピリオドの一部ではありません。そのため、レルムの名前変更はローカルでのみ適用され、realm pull でプルされません。複数のゾーンを持つレルムの名前を変更する場合は、各ゾーンでこのコマンドを実行します。レルムの名前を変更するには、以下のコマンドを実行します。

# radosgw-admin realm rename --rgw-realm=<current-name> --realm-new-name=<new-realm-name>
注記

realm set を使用して name パラメーターを変更しないでください。内部名のみを変更します。--rgw-realm を指定すると、古いレルム名が使用されます。

5.8.2. ゾーングループ

Ceph Object Gateway は、ゾーングループの概念を使用して、マルチサイトのデプロイメントとグローバル名前空間をサポートします。以前の Red Hat Ceph Storage 1.3 で地域と呼ばれていましたが、ゾーングループは、1 つ以上のゾーン内の 1 つ以上の Ceph Object Gateway インスタンスの地理的な場所を定義します。

ゾーングループの設定は、通常の設定の手順とは異なります。これは、すべての設定が Ceph 設定ファイルに残っているわけではありません。ゾーングループを一覧表示し、ゾーングループ設定を取得し、ゾーングループ設定を設定できます。

注記

radosgw-admin zonegroup 操作は、レルム内の任意のホストで実行されます。ただし、radosgw-admin zone 操作は、ゾーン内のホストで実行する 必要があります

5.8.2.1. ゾーングループの作成

ゾーングループの作成は、ゾーングループ名を指定することで構成されます。ゾーンの作成では、--rgw-realm=<realm-name> が指定されていない限り、デフォルトのレルムで実行されていることを前提としています。ゾーングループがデフォルトのゾーングループの場合は、--default フラグを指定します。ゾーングループがマスターゾーングループの場合は、--master フラグを指定します。以下に例を示します。

# radosgw-admin zonegroup create --rgw-zonegroup=<name> [--rgw-realm=<name>][--master] [--default]
注記

zonegroup modify --rgw-zonegroup=<zonegroup-name> を使用して、既存のゾーングループの設定を変更します。

5.8.2.2. ゾーングループのデフォルトの作成

zonegroups の一覧内の zonegroup はデフォルトの zonegroup である必要があります。デフォルト zonegroup は 1 つのみです。zonegroup が 1 つのみで、作成時にデフォルトの zonegroup として指定されていない場合は、デフォルトの zonegroup にします。または、デフォルトで zonegroup を変更するには、次のコマンドを実行します。

# radosgw-admin zonegroup default --rgw-zonegroup=comedy
注記

ゾーングループがデフォルトの場合、コマンドラインは --rgw-zonegroup=<zonegroup-name> を引数として想定します。

次に、期間を更新します。

# radosgw-admin period update --commit

5.8.2.3. ゾーングループへのゾーンの追加

ゾーングループにゾーンを追加するには、ゾーンに追加するホストでこの手順を実行する必要があります。ゾーンを zonegroup に追加するには、次のコマンドを実行します。

# radosgw-admin zonegroup add --rgw-zonegroup=<name> --rgw-zone=<name>

次に、期間を更新します。

# radosgw-admin period update --commit

5.8.2.4. ゾーングループからのゾーンの削除

zonegroup からゾーンを削除するには、以下のコマンドを実行します。

# radosgw-admin zonegroup remove --rgw-zonegroup=<name> --rgw-zone=<name>

次に、期間を更新します。

# radosgw-admin period update --commit

5.8.2.5. ゾーングループの名前変更

zonegroup の名前を変更するには、次のコマンドを実行します。

# radosgw-admin zonegroup rename --rgw-zonegroup=<name> --zonegroup-new-name=<name>

次に、期間を更新します。

# radosgw-admin period update --commit

5.8.2.6. ゾーングループの削除

zonegroup を削除するには、以下のコマンドを実行します。

# radosgw-admin zonegroup delete --rgw-zonegroup=<name>

次に、期間を更新します。

# radosgw-admin period update --commit

5.8.2.7. ゾーングループの一覧表示

Ceph クラスターには、ゾーングループの一覧が含まれます。ゾーングループを一覧表示するには、次のコマンドを実行します。

# radosgw-admin zonegroup list

radosgw-admin は、JSON 形式のゾーングループの一覧を返します。

{
    "default_info": "90b28698-e7c3-462c-a42d-4aa780d24eda",
    "zonegroups": [
        "us"
    ]
}

5.8.2.8. ゾーングループの取得

ゾーングループの設定を表示するには、次のコマンドを実行します。

# radosgw-admin zonegroup get [--rgw-zonegroup=<zonegroup>]

ゾーングループの設定は以下のようになります。

{
    "id": "90b28698-e7c3-462c-a42d-4aa780d24eda",
    "name": "us",
    "api_name": "us",
    "is_master": "true",
    "endpoints": [
        "http:\/\/rgw1:80"
    ],
    "hostnames": [],
    "hostnames_s3website": [],
    "master_zone": "9248cab2-afe7-43d8-a661-a40bf316665e",
    "zones": [
        {
            "id": "9248cab2-afe7-43d8-a661-a40bf316665e",
            "name": "us-east",
            "endpoints": [
                "http:\/\/rgw1"
            ],
            "log_meta": "true",
            "log_data": "true",
            "bucket_index_max_shards": 0,
            "read_only": "false"
        },
        {
            "id": "d1024e59-7d28-49d1-8222-af101965a939",
            "name": "us-west",
            "endpoints": [
                "http:\/\/rgw2:80"
            ],
            "log_meta": "false",
            "log_data": "true",
            "bucket_index_max_shards": 0,
            "read_only": "false"
        }
    ],
    "placement_targets": [
        {
            "name": "default-placement",
            "tags": []
        }
    ],
    "default_placement": "default-placement",
    "realm_id": "ae031368-8715-4e27-9a99-0c9468852cfe"
}

5.8.2.9. ゾーングループの設定

ゾーングループの定義は、少なくとも必要な設定を指定する JSON オブジェクトの作成で構成されます。

  1. name: ゾーングループの名前。必須。
  2. api_name: ゾーングループの API 名。任意です。
  3. is_master: ゾーングループがマスターゾーングループであるかどうかを指定します。必須。注記: マスターゾーングループを 1 つだけ指定できます。
  4. endpoints: ゾーングループ内のエンドポイントの一覧。たとえば、複数のドメイン名を使用して、同じゾーングループを参照できます。忘れずに前方スラッシュ (\/) エスケープしてください。各エンドポイントにポート (fqdn:port) を指定することもできます。任意です。
  5. hostnames: ゾーングループのホスト名の一覧。たとえば、複数のドメイン名を使用して、同じゾーングループを参照できます。任意です。rgw dns name 設定は、このリストに自動的に含まれます。この設定を変更したら、ゲートウェイデーモンを再起動する必要があります。
  6. master_zone: ゾーングループのマスターゾーン。任意です。指定がない場合は、デフォルトのゾーンを使用します。注記: ゾーングループごとにマスターゾーンを 1 つだけ指定できます。
  7. zones: ゾーングループ内のゾーンの一覧。各ゾーンには、名前(必須)、エンドポイントのリスト(オプション)があり、ゲートウェイがメタデータおよびデータ操作をログに記録するかどうか(デフォルトは false)。
  8. placement_targets: 配置ターゲットの一覧 (任意)。各配置ターゲットには、配置ターゲットの名前 (必須) とタグのリスト (任意) が含まれているため、タグを持つユーザーのみが配置ターゲットを使用できます (つまり、ユーザー情報のユーザーの placement_tags フィールド)。
  9. default_placement: オブジェクトインデックスおよびオブジェクトデータのデフォルトの配置ターゲット。デフォルトでは default-placement に設定されます。各ユーザーのユーザー情報で、ユーザーごとのデフォルト配置を設定することもできます。

ゾーングループを設定するには、必須フィールドで構成される JSON オブジェクトを作成し、オブジェクトをファイル (たとえば、zonegroup.json) に保存します。次に、次のコマンドを実行します。

# radosgw-admin zonegroup set --infile zonegroup.json

ここで、zonegroup.json は作成した JSON ファイルです。

重要

default ゾーングループの is_master 設定は true です。新しいゾーングループを作成してそれをマスターゾーングループにしたい場合は、default ゾーングループ is_master 設定を false に設定するか、default ゾーングループを削除する必要があります。

最後に、期間を更新します。

# radosgw-admin period update --commit

5.8.2.10. ゾーングループマップの設定

ゾーングループマップの設定は、1 つ以上のゾーングループで構成される JSON オブジェクトの作成と、クラスターの master_zonegroupの 設定で構成されます。ゾーングループマップの各ゾーングループは、キーと値のペアで構成されます。key 設定は、個々のゾーングループ構成の 名前 設定と同等であり、val は、個々のゾーングループ構成で構成される JSON オブジェクトです。

is_mastertrue と同等のゾーングループを 1 つだけ持つ可能性があり、ゾーングループマップの最後に master_zonegroup として指定する必要があります。以下の JSON オブジェクトは、デフォルトゾーングループマップの例になります。

{
    "zonegroups": [
        {
            "key": "90b28698-e7c3-462c-a42d-4aa780d24eda",
            "val": {
                "id": "90b28698-e7c3-462c-a42d-4aa780d24eda",
                "name": "us",
                "api_name": "us",
                "is_master": "true",
                "endpoints": [
                    "http:\/\/rgw1:80"
                ],
                "hostnames": [],
                "hostnames_s3website": [],
                "master_zone": "9248cab2-afe7-43d8-a661-a40bf316665e",
                "zones": [
                    {
                        "id": "9248cab2-afe7-43d8-a661-a40bf316665e",
                        "name": "us-east",
                        "endpoints": [
                            "http:\/\/rgw1"
                        ],
                        "log_meta": "true",
                        "log_data": "true",
                        "bucket_index_max_shards": 0,
                        "read_only": "false"
                    },
                    {
                        "id": "d1024e59-7d28-49d1-8222-af101965a939",
                        "name": "us-west",
                        "endpoints": [
                            "http:\/\/rgw2:80"
                        ],
                        "log_meta": "false",
                        "log_data": "true",
                        "bucket_index_max_shards": 0,
                        "read_only": "false"
                    }
                ],
                "placement_targets": [
                    {
                        "name": "default-placement",
                        "tags": []
                    }
                ],
                "default_placement": "default-placement",
                "realm_id": "ae031368-8715-4e27-9a99-0c9468852cfe"
            }
        }
    ],
    "master_zonegroup": "90b28698-e7c3-462c-a42d-4aa780d24eda",
    "bucket_quota": {
        "enabled": false,
        "max_size_kb": -1,
        "max_objects": -1
    },
    "user_quota": {
        "enabled": false,
        "max_size_kb": -1,
        "max_objects": -1
    }
}

ゾーングループマップを設定するには、以下のコマンドを実行します。

# radosgw-admin zonegroup-map set --infile zonegroupmap.json

ここで、zonegroupmap.json は作成した JSON ファイルです。ゾーングループマップで指定されたゾーンが作成されていることを確認します。最後に、期間を更新します。

# radosgw-admin period update --commit

5.8.3. ゾーン

Ceph Object Gateway はゾーンの概念をサポートします。ゾーンは、1 つ以上の Ceph Object Gateway インスタンスで構成される論理グループを定義します。

ゾーンの設定は、すべて Ceph 設定ファイルで終了する設定の手順とは異なります。ゾーンの一覧を表示し、ゾーン設定を取得し、ゾーン設定を設定できます。

重要

radosgw-admin zone 操作はすべて、ゾーン内で動作するまたはこれから動作するホストで実行する 必要があります

5.8.3.1. ゾーンの作成

ゾーンを作成するには、ゾーン名を指定します。マスターゾーンの場合は、--master オプションを指定します。ゾーングループのゾーンは、マスターゾーンを 1 つだけ指定できます。ゾーングループにゾーンを追加するには、--rgw-zonegroup オプションをゾーングループ名で指定します。

重要

ゾーンは、ゾーン内にある Ceph Object Gateway ノードに作成する必要があります。

[root@zone] radosgw-admin zone create --rgw-zone=<name> \
                [--zonegroup=<zonegroup-name]\
                [--endpoints=<endpoint:port>[,<endpoint:port>] \
                [--master] [--default] \
                --access-key $SYSTEM_ACCESS_KEY --secret $SYSTEM_SECRET_KEY

次に、期間を更新します。

# radosgw-admin period update --commit

5.8.3.2. ゾーンの削除

ゾーンを削除するには、最初に zonegroup から削除します。

# radosgw-admin zonegroup remove --zonegroup=<name>\
                                 --zone=<name>

次に、期間を更新します。

# radosgw-admin period update --commit

次に、ゾーンを削除します。

重要

この手順では、ゾーン内のホストで MUST を実行する 必要があります

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

[root@zone]# radosgw-admin zone delete --rgw-zone<name>

最後に、期間を更新します。

# radosgw-admin period update --commit
重要

ゾーンを最初に削除せずに、ゾーンを削除しないでください。そうしないと、期間の更新に失敗します。

削除されたゾーンのプールがその他の場所で使用されない場合は、プールを削除することを検討してください。以下の例の <del-zone> を、削除したゾーン名に置き換えます。

重要

Ceph がゾーンプールを削除すると、リカバリーできない方法でデータ内のすべてのデータが削除されます。Ceph クライアントがプールの内容を必要としなくなった場合にのみゾーンプールを削除します。

重要

マルチレルムクラスターでは、.rgw.root プールをゾーンプールと共に削除すると、クラスターのレルム情報のすべてが削除されます。.rgw.root プールを削除する前に、.rgw.root に他のアクティブなレルムが含まれていないことを確認します。

# rados rmpool <del-zone>.rgw.control <del-zone>.rgw.control --yes-i-really-really-mean-it
# rados rmpool <del-zone>.rgw.data.root <del-zone>.rgw.data.root --yes-i-really-really-mean-it
# rados rmpool <del-zone>.rgw.gc <del-zone>.rgw.gc --yes-i-really-really-mean-it
# rados rmpool <del-zone>.rgw.log <del-zone>.rgw.log --yes-i-really-really-mean-it
# rados rmpool <del-zone>.rgw.users.uid <del-zone>.rgw.users.uid --yes-i-really-really-mean-it

5.8.3.3. ゾーンの変更

ゾーンを変更するには、ゾーン名と変更するパラメーターを指定します。

重要

ゾーンは、ゾーン内にある Ceph Object Gateway ノードで変更する必要があります。

[root@zone]# radosgw-admin zone modify [options]

--access-key=<key>--secret/--secret-key=<key>--master--default--endpoints=<list>

次に、期間を更新します。

# radosgw-admin period update --commit

5.8.3.4. ゾーンの一覧

root でクラスター内のゾーンを一覧表示するには、以下を実行します。

$ sudo radosgw-admin zone list

5.8.3.5. ゾーンの取得

root でゾーンの設定を取得するには、次のコマンドを実行します。

$ sudo radosgw-admin zone get [--rgw-zone=<zone>]

default ゾーンは以下のようになります。

{ "domain_root": ".rgw",
  "control_pool": ".rgw.control",
  "gc_pool": ".rgw.gc",
  "log_pool": ".log",
  "intent_log_pool": ".intent-log",
  "usage_log_pool": ".usage",
  "user_keys_pool": ".users",
  "user_email_pool": ".users.email",
  "user_swift_pool": ".users.swift",
  "user_uid_pool": ".users.uid",
  "system_key": { "access_key": "", "secret_key": ""},
  "placement_pools": [
      {  "key": "default-placement",
         "val": { "index_pool": ".rgw.buckets.index",
                  "data_pool": ".rgw.buckets"}
      }
    ]
  }

5.8.3.6. ゾーンの設定

ゾーンの設定には、一連の Ceph Object Gateway プールを指定する必要があります。一貫性を保つため、ゾーン名と同じプールプレフィックスを使用することが推奨されます。プールの設定に関する詳細は、「pools_」を参照してください。

重要

ゾーンは、ゾーン内にある Ceph Object Gateway ノードに設定する必要があります。

ゾーンを設定するには、プールで構成される JSON オブジェクトを作成し、オブジェクトをファイル (例: zone.json) に保存します。続いて以下のコマンドを実行して、{zone-name} をゾーンの名前に置き換えます。

[root@zone]$ sudo radosgw-admin zone set --rgw-zone={zone-name} --infile zone.json

ここで、zone.json は作成した JSON ファイルです。

次に、root でピリオドを更新します。

$ sudo radosgw-admin period update --commit

5.8.3.7. ゾーンの名前変更

ゾーンの名前を変更するには、ゾーン名と新しいゾーン名を指定します。ゾーン内のホストで以下のコマンドを実行します。

[root@zone]# radosgw-admin zone rename --rgw-zone=<name> --zone-new-name=<name>

次に、期間を更新します。

# radosgw-admin period update --commit

5.9. ゾーングループとゾーンの設定

デフォルトゾーングループおよびゾーンを設定する場合、プール名にはゾーン名が含まれます。以下に例を示します。

  • default.rgw.control

デフォルトを変更するには、各 [client.rgw.{instance-name}] インスタンスの配下にある Ceph 設定ファイルに以下の設定を追加します。

名前説明タイプデフォルト

rgw_zone

ゲートウェイインスタンスのゾーン名。

文字列

なし

rgw_zonegroup

ゲートウェイインスタンスのゾーングループの名前。

文字列

なし

rgw_zonegroup_root_pool

ゾーングループのルートプール。

文字列

.rgw.root

rgw_zone_root_pool

ゾーンのルートプール。

文字列

.rgw.root

rgw_default_zone_group_info_oid

デフォルトゾーングループを保存する OID。この設定の変更は推奨していません。

文字列

default.zonegroup

rgw_num_zone_opstate_shards

ゾーン間のグループ同期の進捗を保持する最大シャード数。

整数

128

5.10. マルチサイトを使用した手動によるバケットのリシャード化

{storage-product}DOES は、マルチサイトクラスターの動的バケット再シャード化をサポートしません。以下の手順を使用して、マルチサイトクラスターでバケットを手動で再シャード化できます。

注記
手動による再シャード化は、とくに手動再シャード化が保証される大規模なバケットの場合、非常にコストのかかるプロセスです。すべてのセカンダリーゾーンはすべてのオブジェクトを削除し、マスターゾーンから再同期します。

前提条件

  • すべての Object Gateway インスタンスを停止します。

手順

  1. マスターゾーングループのマスターゾーン内のノードで、以下のコマンドを実行します。

    # radosgw-admin bucket sync disable --bucket=BUCKET_NAME

    すべてのゾーンsync status が、データの同期が最新であることを報告するのを待ちます。

  2. すべて のゾーンで すべてceph-radosgw デーモンを停止します。
  3. マスターゾーングループのマスターゾーン内にあるノードで、バケットを再度シャード化します。以下に例を示します。

    # radosgw-admin bucket reshard --bucket=BUCKET_NAME --num-shards=NEW_SHARDS_NUMBER
  4. セカンダリーゾーンで、以下を実行します。

    # radosgw-admin bucket rm --purge-objects --bucket=BUCKET_NAME
  5. すべて のゾーンで すべてceph-radosgw デーモンを再起動します。
  6. マスターゾーングループのマスターゾーン内のノードで、以下のコマンドを実行します。

    # radosgw-admin bucket sync enable --bucket=BUCKET_NAME

メタデータの同期プロセスでは、更新されたバケットエントリーポイントとバケットインスタンスのメタデータが生成されます。データ同期プロセスは完全な同期を実行します。

5.11. レプリケーションなしの複数ゾーンの設定

相互に複製しない複数のゾーンを設定できます。たとえば、企業の各チーム専用のゾーンを作成できます。

前提条件

  • Ceph Object Gateway がインストールされている Ceph Storage クラスター。

手順

  1. レルムを作成します。

    radosgw-admin realm create --rgw-realm=realm-name [--default]

    以下に例を示します。

    [root@master-zone]# radosgw-admin realm create --rgw-realm=movies --default
    {
        "id": "0956b174-fe14-4f97-8b50-bb7ec5e1cf62",
        "name": "movies",
        "current_period": "1950b710-3e63-4c41-a19e-46a715000980",
        "epoch": 1
    }
  2. ゾーングループを作成します。

    radosgw-admin zonegroup create --rgw-zonegroup=zone-group-name --endpoints=url [--rgw-realm=realm-name|--realm-id=realm-id] --master --default

    以下に例を示します。

    [root@master-zone]# radosgw-admin zonegroup create --rgw-zonegroup=us --endpoints=http://rgw1:80 --rgw-realm=movies --master --default
    {
        "id": "f1a233f5-c354-4107-b36c-df66126475a6",
        "name": "us",
        "api_name": "us",
        "is_master": "true",
        "endpoints": [
            "http:\/\/rgw1:80"
        ],
        "hostnames": [],
        "hostnames_s3webzone": [],
        "master_zone": "",
        "zones": [],
        "placement_targets": [],
        "default_placement": "",
        "realm_id": "0956b174-fe14-4f97-8b50-bb7ec5e1cf62"
    }
  3. ユースケースに応じたゾーンを 1 つ以上作成します。

    radosgw-admin zone create
                 --rgw-zonegroup=zone-group-name \
                 --rgw-zone=zone-name \
                 --master --default \
                 --endpoints=http://fqdn:port[,http://fqdn:port]

    以下に例を示します。

    [root@master-zone]# radosgw-admin zone create --rgw-zonegroup=us \
                                                  --rgw-zone=us-east \
                                                  --master --default \
                                                  --endpoints=http://rgw1:80
  4. ゾーングループの設定が含まれる JSON ファイルを取得します。

    radosgw-admin zonegroup get --rgw-zonegroup=zone-group-name > zonegroup.json

    以下に例を示します。

    [root@master-zone]# radosgw-admin zonegroup get --rgw-zonegroup=us > zonegroup.json
  5. ファイルで、log_meta パラメーター、log_data パラメーター、および sync_from_all パラメーターを false に設定します。

        {
            "id": "72f3a886-4c70-420b-bc39-7687f072997d",
            "name": "default",
            "api_name": "",
            "is_master": "true",
            "endpoints": [],
            "hostnames": [],
            "hostnames_s3website": [],
            "master_zone": "a5e44ecd-7aae-4e39-b743-3a709acb60c5",
            "zones": [
                {
                    "id": "975558e0-44d8-4866-a435-96d3e71041db",
                    "name": "testzone",
                    "endpoints": [],
                    "log_meta": "false",
                    "log_data": "false",
                    "bucket_index_max_shards": 0,
                    "read_only": "false",
                    "tier_type": "",
                    "sync_from_all": "false",
                    "sync_from": []
                },
                {
                    "id": "a5e44ecd-7aae-4e39-b743-3a709acb60c5",
                    "name": "default",
                    "endpoints": [],
                    "log_meta": "false",
                    "log_data": "false",
                    "bucket_index_max_shards": 0,
                    "read_only": "false",
                    "tier_type": "",
                    "sync_from_all": "false",
                    "sync_from": []
                }
            ],
            "placement_targets": [
                {
                    "name": "default-placement",
                    "tags": []
                }
            ],
            "default_placement": "default-placement",
            "realm_id": "2d988e7d-917e-46e7-bb18-79350f6a5155"
        }
  6. 更新された JSON ファイルを使用します。

    radosgw-admin zonegroup set --rgw-zonegroup=zone-group-name --infile=zonegroup.json

    以下に例を示します。

    [root@master-zone]# radosgw-admin zonegroup set --rgw-zonegroup=us --infile=zonegroup.json
  7. 期間を更新します。

    # radosgw-admin period update --commit

5.12. 同じストレージクラスターでの複数のレルムの設定

このセクションでは、同じストレージクラスターで複数のレルムを設定する方法を説明します。これは、マルチサイトの高度なユースケースです。同じストレージクラスターで複数のレルムを設定すると、ローカルレルムを使用してローカル RGW クライアントトラフィックを処理し、セカンダリーサイトにレプリケートされるデータの複製レルムを処理できます。

注記

Red Hat では、各レルムに独自の Ceph Object Gateway があることを推奨します。

前提条件

  • ストレージクラスター内の各データセンターのアクセスキーおよびシークレットキー。
  • ストレージクラスターに 2 つの {storage-product} データセンターを実行します。
  • 各データセンターには、独自のローカルレルムがあります。これらは両方のサイトでレプリケートするレルムを共有します。
  • Ceph Object Gateway ノードで、{storage-product} インストールガイド {install-guide}#requirements-for-installing-rhcs の「Red Hat Ceph Storage のインストールの要件 」に記載されているタスクを実行します。
  • 各 Ceph Object Gateway ノードについては、『{storage-product} インストールガイド 』の「Installing Ceph Object Gateway 」セクションで手順 1-7 を実行します。

手順

  1. 同期ユーザーを作成します。

    構文

    radosgw-admin user create --uid="SYNCHRONIZATION_USER" --display-name="Synchronization User" --system

  2. ストレージクラスター内の最初のデータセンターにローカルレルムを 1 つ作成します。

    構文

    radosgw-admin realm create --rgw-realm=REALM_NAME --default

    [user@rgw1]$ radosgw-admin realm create --rgw-realm=ldc1 --default

  3. 最初のデータセンターに、ローカルのマスターゾーングループを 1 つ作成します。

    構文

    radosgw-admin zonegroup create --rgw-zonegroup=ZONE_GROUP_NAME --endpoints=http://RGW_NODE_NAME:80 --rgw-realm=REALM_NAME --master --default

    [user@rgw1]$ radosgw-admin zonegroup create --rgw-zonegroup=ldc1zg --endpoints=http://rgw1:80 --rgw-realm=ldc1 --master --default

  4. 最初のデータセンターにローカルゾーンを 1 つ作成します。

    構文

    radosgw-admin zone create --rgw-zonegroup=ZONE_GROUP_NAME --rgw-zone=ZONE_NAME --master --default --endpoints=HTTP_FQDN[,HTTP_FQDN]

    [user@rgw1]$ radosgw-admin zone create --rgw-zonegroup=ldc1zg --rgw-zone=ldc1z --master --default --endpoints=http://rgw.example.com

  5. 期間をコミットします。

    [user@rgw1]$ radosgw-admin period update --commit

  6. ceph.conf を、rgw_realm 名、rgw_zonegroup 名、および rgw_zone 名で更新します。

    構文

    rgw_realm = REALM_NAME
    rgw_zonegroup = ZONE_GROUP_NAME
    rgw_zone = ZONE_NAME

    rgw_realm = ldc1
    rgw_zonegroup = ldc1zg
    rgw_zone = ldc1z

  7. RGW デーモンを再起動します。

    構文

    systemctl restart ceph-radosgw@rgw.$(hostname -s).rgw0.service

  8. ストレージクラスター内の 2 番目のデータセンターにローカルレルムを作成します。

    構文

    radosgw-admin realm create --rgw-realm=REALM_NAME --default

    [user@rgw2]$ radosgw-admin realm create --rgw-realm=ldc2 --default

  9. 2 つ目のデータセンターに、ローカルのマスターゾーングループを作成します。

    構文

    radosgw-admin zonegroup create --rgw-zonegroup=ZONE_GROUP_NAME --endpoints=http://RGW_NODE_NAME:80 --rgw-realm=REALM_NAME --master --default

    [user@rgw2]$ radosgw-admin zonegroup create --rgw-zonegroup=ldc2zg --endpoints=http://rgw2:80 --rgw-realm=ldc2 --master --default

  10. 2 番目のデータセンターにローカルゾーンを 1 つ作成します。

    構文

    radosgw-admin zone create --rgw-zonegroup=ZONE_GROUP_NAME --rgw-zone=ZONE_NAME --master --default --endpoints=HTTP_FQDN[, HTTP_FQDN]

    [user@rgw2]$ radosgw-admin zone create --rgw-zonegroup=ldc2zg --rgw-zone=ldc2z --master --default --endpoints=http://rgw.example.com

  11. 期間をコミットします。

    [user@rgw2]$ radosgw-admin period update --commit

  12. ceph.conf を、rgw_realm 名、rgw_zonegroup 名、および rgw_zone 名で更新します。

    構文

    rgw_realm = REALM_NAME
    rgw_zonegroup = ZONE_GROUP_NAME
    rgw_zone = ZONE_NAME

    rgw_realm = ldc2
    rgw_zonegroup = ldc2zg
    rgw_zone = ldc2z

  13. RGW デーモンを再起動します。

    構文

    systemctl restart ceph-radosgw@rgw.$(hostname -s).rgw0.service

  14. レプリケーション/同期ユーザーを作成します。

    構文

    radosgw-admin user create --uid="r_REPLICATION_SYNCHRONIZATION_USER_" --display-name="Replication-Synchronization User" --system

  15. ストレージクラスター内の最初のデータセンターにレプリケートされたレルムを作成します。

    構文

    radosgw-admin realm create --rgw-realm=REPLICATED_REALM_1

    [user@rgw1] radosgw-admin realm create --rgw-realm=rdc1

  16. 最初のデータセンターのマスターゾーングループを作成します。

    構文

    radosgw-admin zonegroup create --rgw-zonegroup=RGW_ZONE_GROUP --endpoints=http://_RGW_NODE_NAME:80 --rgw-realm=_RGW_REALM_NAME --master --default

    [user@rgw1] radosgw-admin zonegroup create --rgw-zonegroup=rdc1zg --endpoints=http://rgw1:80 --rgw-realm=rdc1 --master --default

  17. 最初のデータセンターにマスターゾーンを作成します。

    構文

    radosgw-admin zone create --rgw-zonegroup=RGW_ZONE_GROUP --rgw-zone=_MASTER_RGW_NODE_NAME --master --default --endpoints=HTTP_FQDN[,HTTP_FQDN]

    [user@rgw1] radosgw-admin zone create --rgw-zonegroup=rdc1zg --rgw-zone=rdc1z --master --default --endpoints=http://rgw.example.com

  18. 期間をコミットします。

    構文

    radosgw-admin period update --commit

  19. 最初のデータセンターの rgw_realm 名、rgw_zonegroup 名、および rgw_zone 名で ceph.conf を更新します。

    構文

    rgw_realm = REALM_NAME
    rgw_zonegroup = ZONE_GROUP_NAME
    rgw_zone = ZONE_NAME

    rgw_realm = rdc1
    rgw_zonegroup = rdc1zg
    rgw_zone = rdc1z

  20. RGW デーモンを再起動します。

    構文

    systemctl restart ceph-radosgw@rgw.$(hostname -s).rgw0.service

  21. 2 つ目のデータセンターで複製されたレルムをプルします。

    構文

    radosgw-admin realm pull --url=https://tower-osd1.cephtips.com --access-key=ACCESS_KEY --secret-key=SECRET_KEY

    radosgw-admin realm pull --url=https://tower-osd1.cephtips.com --access-key=3QV0D6ZMMCJZMSCXJ2QJ --secret-key=VpvQWcsfI9OPzUCpR4kynDLAbqa1OIKqRB6WEnH8

  22. 最初のデータセンターから期間をプルします。

    構文

    radosgw-admin period pull --url=https://tower-osd1.cephtips.com --access-key=ACCESS_KEY --secret-key=SECRET_KEY

    radosgw-admin period pull --url=https://tower-osd1.cephtips.com --access-key=3QV0D6ZMMCJZMSCXJ2QJ --secret-key=VpvQWcsfI9OPzUCpR4kynDLAbqa1OIKqRB6WEnH8

  23. 2 番目のデータセンターにセカンダリーゾーンを作成します。

    構文

    radosgw-admin zone create --rgw-zone=RGW_ZONE --rgw-zonegroup=RGW_ZONE_GROUP --endpoints=https://tower-osd4.cephtips.com --access-key=_ACCESS_KEY --secret-key=SECRET_KEY

    [user@rgw2] radosgw-admin zone create --rgw-zone=rdc2z --rgw-zonegroup=rdc1zg --endpoints=https://tower-osd4.cephtips.com --access-key=3QV0D6ZMMCJZMSCXJ2QJ --secret-key=VpvQWcsfI9OPzUCpR4kynDLAbqa1OIKqRB6WEnH8

  24. 期間をコミットします。

    構文

    radosgw-admin period update --commit

  25. 2 番目のデータセンターの rgw_realm 名、rgw_zonegroup 名、および rgw_zone 名を持つ ceph.conf を更新します。

    構文

    rgw_realm = REALM_NAME
    rgw_zonegroup = ZONE_GROUP_NAME
    rgw_zone = ZONE_NAME

    rgw realm = rdc1
    rgw zonegroup = rdc1zg
    rgw zone = rdc2z

  26. RGW デーモンを再起動します。

    構文

    systemctl restart ceph-radosgw@rgw.$(hostname -s).rgw0.service

  27. 2 番目のデータセンターのエンドポイントに root としてログインします。
  28. マスターレルムの同期ステータスを確認します。

    構文

    radosgw-admin sync status

    [root@tower-osd4 ceph-ansible]# radosgw-admin sync status
              realm 59762f08-470c-46de-b2b1-d92c50986e67 (ldc2)
          zonegroup 7cf8daf8-d279-4d5c-b73e-c7fd2af65197 (ldc2zg)
               zone 034ae8d3-ae0c-4e35-8760-134782cb4196 (ldc2z)
      metadata sync no sync (zone is master)

  29. 最初のデータセンターのエンドポイントに root としてログインします。
  30. replication-synchronization レルムの同期ステータスを確認します。

    構文

    radosgw-admin sync status --rgw-realm RGW_REALM_NAME

    以下に例を示します。

    [root@tower-osd4 ceph-ansible]# [root@tower-osd4 ceph-ansible]# radosgw-admin sync status --rgw-realm rdc1
              realm 73c7b801-3736-4a89-aaf8-e23c96e6e29d (rdc1)
          zonegroup d67cc9c9-690a-4076-89b8-e8127d868398 (rdc1zg)
               zone 67584789-375b-4d61-8f12-d1cf71998b38 (rdc2z)
      metadata sync syncing
                    full sync: 0/64 shards
                    incremental sync: 64/64 shards
                    metadata is caught up with master
          data sync source: 705ff9b0-68d5-4475-9017-452107cec9a0 (rdc1z)
                            syncing
                            full sync: 0/128 shards
                            incremental sync: 128/128 shards
                            data is caught up with source
              realm 73c7b801-3736-4a89-aaf8-e23c96e6e29d (rdc1)
          zonegroup d67cc9c9-690a-4076-89b8-e8127d868398 (rdc1zg)
               zone 67584789-375b-4d61-8f12-d1cf71998b38 (rdc2z)
      metadata sync syncing
                    full sync: 0/64 shards
                    incremental sync: 64/64 shards
                    metadata is caught up with master
          data sync source: 705ff9b0-68d5-4475-9017-452107cec9a0 (rdc1z)
                            syncing
                            full sync: 0/128 shards
                            incremental sync: 128/128 shards
                            data is caught up with source
  31. ローカルサイトにデータを保存およびアクセスするには、ローカルレルムのユーザーを作成します。

    構文

    radosgw-admin user create --uid="LOCAL_USER" --display-name="Local user" --rgw-realm=_REALM_NAME --rgw-zonegroup=ZONE_GROUP_NAME --rgw-zone=ZONE_NAME

    [user@rgw2] #radosgw-admin user create --uid="local-user" --display-name="Local user" --rgw-realm=ldc1 --rgw-zonegroup=ldc1zg --rgw-zone=ldc1z

重要

デフォルトでは、マルチサイト設定にユーザーが追加されます。ユーザーがローカルゾーン内のデータにアクセスするには、radosgw-admin コマンドに --rgw-realm 引数が必要です。