Red Hat Training

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

Red Hat Enterprise Linux 用 Object Gateway ガイド

Red Hat Ceph Storage 3

Red Hat Enterprise LinuxでのCeph Storage Object Gatewayの構成と管理

概要

本ドキュメントでは、AMD64およびIntel 64アーキテクチャ上で動作するRed Hat Enterprise Linux 7上でCeph Storage Object Gatewayを構成し管理するための手順を説明します。

第1章 概要

RADOS Gateway (RGW)とも呼ばれるCeph Object Gatewayは、libradosの上に構築されたオブジェクトストレージインターフェースで、アプリケーションにCephストレージクラスタへのRESTfulなゲートウェイを提供します。Ceph Object Gatewayは2つのインタフェースをサポートしています。

  1. S3-compatible: Amazon S3 RESTful APIの大部分と互換性のあるインターフェイスで、オブジェクトストレージ機能を提供します。
  2. Swift-compatible: OpenStack Swift APIの大部分と互換性のあるインターフェースで、オブジェクトストレージ機能を提供します。

Cephオブジェクトゲートウェイは、Cephストレージクラスタと対話するためのサーバです。OpenStack SwiftおよびAmazon S3と互換性のあるインタフェースを提供しているため、Cephオブジェクトゲートウェイには独自のユーザ管理があります。Ceph object gatewayは、Cephブロックデバイスクライアントからのデータの格納に使用されるのと同じCephストレージクラスタにデータを格納できますが、その場合はプールが別々になり、CRUSH階層も異なる可能性があります。S3とSwiftのAPIは共通の名前空間を共有しているため、一方のAPIでデータを書き込み、もう一方のAPIでデータを取り出すことができます。

gateway
警告

RGW で使用するプールに RADOS スナップショットを使用しないでください。望ましくないデータの不整合が発生する可能性があります。

第2章 構成

2.1. CivetWebのフロントエンド

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

追加リソース

2.2. CivetWebポートの変更

Ansibleを使用してCeph Object Gatewayをインストールすると、CivetWebがポート8080で実行されるように構成されます。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がCeph Object Gatewayをポート8080でリッスンするように構成し、サポートされているRed Hat Ceph Storage 3のインストール方法はceph-ansibleを使用するため、Red Hat Ceph Storage 3のドキュメントではポート8080がデフォルトのポートと見なされます。

前提条件

  • 実行中の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設定ファイルのこの部分は、クライアントタイプがrgwで識別されるCeph Object Gatewayであり、ノード名がgateway-node1であるCeph Storage Clusterクライアントを設定していることがわかります。

  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サービスを再起動して、新しいポート設定を有効にします。

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

    # firewall-cmd --list-all
  6. ポートが開いていない場合は、ポートを追加して、ファイアウォールの設定をリロードしてください。

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

追加リソース

2.3. CivetwebでSSLを使う

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

重要

本番環境ではMUST HAProxy を使用し、keepalived で SSL 接続を HAProxy で終了させます。Civetweb での SSL の使用は、ONLY 小規模から中規模のtest and pre-production のデプロイメントに推奨されます。

Civetweb で SSL を使用するには、ゲートウェイノードのホスト名と一致する認証局(CA)から証明書を取得します。Red Hat は、S3 スタイルのサブドメインで使用するために、サブジェクトの代替名フィールドとワイルドカードを持つ CA から証明書を取得することをお勧めします。

Civetwebでは、鍵、サーバー証明書、その他の認証局や中間証明書を1つの.pemファイルにまとめる必要があります。

重要

.pemファイルには、秘密鍵が含まれています。.pemファイルを不正なアクセスから守る。

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

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

2.4. Civetweb設定オプション

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

オプション説明デフォルト

access_log_file

アクセスログ用のファイルへのパス。フルパス、または現在の作業ディレクトリからの相対パスです。存在しない場合(デフォルト)、アクセスは記録されません。

EMPTY

エラーログファイル

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

EMPTY

num_threads

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

512

リクエストタイムアウト_ms

ネットワークの読み取りおよび書き込み操作のタイムアウト(単位:ミリ秒)。クライアントが長時間の接続を維持しようとする場合は、この値を大きくするか、(より良い)キープアライブメッセージを使用してください。

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構成オプションは、RADOS Gateway用のCeph構成ファイルで組み込みWebサーバに渡すことができます。各オプションにはデフォルト値があります。値が指定されていない場合、デフォルト値は空になります。

オプション説明デフォルト

エンドポイントssl_endpoint

リスニングアドレスをaddress[:port]という形式で設定します。address は、ドット付き10進法による IPv4 アドレス文字列、または角括弧で囲まれた16進法による IPv6 アドレスです。オプションのポートのデフォルトは、エンドポイント80ssl_endpoint443です。endpoint=[::1] endpoint=192.168.0.100:8000 のように、複数回指定することができます。

EMPTY

ssl_certificate

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

EMPTY

ssl_private_key

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

EMPTY

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にワイルドカードを追加する

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

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

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

例えば、以下のように。

address=/.gateway-node1/192.168.122.75

バインドの場合は、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.{ホスト名}。

例えば、以下のように。

ping mybucket.gateway-node1

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

最後に、Ceph構成ファイルの適切な[client.rgw.{instance}]セクションで、rgw_dns_name = {hostname}の設定を使用して、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に存在します。

ログとデバッグの一般的な詳細については、以下を参照してください。 Logging Configuration Referenceの章を参照してください。Configuration Guide for Red Hat Ceph Storage 3.Ceph Object Gatewayに固有のロギングの詳細については、本ガイドの の章の The Ceph Object GatewayこのガイドのLogging Configuration Reference の章のセクションを参照してください。

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オブジェクト暗号化をサポートしていません。

重要

暗号化を使用するには、クライアントのリクエストMUST 、SSL接続でリクエストを送信します。Red Hatは、Ceph Object GatewayがSSLを使用しない限り、クライアントからのS3暗号化をサポートしません。ただし、テスト目的の場合、管理者は、実行時にrgw_crypt_require_ssl構成設定をfalseに設定したり、Ceph構成ファイルでfalseに設定してゲートウェイインスタンスを再起動したり、Ansible構成ファイルでfalseに設定してCeph Object Gateway用のAnsibleプレイブックを再生したりすることで、テスト中に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_keysecret_keyの値にJSONのエスケープ文字が含まれていないことを確認してください。これらの値はアクセス検証に必要ですが、クライアントによってはJSONエスケープ文字が含まれていると処理できない場合があります。この問題を解決するには、次のいずれかの操作を行ってください。

    • JSONのエスケープ文字を削除します。
    • 文字列を引用符でカプセル化します。
    • キーを再生成し、キーにJSONのエスケープ文字が含まれていないことを確認します。
    • キーとシークレットを手動で指定します。

    フォワードスラッシュの/は有効な文字なので削除しないでください。

2.10.2. Swiftユーザーの作成

Swiftのインターフェースをテストするには、Swiftのサブユーザーを作成します。Swiftユーザーの作成は、2つのステップで行われます。最初のステップは、ユーザーを作成することです。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_idaws_secret_access_keyの値は、radosgw_adminコマンドが返すaccess_keysecret_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となります。hostの設定がDNSで解決することを確認してください。<port>をゲートウェイのポート番号に置き換えてください。
    2. accesssecretを、「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 -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

と出力されるはずです。

マイニューバケット

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サーバーでHTTPSを終了させ、HAProxyサーバーとCivetwebゲートウェイインスタンスの間でHTTPを使用することができます。

2.11.1. HAProxy/keepalived 前提条件

Ceph Object GatewayでHA Proxyを設定するには、以下が必要です。

  • 稼働中のCephクラスタ
  • 同じゾーン内の少なくとも2台のCeph Object Gatewayサーバがポート80で実行するように構成されていること。シンプルなインストール手順に従った場合、ゲートウェイインスタンスはデフォルトで同じゾーングループとゾーンにあります。連携型アーキテクチャを使用している場合は、インスタンスが同じゾーングループとゾーンにあることを確認してください。
  • HAProxyとkeepalivedのために少なくとも2つのサーバーを用意すること。
注記

このセクションでは、少なくとも2台のCeph Object Gatewayサーバが稼働しており、ポート80を介してテストスクリプトを実行すると、それぞれのサーバから有効な応答が得られることを前提としています。

HAProxyとkeepalivedについての詳しい説明は、「Load Balancer Administration」を参照してください。

2.11.2. HAProxyノードの準備

以下のセットアップでは、haproxyおよびhaproxy2という名前の2つのHAProxyノードと、rgw1およびrgw2という名前の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. haproxyのSELinuxとHTTPの設定を行います。

    [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で、haproxy-http.xmlファイルに正しいSELinuxのコンテキストとファイルパーミッションを割り当てます。

    [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で、haproxy-https.xmlファイルに正しいSELinuxのコンテキストとファイルパーミッションを割り当てます。

    # cd /etc/firewalld/services
    # restorecon haproxy-https.xml
    # chmod 640 haproxy-https.xml
  4. HTTPSを使用する場合は、SSL用の鍵を生成します。証明書を持っていない場合は、自己署名証明書を使用することができます。鍵を生成するには、Red Hat Enterprise Linux 7 の にある Generating a New Key and Certificateのセクションを参照してください。System Administrator’s Guide for 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

    globaldefaultsは変更しなくてもよい。defaultsセクションの後、frontendbackendセクションを設定する必要があります。例えば、以下のようになります。

    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サーバを設定しますが、コンテンツが動的に変更されない場合、リソースを非効率的に使用する可能性があります。Ceph Object Gatewayでは、PHP、サーブレット、データベース、nodejsなどのサーバーサイドサービスを使用していない静的なWebサイトをS3バケットでホスティングできます。この方法は、サイトごとにWebサーバを搭載したVMをセットアップするよりも大幅に経済的です。

2.12.1. 静的ウェブホスティングの前提条件

静的なWebホスティングには、少なくとも1つの稼働中のCeph Storage Clusterと、静的なWebサイト用の少なくとも2つのCeph Object Gatewayインスタンスが必要です。Red Hatは、各ゾーンにHAProxy/keepalivedでロードバランスされた複数のゲートウェイインスタンスがあることを想定しています。

HAProxy/keepalivedについての詳細は、「HAProxy/keepalivedの設定」を参照してください。

注記

Red HatDOES NOT は、Ceph Object Gatewayインスタンスを使用して、標準的なS3/Swift APIと静的なWebホスティングの両方を同時に展開することをサポートしています。

2.12.2. 静的ウェブホスティングの要件

静的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ホスティング用のゲートウェイを有効にするには、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にしなければなりません(MUST)。rgw_enable_apis設定は、s3websiteAPIを有効にしなければなりません(MUST)。rgw_dns_nameおよびrgw_dns_s3website_nameの設定は、完全修飾ドメインを提供しなければなりません。サイトがcanonical name extensionsを使用する場合は、rgw_resolve_cnametrueに設定します。

重要

rgw_dns_namergw_dns_s3website_nameのFQDNMUST NOT が重なっています。

2.12.4. 静的ウェブホスティングのDNS設定

以下は想定されるDNS設定の例で、最初の2行は標準的なS3インターフェイスを使用するゲートウェイインスタンスのドメインを指定し、それぞれIPv4とIPv6のアドレスを指している。3行目は、canonical name extensionsを使用するS3バケットのワイルドカードCNAME設定を行う。4行目と5行目は、S3ウェブサイトのインターフェイスを使用するゲートウェイインスタンスのドメインを指定し、それぞれ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
注記

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

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

Amazon Web Service (AWS)では、静的なWebホストバケットをホスト名と一致させる必要があります。Cephには、DNSを設定するためのいくつかの異なる方法が用意されていてHTTPS will work if the proxy has a matching certificate.

サブドメインのバケットにホスト名をつける

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

CNAMEによるロングバケットへのホスト名

AWSは通常、バケット名がドメイン名と一致することを要求します。CNAMEを使用して静的なウェブホスティングのDNSを設定するには、DNSエントリは以下のようになります。

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

バケットへのアクセスは以下の手順で行います。

http://www.example.com

CNAMEなしのロングバケットへのホスト名

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. 静的ウェブホスティングサイトの作成

静的ウェブサイトを作成するには、以下の手順を実行します。

  1. S3バケットを作成します。バケット名は、ウェブサイトのドメイン名と同じにしてもよい(MAY)。たとえば、mysite.comの場合、バケット名はmysite.comにすることができます。これは、AWSでは必要ですが、Cephでは必要ありません。詳細は「DNS設定」を参照してください。
  2. 静的ウェブサイトのコンテンツをバケットにアップロードします。コンテンツには、HTML、CSS、クライアントサイドの JavaScript、画像、オーディオ/ビデオコンテンツ、その他のダウンロード可能なファイルが含まれます。ウェブサイトは、index.htmlファイルを持たなければならず(MUST)、error.htmlファイルを持ってもよい(MAY)とされています。
  3. ウェブサイトのコンテンツを確認します。この時点では、バケットの作成者のみがコンテンツにアクセスできます。
  4. ファイルのパーミッションを設定して、一般に読めるようにします。

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

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

注記

NFSガネーシャ機能は、一般的な使用ではなく、S3クラウドへの移行のみを目的としています。

この実装は、UNIXスタイルのパス名をS3バケットとオブジェクトにマッピングするAmazon Web Services (AWS)の階層的な名前空間の規約に準拠しています。付属の名前空間の最上位レベルは、NFSv4疑似ルートが存在する場合はその下位で、Ceph Object GatewayのS3バケットで構成され、バケットはNFSディレクトリとして表現されます。バケット内のオブジェクトは、S3の規約に従って、NFSファイルおよびディレクトリ階層として表示されます。ファイルやディレクトリを作成する操作がサポートされています。

注記

ハードリンクやソフトリンクの作成や削除はサポートされていません。バケットやディレクトリの名前変更はNFSではサポートされていませんが、ディレクトリ内やディレクトリ間、ファイルシステムとNFSマウントの間でのファイルの名前変更はサポートされています。ファイルの名前変更操作は、NFS経由で行うと、対象となるディレクトリが変更され、通常はそのディレクトリを更新するために完全なreaddirが必要となるため、よりコストがかかります。

注記

NFSマウントによるファイルの編集はサポートされていません。

注記

Ceph Object Gatewayでは、アプリケーションがオフセット0からファイルの最後まで順番に書き込む必要があります。順不同で書き込もうとすると、アップロード操作が失敗します。この問題を回避するには、NFS空間にファイルをコピーするときに、cpcatrsyncなどのユーティリティを使用します。常にsyncオプションを付けてマウントしてください。

Ceph Object Gateway with NFSは、Gatewayサーバのプロセス内ライブラリパッケージと、NFS-Ganesha NFSサーバのFile System Abstraction Layer (FSAL)名前空間ドライバをベースにしています。実行時には、Ceph Object Gatewayデーモン with NFSのインスタンスは、Civetweb HTTPサービスを含まない完全なCeph Object Gatewayデーモンと、NFS-Ganeshaインスタンスを1つのプロセスで組み合わせます。この機能を使用するには、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インスタンスが実行中の場合、NFS-Ganeshaは起動しません。
  2. root のように、Red Hat Ceph Storage 3 Toolsリポジトリを有効にします。

    # subscription-manager repos --enable=rhel-7-server-rhceph-3-tools-rpms
  3. rpcbindサービスが動作していることを確認します。

    # systemctl start rpcbind
    注記

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

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

  4. nfs-serviceサービスが動作している場合は、停止して無効にしてください。

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

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

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

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

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

    Ceph構成ファイルには、有効な[client.rgw.{instance-name}]セクションと、rgw_datakeyring、またはrgw_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オプションは、ガネーシャにエクスポートの場所を指示します。VFS FSALの場合は、サーバーのネームスペース内の場所となります。他のFSALの場合は、そのFSALの名前空間で管理されているファイルシステム内の場所になります。たとえば、Ceph FSALがCephFSボリューム全体のエクスポートに使用されている場合、Path/になります。

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

    NFSv3をサポートする必要があるEXPORTブロックは、NFS_Protocols設定にバージョン3を含める必要があります。さらに、NFSv3はUDPトランスポートをサポートする最後のメジャーバージョンです。規格の初期バージョンではUDPが含まれていましたが、RFC 7530ではその使用が禁止されています。UDPを有効にするには、Transport_Protocols設定にUDPを含めます。例えば、以下のようになります。

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

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

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

    従来のOSネイティブのNFS 4.1クライアントを使用するNFSクライアントには、通常、宛先サーバのpseudofsルートで定義されたエクスポートされたファイルシステムの統合された名前空間が表示されます。これらのうちのいくつかはCeph Object Gatewayのエクスポートにすることができます。

    各エクスポートは、名前User_IdAccess_KeySecret_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クライアントの設定

名前空間にアクセスするには、構成されたNFS-Ganeshaのエクスポートを、ローカルのPOSIX名前空間の任意の場所にマウントします。前述のとおり、この実装にはいくつかの独自の制限があります。

  • NFS 4.1以降のプロトコルフレーバーのみサポートしています。
  • 書き込み順序を強制するには、syncmountオプションを使用します。

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 の Storage Administration Guide のNetwork File System (NFS)の章を参照してください。

NFSv3クライアントの設定

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

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

マウントでバージョン3のUDPを使用する場合は、NFS GaneshaEXPORTブロックの「プロトコル」設定をバージョン3に、「トランスポート」設定をUDPに設定します。

NFSv3では、クライアントのOPENおよびCLOSE操作がファイルサーバに伝達されないため、RGW NFSでは、これらの操作をファイルのアップロードトランザクションの開始および終了の印として使用することができません。代わりに、RGW NFSは、オフセット0のファイルに最初の書き込みが送信されたときに新しいアップロードを開始しようとし、ファイルへの新しい書き込みが一定時間(デフォルトでは10秒)見られなくなったときにアップロードを確定します。この値を変更するには、Ceph構成ファイルのRGWセクションでrgw_nfs_write_completion_interval_sの値を設定します。

第3章 アドミニストレーション

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

3.1. 管理データの保存

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

  • .rgw.root
  • .default.rgw.control
  • .default.rgw.meta
  • .default.rgw.log
  • .default.rgw.buckets.index
  • .default.rgw.buckets.data
  • .default.rgw.buckets.non-ec

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

配置グループの計算の詳細については、「プールごとのCeph配置グループ(PG)計算機」も参照してください。mon_pg_warn_max_per_osd設定では、プールに割り当てる配置グループの数が多すぎると警告されます(デフォルトでは300など)。ニーズやハードウェアの性能に合わせて値を調整することができます。

mon_pg_warn_max_per_osd = n

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

Ceph Object Gatewayは、プレースメントターゲットを特定し、プレースメントターゲットに関連付けられたプールにバケットとオブジェクトを格納することで、クライアントのバケットとオブジェクトのデータを格納します。インスタンスのゾーン構成で配置ターゲットを構成してプールにマッピングしないと、Ceph Object Gatewayはdefault_placementなどのデフォルトのターゲットとプールを使用します。

ストレージポリシーは、Ceph Object Gatewayクライアントがストレージ戦略にアクセスする方法、つまり、SSD、SASドライブ、SATAドライブなど、特定の種類のストレージを対象とする機能を提供します。耐久性、レプリケーション、消去コーディングなどを確保する特定の方法です。詳細については Storage StrategiesRed Hat Ceph Storage 3 のガイドを参照してください。

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

  1. 目的のストレージ戦略を持つ新しいプール.rgw.buckets.specialを作成します。たとえば、消去コード、特定のCRUSHルールセット、レプリカの数、およびpg_numpgp_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

    スペシャル・プレースメント・エントリーは、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. zone.jsonを修正して、新しいプレースメントターゲットを追加するか、既存のターゲットを修正して、"index_type"を追加してください。1などに変更します。

    "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. 新しいプレースメントターゲットを作成した場合は、ゾーングループが新しいプレースメントターゲットを参照していることを確認してください。

    $ radosgw-admin zonegroup get --rgw-zonegroup=<zonegroup> > zonegroup.json
  5. zonegroupの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オブジェクトバージョニングを使用することは推奨されません。

注記

インデックスレスバケットを使用すると、1つのバケットに入れるオブジェクトの最大数の制限がなくなります。

注記

インデックスレスバケット内のオブジェクトをNFSからリストアップできない

3.4. バケットシャーディングの設定

Ceph Object Gatewayは、バケットのインデックスデータをインデックスプール(index_pool)に格納します。インデックスプールのデフォルトは.rgw.buckets.indexです。バケットごとの最大オブジェクト数のクォータを設定せずに、クライアントが数十万から数百万のオブジェクトを1つのバケットに入れると、インデックスプールのパフォーマンスが著しく低下します。

Bucket index sharding バケットあたりのオブジェクト数が多い場合、パフォーマンスのボトルネックを防ぐことができます。

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

バケット・インデックス・シャーディングを設定するには

バケツを再利用するために

3.4.1. バケットシャーディングの限界

重要

以下の制限事項には注意してください。ハードウェアの選択に関連する意味合いがありますので、これらの要件については常に Red Hat アカウントチームと相談してください。

  • Maximum number of objects in one bucket before it needs sharding: Red Hatでは、バケットインデックスシャードあたり最大102,400個のオブジェクトを推奨しています。シャーディングを最大限に活用するには、Ceph Object Gatewayのバケットインデックスプールに十分な数のOSDを用意して、最大の並列性を得るようにします。
  • Maximum number of objects when using sharding: 事前のテストによると、現在サポートされているバケットインデックスシャードの数は 65521 です。Red Hat の品質保証では、バケットシャーディングの完全なスケーラビリティテストは行っていません。

3.4.2. シンプルな構成でのバケット・インデックス・シャーディングの設定

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

  • 0に設定すると、バケットインデックスのシャーディングを無効にします。これがデフォルト値です。
  • バケットシャーディングを有効にし、シャーディングの最大数を設定するには、0より大きな値を指定します。

前提条件

手順

  1. 推奨されるシャドウの数を計算します。そのためには、以下の式を使用してください。

    バケツの中に入っている物体の数 / 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を再起動します。

    # systemctl restart ceph-radosgw.target

3.4.3. マルチサイト構成でのバケットインデックスシャーディングの設定

マルチサイト構成では、フェイルオーバーを管理するために、各ゾーンが異なるindex_pool設定を持つことができます。1つのゾーングループ内のゾーンに一貫したシャード数を設定するには、そのゾーングループの設定でrgw_override_bucket_index_max_shards設定を行います。パラメーターを設定します。

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

インデックスプール(該当する場合は各ゾーン)をSSDベースのOSDのCRUSHルールセットにマッピングすることで、バケットインデックスのパフォーマンスが向上する可能性もあります。

前提条件

手順

  1. 推奨されるシャドウの数を計算します。そのためには、以下の式を使用してください。

    バケツの中に入っている物体の数 / 100,000

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

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

    $ radosgw-admin zonegroup get > zonegroup.json
  3. zonegroup.jsonファイルで、名前の付いたゾーンごとにrgw_override_bucket_index_max_shardsの設定を行います。

    rgw_override_bucket_index_max_shards =value

    value を、前のステップで算出した推奨シャード数に置き換えてください(例)。

    rgw_override_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 はマルチサイト構成での動的なバケットリシャーディングをサポートしていません。このような構成でバケットのインデックスをリハードするには Manually Resharding Buckets with Multi-site.

前提条件

手順

  • ダイナミックなバケットインデックスのリシャーディングを行うには

    1. Ceph構成ファイルのrgw_dynamic_resharding設定を、デフォルト値であるtrueに設定します。
    2. Optional 。必要に応じて、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 --bucketBUCKET_NAME --num-shardsNUMBER

    置き換える。

    • BUCKET_NAME には、リシャールするバケットの名前が入ります。
    • NUMBER 新しいシャドウの数を表示します。

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

  • リシャーディングのキューをリストアップするために

    $ radosgw-admin reshard list
  • バケットのリシャーディング状況を確認するために

    radosgw-admin reshard status --bucketBUCKET_NAME

    置き換える。

    • BUCKET_NAME には、リシャールするバケットの名前が入ります。

    $ radosgw-admin reshard status --bucket data

    注記

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

    • ノット・リフレッシュ
    • インプログレス
  • リシャーディングキューのエントリーをすぐに処理するために。

    $ radosgw-admin reshard process
  • 保留中のバケット・リシャーディングをキャンセルするには

    radosgw-admin reshard cancel --bucketBUCKET_NAME

    置き換える。

    • BUCKET_NAME 、保留中のバケットの名前が表示されます。

    $ radosgw-admin reshard cancel --bucket data

    重要

    pending の再出荷作業のキャンセルのみ可能です。ongoing の再出荷作業をキャンセルすることはできません。

  • Red Hat Ceph Storage 3.1および以前のバージョンを使用している場合は、セクションで説明されているように、古くなったバケットエントリを削除します。 Cleaning stale instances after reshardingセクションを参照してください。

3.4.5. マニュアルバケットインデックスリシャーディング

バケットが初期設定で最適化されたものよりも大きくなってしまった場合は、radosgw-admin bucket reshardコマンドを使用して、バケットインデックスプールをリハードします。このコマンドは

  • 指定されたバケツのためのバケツインデックスオブジェクトのセットを新規に作成します。
  • これらのバケットインデックスオブジェクトにオブジェクトエントリを分散させます。
  • 新しいバケットのインスタンスを作成します。
  • 新しいバケットインスタンスとバケットをリンクし、すべての新しいインデックス操作が新しいバケットインデックスを経由するようにします。
  • 旧バケットIDと新バケットIDをコマンド出力に表示します。
重要

この手順は、シンプルな構成の場合にのみ使用してください。マルチサイト構成でバケットをリハードするには Manually Resharding Buckets with Multi-site.

前提条件

手順

  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 新しいシャドーの数で

    例えば、データという名前のバケットで、必要なシャード数が100の場合、次のように入力します。

    $ radosgw-admin bucket reshard --bucket=data --num-shards=100
  3. Red Hat Ceph Storage 3.1および以前のバージョンを使用している場合は、セクションで説明されているように、古くなったバケットエントリを削除します。 Cleaning stale instances after reshardingセクションを参照してください。

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です。サポートされています。
  • スナッピーテクノロジープレビュー。
  • zstd: テクノロジープレビュー。
注記

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

構成

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

各圧縮オブジェクトには、圧縮タイプが保存されます。この設定を変更しても、既存の圧縮オブジェクトを解凍する機能が妨げられることはなく、Ceph Object Gatewayが既存のオブジェクトを再圧縮することもありません。

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

ゾーンの配置ターゲットの圧縮を無効にするには、radosgw-admin zone placement modifyコマンドに--compression=<type>オプションを指定し、空の文字列または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 for Productionガイド、より具体的には Creating a Realmセクションを最初に参照してください。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 Storage ClusterのクライアントアプリケーションとしてのCeph Object Gatewayではありません。クライアントアプリケーションがCeph Object Gatewayサービスとやり取りできるようにするには、ユーザ、アクセスキー、シークレットを作成する必要があります。

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

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

ユーザーやサブユーザーの作成、変更、表示、停止、削除が可能です。

重要

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

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

ユーザー管理のコマンドライン構文は、一般的に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 APIとSwift APIの両方でマルチテナントをサポートしており、各ユーザーとバケットが1つの "tenant."の下に置かれます。マルチテナンシーは、複数のテナントが共通のバケット名を使用する際の名前空間の衝突を防ぎます。

それぞれのユーザーとバケットは、1つのテナントの下に存在します。後方互換性のために、空の名前を持つ ˶ˆ꒳ˆ˵ ) テナントが追加されます。特にテナントを指定せずにバケットを参照する場合、Swift API は ″Legacy″ テナントを想定します。既存のユーザーもレガシーテナントの下に保存されるため、以前のリリースと同じ方法でバケットやオブジェクトにアクセスできます。

このようなテナントには、何の操作もありません。ユーザーが管理されるときに、必要に応じて現れたり消えたりします。明示的なテナントを持つユーザーを作成、変更、削除するには、--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. ユーザーの作成

S3-interfaceのユーザーを作成するには、user createコマンドを使用します。ユーザーIDと表示名を指定しなければなりません。また、電子メールアドレスを指定することもできます。キーやシークレットを指定しない場合は、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、サブユーザーのアクセスレベルを指定する必要があります。キーやシークレットを指定しない場合は、radosgw-adminが自動的に生成します。ただし、生成されたキー/シークレットペアを使用したくない場合は、キーやシークレットを指定することができます。

注記

fullは、アクセスコントロールポリシーも含まれているため、リードライトではありません。

[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. ユーザー情報の取得

あるユーザーの情報を取得するには、ユーザー情報とユーザー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: --purge-dataオプションは、UID に関連するすべてのデータをパージします。
  • Purge Keys: --purge-keysオプションは、UID に関連するすべてのキーをパージします。

3.6.8. サブユーザーの削除

サブユーザーを削除すると、Swiftインターフェースへのアクセスを削除することになります。ユーザーはシステムに残ります。The 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アクセス
  • Ceph Object Gatewayのインストール

手順

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

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

    例えば、user1の名前をuser2に変更する場合。

    # 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

    例えば、テストテナント内で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 ユーザー情報 --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

追加リソース

  • スクリーン(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> specifies a secret key (e.g,. manually generated).
  • --gen-access-keyは、ランダムなアクセスキー(デフォルトではS3ユーザー用)を生成します。
  • --gen-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を提供します。デフォルトでは、ユーザはこの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オプションは、クォータのスコープを設定します。オプションは、バケットユーザーです。バケットクォータは、ユーザーが所有するバケットに適用されます。ユーザークォータは、あるユーザーに適用されます。
重要

バケットに大量のオブジェクトがあると、パフォーマンスに重大な問題が生じる可能性があります。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 objectsおよび/またはmax sizeに負の値を設定すると、特定のクォータ属性のチェックが無効になります。

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 objectsおよび/またはmax sizeに負の値を設定すると、特定のクォータ属性のチェックが無効になります。

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バケットクォータttlrgwユーザクォータバケット同期間隔、およびrgwユーザクォータ同期間隔です。これらの値が高ければ高いほど、クォータ操作の効率は上がりますが、複数のインスタンスの同期が取れなくなります。これらの値が低ければ低いほど、複数のインスタンスが完全な実施に近づきます。3つの値がすべて0の場合、クォータキャッシュは実質的に無効となり、複数のインスタンスは完璧なクォータエンフォースメントを実現します。これらのオプションの詳細については、4章コンフィギュレーション・リファレンス を参照してください。

3.7.9. グローバルクオータの読み方・書き方

クォータ設定は、zonegroupマップで読み書きできます。zonegroupマップを取得するには。

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

グローバルクォータの設定は、例えば、quota setquota enablequota disableコマンドのグローバルクォータ対応版で操作できます。

[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 Gatewaysを再起動する必要があります。

3.8. 使用方法

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

オプションは以下の通りです。

  • Start Date: --start-dateオプションは、特定の開始日(format: yyyy-mm-dd[HH:MM:SS])からの使用統計をフィルタリングすることができます。
  • End Date: --end-dateオプションは、特定の日付までの使用状況をフィルタリングすることができます(format: yyyy-mm-dd[HH:MM:SS])。
  • Log Entries: --show-log-entriesオプションでは、使用状況の統計にログエントリを含めるかどうかを指定できます(オプション:truefalse)。
注記

時間は分と秒で指定することができますが、1時間の分解能で保存されます。

3.8.1. 使用方法の表示

使用量の統計を表示するには、use 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. オーファン・オブジェクトの発見

通常、健全なストレージクラスタでは、リークオブジェクトは発生しないはずですが、場合によってはリークオブジェクトが発生することがあります。例えば、RADOSゲートウェイが操作の途中でダウンした場合、これによって一部の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のバケットユーティリティーは、ユーザー間でバケットを移動する機能を提供します。これを行うには、バケットを新しいユーザーにリンクし、バケットの所有権を新しいユーザーに変更します。

バケットを動かすことができます。

3.9.1.1. 前提条件

  • 稼働中のRed Hat Ceph Storageクラスター
  • Ceph Object Gatewayがインストールされている
  • Aバケット
  • テナント、ノンテナントの様々なユーザー

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

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

手順

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

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

    Replace:

    • user には、バケットをリンクするユーザーのユーザー名が入ります。
    • bucket バケツの名前で

    例えば、データバケットを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

    Replace:

    • user に、バケットの所有権を変更するユーザー名を入力します。
    • bucket バケツの名前で

    例えば、データバケットのオーナーシップをuser2に変更する場合。

    # radosgw-admin bucket chown --uid=user2 --bucket=data
  4. データバケットのオーナーシップが正常に変更されたことを、以下のコマンドの出力のowner行で確認します。

    # radosgw-admin bucket list --bucket=data

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

テナントのユーザー間でバケットを移動することができます。

手順

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

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

    Replace

    • current-tenant には、バケットが属するテナントの名前が入ります。
    • bucket 、リンクするバケットの名前を入れて
    • new-tenant には、新しいユーザーがいるテナントの名前が入ります。
    • user 新しいユーザーのユーザー名で

    例えば、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

    Replace:

    • bucket 、リンクするバケットの名前を入れて
    • new-tenant には、新しいユーザーがいるテナントの名前が入ります。
    • user 新しいユーザーのユーザー名で

    例えば、データバケットの所有権をtest2テナント内のuser2に変更する場合です。

    # radosgw-admin bucket chown --bucket='test2/data' --uid='test$tuser2'
  4. データバケットのオーナーシップが正常に変更されたことを、以下のコマンドの出力のowner行で確認します。

    # 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コマンドのいずれかを使用して、eternalテナントからCeph Object Gatewayにアクセスします。

    # swift list

    またはs3cmdを使う。

    # s3cmd ls

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

  2. テナントのユーザーにバケットを移動させる。

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

    Replace

    • bucket バケツの名前で
    • tenant には、新しいユーザーがいるテナントの名前が入ります。
    • user 新しいユーザーのユーザー名で

    例えば、データバケットをテストテナント内のtenanted-userに移動させる場合などです。

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

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

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

    Replace

    • bucket バケツの名前で
    • tenant には、新しいユーザーがいるテナントの名前が入ります。
    • user 新しいユーザーのユーザー名で

    例えば、データバケットの所有権をテストテナント内のtenanted-userに変更する場合などです。

    # radosgw-admin bucket chown --bucket='test/data' --uid='test$tenanted-user'
  5. データバケットのオーナーシップが正常に変更されたことを、以下のコマンドの出力のowner行で確認します。

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

3.9.2. バケットの名称変更

バケットの名前を変更することができます。

前提条件

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

手順

  1. バケットをリストアップします。

    radosgw-adminのバケットリスト

    例えば、出力されたバケツを見てみましょう。

    # 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のバケットリスト

    例えば、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. 追加リソース

第4章 コンフィギュレーション・リファレンス

以下の設定は、Cephの設定ファイル、つまり通常はceph.conf[client.rgw.<instance_name>]セクションに追加することができます。各設定にはデフォルト値が含まれている場合があります。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のキャッシュが有効であるかどうか。

ブーリアン

rgw_cache_lru_size

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

整数

10000

rgw_socket_path

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

ストリング

N/A

rgw_host

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

ストリング

0.0.0.0

rgw_port

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

ストリング

なし

rgw_dns_name

サービスを受けるドメインのDNS名です。ゾーングループ内のホスト名の設定も参照してください。

ストリング

なし

rgw_script_uri

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

ストリング

なし

rgw_request_uri

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

ストリング

なし

rgw_print_continue

動作可能であれば、100-continueを有効にします。

ブーリアン

rgw_remote_addr_param

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

ストリング

REMOTE_ADDR

rgw_op_thread_timeout

開いているスレッドのタイムアウトを秒単位で指定します。

整数

600

rgw_op_thread_suicide_timeout

Ceph Object Gatewayプロセスが死ぬまでのタイムアウトを秒単位で指定します。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名と等しくない場合)。

ブーリアン

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

1つのオブジェクトリクエストのウィンドウサイズ(バイト)です。

整数

16 << 20

rgw_get_obj_max_req_size

Ceph Storage Clusterに送信される1つのget操作の最大リクエストサイズ。

整数

4 << 20

rgw_relaxed_s3_bucket_names

ゾーングループバケットのリラックスしたS3バケット名ルールを有効にします。

ブーリアン

rgw_list buckets_max_chunk

ユーザーのバケットをリストアップする際に、1回の操作で取得するバケットの最大数を指定します。

整数

1000

rgw_override_bucket_index_max_shards

バケット・インデックス・オブジェクトのシャードの数。値が0の場合はシャーディングがないことを示します。Red Hat は、バケット一覧のコストが増加するため、あまり大きな値 (たとえば1000) を設定することを推奨しません。

この変数は、[client]または[global]セクションで設定することで、radosgw-adminコマンドに自動的に適用されます。

整数

0

rgw_num_zone_opstate_shards

オゾングループ間のコピー進捗情報を保持するための最大シャード数です。

整数

128

rgw_opstate_ratelimit_sec

1回のアップロードでオプステートを更新する際の最小時間。0は、ラテラルリミットを無効にします。

整数

30

rgw_curl_wait_timeout_ms

特定のcurlコールのタイムアウトをミリ秒単位で指定します。

整数

1000

rgw_copy_obj_progress

ロングコピー時のオブジェクトプログレスの出力を有効にします。

ブーリアン

rgw_copy_obj_progress_every_bytes

コピープログレス出力間の最小バイト数です。

整数

1024 * 1024

rgw_admin_entry

管理者用リクエストURLのエントリーポイントです。

ストリング

admin

rgw_content_length_compat

CONTENT_LENGTHとHTTP_CONTENT_LENGTHの両方が設定されたFCGIリクエストの互換性処理を有効にする。

ブーリアン

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 Clusterプールにマッピングされます。

Manually Created Pools vs. Generated Pools

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

本番システムをセットアップするには、Red Hat Ceph Storage 3の Ceph Object Gateway for Productionのガイドを参照してください。ストレージ戦略については Developing Storage Strategies Ceph Object Gateway for Production ガイドのセクションを参照してください。

Ceph Object Gatewayのデフォルトゾーンには、以下のようなプールがあります。

  • .rgw.root
  • .default.rgw.control
  • .default.rgw.meta
  • .default.rgw.log
  • .default.rgw.buckets.index
  • .default.rgw.buckets.data
  • .default.rgw.buckets.non-ec

Ceph Object Gatewayは、ゾーンごとにプールを作成します。プールを手動で作成する場合は、ゾーン名を前置します。システムプールは、システム制御、ログ、ユーザ情報などに関連するオブジェクトを格納します。慣習上、これらのプール名には、プール名の前にゾーン名が付いています。

  • .<zone-name>.rgw.control:コントロールプールのこと。
  • .<zone-name>.log: ログプールには、すべてのバケット/コンテナとオブジェクトのアクション(create、read、update、deleteなど)のログが含まれています。
  • .<zone-name>.rgw.buckets.index:このプールには、バケットのインデックスが格納されます。
  • .<zone-name>.rgw.buckets.data:このプールには、バケットのデータが格納されます。
  • .<zone-name>.rgw.meta: メタデータプールには、user_keysなどの重要なメタデータが保存されています。
  • .<zone-name>.meta:users.uid:ユーザーIDプールには、ユニークなユーザーIDのマップが含まれています。
  • .<zone-name>.meta:users.keys:keysプールには、各ユーザーIDのアクセスキーとシークレットキーが含まれています。
  • .<zone-name>.meta:users.email:Eメールプールには、ユーザーIDに関連付けられたEメールアドレスが含まれています。
  • .<zone-name>.meta:users.swift:Swiftプールには、ユーザーIDのSwiftサブユーザー情報が含まれています。

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

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

rgw_zonegroup_root_pool

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

ストリング

.rgw.root

rgw_zone_root_pool

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

ストリング

.rgw.root

4.3. スウィフト設定

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

rgw_enforce_swift_acls

Swiftのアクセスコントロールリスト(ACL)の設定を強制します。

ブーリアン

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).

スイフト

N/A

rgw_swift_auth_url

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

ストリング

なし

rgw_swift_auth_entry

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

ストリング

auth

4.4. ロギング設定

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

rgw_log_nonexistent_bucket

Ceph Object Gatewayが存在しないバケットへの要求をログに記録するようにします。

ブーリアン

rgw_log_object_name

オブジェクト名のロギングフォーマットです。フォーマット指定子の詳細については、manpage dateを参照してください。

日付

%Y-%m-%d-%H-%i-%n

rgw_log_object_name_utc

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

ブーリアン

rgw_usage_max_shards

使用状況を記録するシャードの最大数です。

整数

32

rgw_usage_max_user_shards

1人のユーザーの使用状況を記録するために使用されるシャードの最大数です。

整数

1

rgw_enable_ops_log

Ceph Object Gatewayの操作が成功するたびにログを有効にします。

ブーリアン

rgw_enable_usage_log

使用ログを有効にします。

ブーリアン

rgw_ops_log_rados

操作ログをCeph Storage Clusterバックエンドに書き込むかどうか。

ブーリアン

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

インテント・ログ・オブジェクト名のロギング・フォーマットです。フォーマット指定子の詳細については、manpage dateを参照してください。

日付

%Y-%m-%d-%i-%n

rgw_intent_log_object_name_utc

イ ン テ ン ト ロ グ オ ブ ジ ェ ク ト の 名 前 に テ ィ ッ ク ス タ イ ム を 含 む か ど う か 。falseの場合は、ローカル時間を使用します。

ブーリアン

rgw_data_log_window

データ・ログ・エントリ・ウィンドウを秒単位で表示します。

整数

30

rgw_data_log_changes_size

データ変更ログのために保持するメモリ内エントリの数です。

整数

1000

rgw_data_log_num_shards

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

整数

128

rgw_data_log_obj_prefix

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

ストリング

データログ

rgw_replica_log_obj_prefix

レプリカログのオブジェクト名のプレフィックスです。

ストリング

レプリカ・ログ

rgw_md_log_max_shards

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

整数

64

4.5. キーストーンの設定

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

rgw_keystone_url

KeystoneサーバーのURLです。

ストリング

なし

rgw_keystone_admin_token

Keystoneのアドミン・トークン(シェアード・シークレット)です。

ストリング

なし

rgw_keystone_accepted_roles

リクエストに応えるために必要な役割です。

ストリング

メンバー、管理者

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つのゾーングループと、1つ以上のceph-radosgwインスタンスで構成され、インスタンス間でゲートウェイクライアント要求をロードバランスすることができます。シングルゾーン構成では、通常、複数のゲートウェイインスタンスが1つのCephストレージクラスターを指します。ただし、Red HatはCeph Object Gatewayのいくつかのマルチサイト構成オプションをサポートしています。

  • Multi-zone: より高度な構成では、1つのゾーングループと複数のゾーンで構成され、各ゾーンには1つ以上のceph-radosgw インスタンスがあります。各ゾーンは、独自のCeph Storage Clusterによってバックアップされます。1つのゾーングループに複数のゾーンがあると、ゾーンの1つに重大な障害が発生した場合に、ゾーングループのディザスタリカバリが可能になります。Red Hat Ceph Storage 2以降では、各ゾーンはアクティブで、書き込み操作を受け取ることができます。ディザスタリカバリだけでなく、複数のアクティブゾーンはコンテンツ配信ネットワークの基盤としても機能します。レプリケーションなしで複数のゾーンを構成するには、「レプリケーションなしで複数のゾーンを設定する」 を参照してください。
  • Multi-zone-group: かつて「リージョン」と呼ばれていたCeph Object Gatewayは、複数のゾーングループをサポートすることもでき、各ゾーングループには1つ以上のゾーンが含まれます。同じレルム内のゾーングループに格納されたオブジェクトは、グローバルな名前空間を共有し、ゾーングループとゾーン間で一意のオブジェクトIDが確保されます。
  • Multiple Realms: Red Hat Ceph Storage 2以降では、Ceph Object Gatewayがレルムという概念をサポートしています。レルムには、単一のゾーングループ、または複数のゾーングループと、グローバルに一意な名前空間があります。複数のレルムにより、多数の構成と名前空間をサポートする機能が提供されます。
gateway realm

5.1. 要件と前提条件

マルチサイト構成では、少なくとも2つのCephストレージクラスターと、各Cephストレージクラスターに1つずつ、少なくとも2つのCeph Object Gatewayインスタンスが必要です。

このガイドでは、地理的に離れた場所に少なくとも2つのCephストレージクラスタがあることを想定していますが、この構成は同じ物理的サイトで動作させることができます。また、このガイドでは、rgw1rgw2rgw3rgw4という名前の4台のCephオブジェクトゲートウェイサーバを想定しています。

A multi-site configuration requires a master zone group and a master zone. さらに、each zone group requires a master zone. ゾーングループは、1つ以上のセカンダリーゾーンまたはノンマスターゾーンを持つことができます。

重要

レルムのマスターゾーングループ内のマスターゾーンは、ユーザー、クォータ、バケットを含む、レルムのメタデータのマスターコピーを保存する責任があります(radosgw-adminCLIで作成されます)。このメタデータは、セカンダリゾーンおよびセカンダリゾーングループに自動的に同期されます。radosgw-adminCLIMUST be executed で実行されるメタデータ操作は、セカンダリゾーングループとゾーンへの同期を確実に取るために、マスターゾーングループのマスターゾーン内のホスト上で行われます。NOT recommended 現在、セカンダリゾーンやゾーングループでメタデータ操作を実行するのはpossible ですが、WILL NOT が同期されてしまうため、メタデータが断片化されてしまうことになります。

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

5.2. プール

Red Hatでは、Ceph Placement Group's per Pool Calculatorを使用して、ceph-radosgwデーモンが作成するプールに適した数のプレースメントグループを計算することをお勧めします。計算された値をCephの設定ファイルでデフォルトとして設定します。たとえば、以下のようになります。

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

ストレージクラスタのCeph設定ファイルにこの変更を加え、その後、ゲートウェイインスタンスがプールを作成するときにこれらのデフォルトを使用するように、設定をランタイムで変更します。

また、手動でプールを作成することもできます。プールの作成については Poolsの章を参照してください。プールの作成方法については、Storage Strategies ガイドを参照してください。

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

  • .rgw.root
  • US-East.RGW.コントロール
  • us-east.rgw.meta
  • us-east.rgw.log
  • us-east.rgw.buckets.index
  • us-east.rgw.buckets.data
  • US-East.RGW.Buckets.Non-ec
  • us-east.rgw.meta:users.keys
  • us-east.rgw.meta:users.email
  • us-east.rgw.meta:users.swift
  • us-east.rgw.meta:users.uid

5.3. Object Gatewayのインストール

Ceph Object Gatewayをインストールするには、「Red Hat Ceph Storage 3 Installation Guide for Red Hat Enterprise Linux.

すべてのCeph Object Gatewayノードは、Requirements for Installing Red Hat Ceph Storage セクションに記載されているタスクに従う必要があります。

Ansibleでは、Ceph Storageクラスタで使用するCeph Object Gatewaysのインストールと設定が可能です。マルチサイトおよびマルチサイトグループの展開では、ゾーンごとにAnsibleの設定を行う必要があります。

Ceph Object GatewayをAnsibleでインストールする場合は、Ansibleプレイブックが初期設定を代行します。Ceph Object GatewayをAnsibleでインストールするには、/etc/ansible/hostsファイルにホストを追加します。Ceph Object Gatewayのホストを[rgws]セクションの下に追加して、Ansibleに対する役割を識別します。ホストがシーケンシャルに命名されている場合は、範囲を使用することができます。たとえば、以下のようになります。

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

ホストの追加が完了したら、Ansibleプレイブックを再実行します。

注記

Ansibleはゲートウェイの実行を保証するため、デフォルトのゾーンとプールを手動で削除する必要がある場合があります。このガイドでは、その手順を説明します。

既存のマルチサイトクラスターを非同期アップデートで更新する場合は、アップデートのインストール手順に従ってください。その後、ゲートウェイ・インスタンスを再起動します。

注記

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

5.4. Multisite Realmの構築

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

したがって、マルチサイトクラスタを作成する最初のステップでは、レルム、マスターゾーングループ、マスターゾーンを確立する必要があります。マルチサイト構成でゲートウェイを設定するには、レルム構成、マスターゾーングループ、マスターゾーンを保持するceph-radosgwインスタンスを選択します。

5.4.1. レルムの作成

レルムには、ゾーングループとゾーンのマルチサイト構成が含まれており、また、レルム内でグローバルにユニークな名前空間を強制する役割も果たしています。

マスターゾーングループとゾーンの役割を果たすことが確認されたホスト上で、コマンドラインインターフェイスを開いて、マルチサイト構成用の新しいレルムを作成します。その後、次のように実行します。

[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

レルムが単一のゾーン・グループしか持たない場合は、--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は指定しません。これらの設定は、次のセクションでユーザーが作成されると、ゾーンに追加されます。

重要

以下の手順は、まだデータを保存していない新規インストールのシステムを使用したマルチサイト構成を想定しています。データの保存に使用している場合は、デフォルトゾーンとそのプールを削除しないでください。

5.4.4. デフォルトのゾーングループとゾーンの削除

デフォルトゾーンが存在する場合は、それを削除します。必ず最初にデフォルトゾーングループから削除してください。

[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ストレージクラスタにデフォルトのプールがある場合は、それを削除します。

重要

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

# 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}" -システム

例えば、以下のように。

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

access_keyとsecret_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サービスを起動して有効にします。

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

サービスがすでに実行されている場合は、サービスを開始して有効にするのではなく、サービスを再起動してください。

# systemctl restart ceph-radosgw@rgw.`hostname -s`.

5.5. セカンダリーゾーンの設定

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

注記

セカンダリーゾーンを追加する場合は、セカンダリーゾーンの追加と同じ手順で行います。異なるゾーン名を使用してください。

重要

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

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、新しいゾーン名、ゾーンのエンドポイントを指定します。DO NOT には、--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
重要

以下の手順では、データを保存していない新規導入システムを使用したマルチサイト構成を想定しています。DO NOT DELETE デフォルトゾーンとそのプールをすでにデータの保存に使用している場合は、データが失われて回復できなくなりますのでご注意ください。

必要に応じて、デフォルトゾーンを削除してください。

[root@second-zone]# radosgw-admin zone delete --rgw-zone=default

最後に、必要に応じて、Cephストレージクラスタのデフォルトプールを削除します。

# 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サービスを起動して有効にします。

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

サービスがすでに実行されている場合は、サービスを開始して有効にするのではなく、サービスを再起動してください。

# 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を再起動します。

    # 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を再起動します。

    # 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を再起動します。

    # systemctl restart ceph-radosgw@rgw.`hostname -s`.

5.7. シングルサイトシステムからマルチサイトへの移行

デフォルトのゾーングループとゾーンを持つシングルサイトシステムからマルチサイトシステムに移行するには、以下の手順で行います。

  1. レルムを作成します。<name>をレルム名に置き換えてください。

    [root@master-zone]# radosgw-admin realm create --rgw-realm=<name> --default
  2. デフォルトのゾーンおよびゾーネグループの名前を変更します。<name>をzonegroupまたはゾーン名に置き換えてください。

    [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>をzonegroup内の完全修飾ドメイン名に置き換えてください。

    [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を再起動します。

    # systemctl restart ceph-radosgw@rgw.`hostname -s`.

この手順が完了したら、「セカンダリーゾーンの確立」に進み、マスターゾーングループにセカンダリーゾーンを作成します。

5.8. Multisiteコマンドライン使用法

5.8.1. レルム

レルムは、1つまたは複数のゾーンを含む1つまたは複数のゾーングループ、およびバケットを含むゾーン、さらにバケットにはオブジェクトが含まれている、グローバルに一意な名前空間を表します。レルムを使用すると、Ceph Object Gatewayは、同じハードウェア上で複数の名前空間とその構成をサポートできます。

レルムにはピリオドという概念があります。それぞれのピリオドは、ゾーングループとゾーンの設定の状態を表しています。ゾーングループやゾーンに変更を加えるたびに、ピリオドを更新してコミットします。

デフォルトでは、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つだけでよい。レルムが1つしかなく、作成時にデフォルトのレルムとして指定されていなかった場合は、そのレルムをデフォルトのレルムにします。あるいは、どのレルムをデフォルトとするかを変更するには、次のように実行します。

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

realmがdefaultの場合、コマンドラインでは引数として--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を取得するには、realm getを実行し、realm名を指定します。

# radosgw-admin realm get --rgw-realm=<name>

例えば、以下のように。

# radosgw-admin realm get --rgw-realm=movies [> filename.json]

CLIは、レルムのプロパティを含むJSONオブジェクトをエコーします。

{
    "id": "0a68d52e-a19c-4e8e-b012-a8f831cb3ebc",
    "name": "movies",
    "current_period": "b0c5bbef-4337-4edd-8184-5aeab2ec413b",
    "epoch": 1
}

>と出力ファイル名を使用して、JSONオブジェクトをファイルに出力します。

5.8.1.5. レルムの設定

realmを設定するには、realm setを実行し、realm名を指定し、--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の一覧を表示するには、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では引き出されません。複数のゾーンを持つレルムの名前を変更する場合run the command on each zone. レルムの名前を変更するには、次のように実行します。

# 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 zonegroupoperationsMAY レルム内のどのホストでも実行できますが、これは期間を更新するステップで変更がクラスター全体に伝搬されるためです。しかし、radosgw-admin zoneoperationsMUST は、ゾーン内のホストで実行されます。

5.8.2.1. ゾーングループの作成

ゾーン・グループの作成は、ゾーン・グループ名の指定から始まります。ゾーンを作成すると、--rgw-realm=<realm-name>が指定されていない限り、デフォルトのレルムに住むことを想定します。zonegroupがデフォルトのzonegroupの場合、--defaultフラグを指定します。zonegroupがmaster zonegroupの場合は、--masterフラグを指定します。たとえば、以下のようになります。

# radosgw-admin zonegroup create --rgw-zonegroup=<name> [--rgw-realm=<name>][--master] [--default]
注記

既存のゾーングループの設定を変更するには、zonegroup modify --rgw-zonegroup=<zonegroup-name>を使用します。

5.8.2.2. あるゾーングループをデフォルトにする

zonegroups のリストの中の 1 つの zonegroup をデフォルト zonegroup とします。デフォルトのZonegroupは1つだけでよい。zonegroupが1つしかなく、作成時にデフォルトのzonegroupとして指定されていなかった場合、それをデフォルトのzonegroupにします。また、どのゾーングループをデフォルトとするかを変更するには、次のように実行します。

# radosgw-admin zonegroup default --rgw-zonegroup=comedy
注記

When the zonegroup is default, the command line assumes --rgw-zonegroup=<zonegroup-name> as an argument.

その後、期間を更新します。

# radosgw-admin period update --commit

5.8.2.3. ゾーングループへのゾーンの追加

zonegroupにゾーンを追加するには、MUST ゾーンに入るホストでこのステップを実行します。ゾーンをゾーネグループに追加するには、次のように実行します。

# radosgw-admin zonegroup add --rgw-zonegroup=<name> --rgw-zone=<name>

その後、期間を更新します。

# radosgw-admin period update --commit

5.8.2.4. ゾーングループからのゾーンの削除

ゾーングループからゾーンを削除するには、次のように実行します。

# 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. ゾーングループの削除

ゾーングループを削除するには、次のように実行します。

# 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ゾーン・グループがマスター・ゾーン・グループであるかどうかを決定します。必須です。note: マスターゾーングループは1つしかありません。
  4. エンドポイントゾーングループ内のすべてのエンドポイントのリストです。例えば、同じゾーングループを参照するのに、複数のドメイン名を使用することができます。その際は、フォワードスラッシュを必ずエスケープしてください※)。また、各エンドポイントにポート(fqdn:port)を指定することもできます。オプションです。
  5. hostnamesゾーングループ内のすべてのホスト名のリストです。たとえば、同じゾーングループを参照するために複数のドメイン名を使用することができます。オプションです。rgw dns nameの設定は、自動的にこのリストに含まれます。この設定を変更した後は、ゲートウェイ・デーモンを再起動する必要があります。
  6. マスターゾーン。ゾーングループのマスターゾーンです。オプションです。note: マスターゾーンは、ゾーングループごとに1つだけ設定できます。
  7. ゾーンゾーン・グループ内のすべてのゾーンのリストです。各ゾーンには、名前(必須)、エンドポイントのリスト(オプション)、ゲートウェイがメタデータやデータ操作をログに記録するかどうか(デフォルトではfalse)があります。
  8. プレースメントターゲット。プレースメントターゲットのリスト(オプション)。各プレースメントターゲットには、プレースメントターゲットの名前(必須)と、タグを持つユーザーのみがプレースメントターゲットを使用できるようにするためのタグのリスト(オプション)が含まれます(つまり、ユーザー情報のplacement_tagsフィールド)。
  9. default_placement。オブジェクトインデックスとオブジェクトデータのデフォルトの配置先。デフォルトでdefault-placementに設定されています。ユーザーごとのデフォルトの配置を、ユーザー情報で設定することもできます。

ゾーングループを設定するには、必要なフィールドで構成されたJSONオブジェクトを作成し、そのオブジェクトをファイル(例:zonegroup.json)に保存した後、以下のコマンドを実行します。

# radosgw-admin zonegroup set --infile zonegroup.json

zonegroup.jsonは、作成したJSONファイルです。

重要

デフォルトのゾーングループのis_master設定は、デフォルトでtrueです。新しいゾーングループを作成して、それをマスターゾーングループにしたい場合は、デフォルトゾーングループのis_master設定をfalseにするか、デフォルトゾーングループを削除する必要があります。

最後に、期間を更新します。

# radosgw-admin period update --commit

5.8.2.10. ゾーングループマップの設定

ゾーン・グループ・マップの設定は、1つまたは複数のゾーン・グループで構成されるJSONオブジェクトを作成し、クラスタのmaster_zonegroupを設定することで構成されます。ゾーン・グループ・マップの各ゾーン・グループはkey/valueのペアで構成され、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ゾーン操作MUST は、ゾーン内で動作する、または動作する予定のホストで実行される。

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で、クラスタ内のゾーンをリストアップするには、次のように実行します。

# radosgw-admin zone list

5.8.3.5. ゾーンの取得

ルートとして、ゾーンの設定を取得するには、次のように実行します。

# radosgw-admin zone get [--rgw-zone=<zone>] 。

デフォルトのゾーンは以下のようになっています。

{ "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]# radosgw-admin zone set --rgw-zone={zone-name} --infile zone.json

zone.jsonは、作成したJSONファイルです。

その後、ルートとして、期間を更新します。

# 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. Multisiteでバケットを手動でリシャーディングする方法

{storage-product}DOES NOT マルチサイトクラスターのダイナミックなバケットリシャーディングをサポートします。以下の手順で、マルチサイトクラスターのバケットを手動でリハードすることができます。

ノート
手動でのリシャーディングは、特に巨大なバケットの場合、非常に高価なプロセスとなります。すべてのセカンダリーゾーンは、すべてのオブジェクトを削除し、マスターゾーンから再同期させます。

前提条件

  • すべてのObject Gatewayインスタンスを停止します。

手順

  1. マスターゾーングループのマスターゾーン内のノードで、以下のコマンドを実行します。

    # radosgw-admin bucket sync disable --bucket=BUCKET_NAME

    データの同期が最新であることを報告するために、all zonessync statusを待ちます。

  2. ALL ceph-radosgwのデーモンをALL ゾーンで停止します。
  3. マスターゾーングループのマスターゾーン内のノードで、バケットをリハードします。例えば、以下のようになります。

    # radosgw-admin bucket reshard --bucket=BUCKET_NAME --num-shards=NEW_SHARDS_NUMBER
  4. EACH セカンダリーゾーンで、以下を実行します。

    # radosgw-admin bucket rm --purge-objects --bucket= です。BUCKET_NAME
  5. ALL ceph-radosgwのデーモンをALL ゾーンで再起動します。
  6. マスターゾーングループのマスターゾーン内のノードで、以下のコマンドを実行します。

    # radosgw-admin bucket sync enable --bucket=BUCKET_NAME

メタデータ同期処理では、更新されたバケットエントリポイントとバケットインスタンスのメタデータを取得します。データ同期処理では、完全な同期を行います。

5.11. レプリケーションなしで複数のゾーンを設定する

複数のゾーンを設定しても、お互いに複製されることはありません。例えば、会社の各チームに専用のゾーンを作成することができます。

前提条件

  • Ceph Object GatewayがインストールされたCeph Storage Cluster。

手順

  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_metalog_datasync_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. 同一のストレージクラスターに複数のレルムを設定する場合

ここでは、同じストレージクラスターに複数のレルムを設定する方法について説明します。これは、Multisiteのより高度なユースケースです。同じストレージクラスター内に複数のレルムを構成することで、ローカルのRGWクライアントのトラフィックを処理するためのローカルレルムと、セカンダリサイトに複製されるデータ用のレプリケートされたレルムを使用することができます。

注記

Red Hatでは、各レルムに独自のCeph Object Gatewayがあることを推奨しています。

前提条件

  • ストレージクラスターの各データセンターのアクセスキーとシークレットキーです。
  • ストレージクラスター内の2つの稼働中の{storage-product}データセンター。
  • 各データセンターには独自のローカルレルムがあります。両データセンターは、両サイトで複製されるレルムを共有しています。
  • Ceph Object Gatewayノードで、以下に記載されているタスクを実行します。 Requirements for Installing Red Hat Ceph Storage {storage-product} Installation Guide に記載されています。
  • 各Ceph Object Gatewayノードで、以下のステップ1~7を実行します。 Installing the Ceph Object Gatewayのセクションを参照してください({storage-product} Installation Guide)。

手順

  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つ目のデータセンターに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つ目のデータセンターにローカルゾーンを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.confrgw_realmrgw_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データセンターにローカルレルムを1つ作成します。

    シンタックス

    radosgw-admin realm create --rgw-realm=REALM_NAME --default

    [user@rgw2]$ radosgw-admin realm create --rgw-realm=ldc2 --default

  9. 第2データセンターに1つのローカルマスターゾーネグループを作成します。

    シンタックス

    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.confrgw_realmrgw_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. 1つ目のデータセンターにマスターゾーンを作成します。

    シンタックス

    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_realmrgw_zonegrouprgw_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_realmrgw_zonegrouprgw_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つ目のデータセンターのエンドポイントにルートとしてログインします。
  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. 1つ目のデータセンターのエンドポイントにルートとしてログインします。
  30. replication-synchronization realmの同期状態を確認します。

    シンタックス

    radosgw-admin sync status --rgw-realmRGW_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-realmarugumentが必要です。