オブジェクトゲートウェイ設定および管理ガイド

Red Hat Ceph Storage 4

Ceph Storage Object Gateway の設定および管理

Red Hat Ceph Storage Documentation Team

概要

本書では、Ceph Storage Object Gateway を設定および管理する手順について説明します。

第1章 概要

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

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

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

gateway

第2章 設定

2.1. Beast および CivetWeb フロントエンドの Web サーバー

Ceph Object Gateway はフロントエンドとして Beast および CivetWeb を提供し、どちらも C/C++ の組み込み Web サーバーです。

Beast

Red Hat Ceph Storage 4 以降は、デフォルトのフロントエンド Web サーバーになります。Red Hat Ceph Storage 3 からアップグレードすると、rgw_frontends パラメーターが自動的に Beast に変更になります。Beast は Boost.Beast C++ ライブラリーを使用して HTTP を解析し、Boost.Asio を使用して非同期ネットワーク I/O を行います。

CivetWeb

Red Hat Ceph Storage 3 では、CivetWeb がデフォルトのフロントエンドですが、それに応じて rgw_frontends オプションを設定して Beast を使用することもできます。Civetweb は、Mongoose プロジェクトのフォークである HTTP ライブラリーです。

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

Ceph Object Gateway は CivetWeb および Beast 埋め込み HTTP サーバーをフロントエンドとして提供します。Beast フロントエンドは、HTTP 解析に Boost.Beast ライブラリーを使用し、非同期ネットワーク I/O に Boost.Asio ライブラリーを使用します。Red Hat Ceph Storage バージョン 3.x では、CivetWeb がデフォルトのフロントエンドとなり、Beast フロントエンドは Red Hat Ceph Storage 設定ファイルの rgw_frontends で指定する必要があります。Red Hat Ceph Storage バージョン 4.0 の時点で、Beast フロントエンドはデフォルトであり、Red Hat Ceph Storage 3.x からのアップグレードにより、rgw_frontends パラメーターが自動的に Beast に変更になります。

2.3. Beast 設定オプション

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

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

endpoint および ssl_endpoint

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

ssl_certificate

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

ssl_private_key

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

tcp_nodelay

一部の環境でのパフォーマンスの最適化。

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.4. CivetWeb ポートの変更

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

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

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

重要

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

前提条件

  • 稼働中の Red Hat Ceph Storage 4.1 クラスター
  • Ceph Object Gateway ノード

手順

  1. ゲートウェイノードで、/etc/ceph/ ディレクトリーで Ceph 設定ファイルを開きます。
  2. 以下の例のような Ceph Object Gateway (RGW) クライアントセクションを見つけます。

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

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

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

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

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

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

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

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

    # firewall-cmd --list-all
  6. ポートが開かなければ、ポートを追加してファイアウォール設定を再読み込みします。

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

2.5. Civetweb での SSL の使用

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

重要

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

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

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

重要

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

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

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

2.6. Civetweb 設定オプション

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

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

access_log_file

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

error_log_file

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

num_threads

ワーカースレッドの数。Civetweb は、各着信接続を個別のスレッドで処理します。そのため、このオプションの値は、同時 HTTP 接続 Civetweb が処理できる数です。

50

request_timeout_ms

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

30000

このオプションの一部が設定された /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.7. DNS へのワイルドカードの追加

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

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

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

以下に例を示します。

address=/.gateway-node1/192.168.122.75

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

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

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

ping mybucket.{hostname}

以下に例を示します。

ping mybucket.gateway-node1

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

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

[client.rgw.rgw1.rgw0]
...
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 civetweb = 20

RGW デバッグログの場合は、Ceph 設定ファイルの [client.rgw.{instance}] セクションに以下のパラメーターを追加します。

[client.rgw.rgw1.rgw0]
...
debug rgw = 20

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

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

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

ロギングおよびデバッグに関する一般的な情報は、『Red Hat Ceph Storage 設定ガイド』「Ceph デバッグおよびログ設定」セクションを参照してください。

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

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

注記

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

重要

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

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

お客様提供のキー

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

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

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

キー管理サービス

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

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

重要

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

2.10. HashiCorp Vault

ストレージ管理者は、Ceph Object Gateway で使用するために、キー、パスワード、および証明書を HAshiCorp Vault に安全に保存できます。HashiCorp Vault は、Ceph Object Gateway によって使用されるサーバー側の暗号化にセキュアなキー管理サービスを提供します。

Ceph Vault の統合ダイアグラム

基本的なワークフロー:

  1. クライアントは、オブジェクトのキー ID に基づいて Vault から秘密鍵の作成を要求します。
  2. クライアントは、オブジェクトのキー ID を持つオブジェクトを Ceph Object Gateway にアップロードします。
  3. その後、Ceph Object Gateway は vault から新規作成された秘密鍵を要求します。
  4. Vault は秘密鍵を Ceph Object Gateway に返すことで要求に応答します。
  5. Ceph Object Gateway は新しい秘密鍵を使用してオブジェクトを暗号化できるようになりました。
  6. 暗号化が完了すると、オブジェクトは Ceph OSD に保存されます。
重要

Red Hat は、弊社のテクノロジーパートナーと協力して、本書をお客様にサービスとして提供します。ただし、Red Hat はこの製品のサポートを提供しません。この製品の技術的なサポートが必要な場合は、Hashicorp にサポートを依頼してください。

2.10.1. 前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • Ceph Object Gateway ソフトウェアのインストール。
  • HashiCorp Vault ソフトウェアのインストール

2.10.2. Vault のシークレットエンジン

HashiCorp Vault は、データを生成、保存、または暗号化するために複数のシークレットエンジンを提供します。アプリケーションプログラミングインターフェース(API)は、そのデータのアクションを要求するシークレットエンジンにデータ呼び出しを送信し、シークレットエンジンはそのアクション要求の結果を返します。

Ceph Object Gateway は、HshiCorp Vault シークレットエンジンの 2 つをサポートします。

  • キー/値バージョン 2
  • 移動中

キー/値バージョン 2

キー/値のシークレットエンジンは、ディスク上の Vault にランダムなシークレットを保存します。kv エンジンのバージョン 2 では、設定可能な数のバージョン数をキーに指定できます。バージョンのデフォルト数は 10 です。バージョンを削除しても、基盤のデータは削除されませんが、データを削除したとマークするため、削除されたバージョンの削除が解除されます。キー名は文字列でなければ、エンジンは文字列以外の値を文字列に変換します。コマンドラインインターフェースを使用する場合、エンジンは文字列以外の値を文字列に変換します。文字列以外の値を保持するには、JSON ファイルを指定するか、HTTP アプリケーションプログラミングインターフェース(API)を使用します。

注記

アクセス制御リスト(ACL)ポリシーの場合、キー/値のシークレットエンジンは 作成 機能と 更新 機能の違いを認識します。

移動中

移行シークレットエンジンは、受信データで暗号化機能を実行します。移行シークレットエンジンはハッシュを生成でき、ランダムなバイトのソースで、データの署名および検証も可能です。Vault は移行シークレットエンジンを使用する場合にデータを保存しません。移行シークレットエンジンは、複数の目的で同じキーを使用できるようにするため、キーの派生をサポートします。また、推移シークレットエンジンはキーバージョン管理をサポートします。Transit シークレットエンジンは、以下のキータイプをサポートします。

aes128-gcm96
128 ビットの AES 鍵と 96 ビットの nonce を使用する AES-GCM は、暗号化、復号化、鍵の復号化、および収束暗号化をサポートします。
aes256-gcm96
256 ビットの AES キーと 96 ビットの nonce を使用する AES-GCM は、暗号化、復号化、鍵の復号化、および収束暗号化(デフォルト)をサポートします。
chacha20-poly1305
Chacha20: 256 ビットキーを使用した Chacha20-Poly1305。暗号化、復号化、鍵の復号化、および収束暗号化をサポートします。
ed25519
ed25519; は署名、署名検証、および鍵の派生をサポートします。
ecdsa-p256
曲線 P-256 を使用した ECDSA。署名および署名の検証をサポートします。
ecdsa-p384
曲線 P-384 を使用した ECDSA。署名および署名の検証をサポートします。
ecdsa-p521
曲線 P-521 を使用する ECDSA。署名および署名の検証をサポートします。
rsa-2048
2048 ビットの RSA 鍵(暗号化、復号化、署名、および署名の検証に対応)
rsa-3072
3072 ビットの RSA 鍵(暗号化、復号化、署名、および署名の検証に対応)
rsa-4096
4096 ビットの RSA 鍵(暗号化、復号化、署名、および署名の検証に対応)

関連情報

  • 詳細は、Vault のプロジェクトサイトにある 「KV Secrets Engine」ドキュメントを参照してください。
  • 詳細は、Vault のプロジェクトサイトにある「Transport Secrets Engine」ドキュメントを参照してください。

2.10.3. Vault の認証

HashiCorp Vault は、さまざまな種類の認証メカニズムをサポートします。Ceph Object Gateway は現在 Vault エージェントおよびトークンの認証方法をサポートします。Ceph Object Gateway は rgw_crypt_vault_auth オプションおよび rgw_crypt_vault_addr オプションを使用して HashiCorp Vault を使用するように設定します。

token

トークン認証方法により、ユーザーはトークンを使用した認証が可能になります。新規トークンの作成、トークンによるシークレットの取り消し、その他の多くのトークン操作を行うことができます。トークンストアを使用すると、他の認証方法をバイパスできます。トークン認証方法を使用する場合は、rgw_crypt_vault_token_file オプションも使用する必要があります。トークンファイルは、Ceph Object Gateway によってのみ読み取り可能です。また、特定のパスからのキーリングの取得を可能にする制限されたポリシーを持つ Vault トークンを使用する必要があります。

警告

Red Hat は、実稼働環境にトークン認証を使用しないことを推奨します。

vault エージェント

Vault エージェントは、クライアントノード上で実行され、クライアント側のキャッシュとトークンの更新を提供するデーモンです。Vault エージェントは通常 Ceph Object Gateway ノードで実行されます。

関連情報

  • 詳細は、Vault のプロジェクトサイトにある「Token Auth Method」ドキュメントを参照してください。
  • 詳細は、Vault のプロジェクトサイトにある「Vault Agent」ドキュメントを参照してください。

2.10.4. Vault の名前空間

HashiCorp Vault をエンタープライズサービスとして使用することで、組織内のチームが使用できる分離された namespace を一元管理できるようになります。これらの分離された名前空間環境は テナント と呼ばれ、組織内のチームがこれらの テナント を使用して、ポリシー、シークレット、ID を他のチームから分離することができます。Vault の名前空間機能は、単一のインフラストラクチャー内からのセキュアなマルチテナンシーをサポートします。

関連情報

2.10.5. Vault を使用するための Ceph Object Gateway の設定

HashiCorp Vault を使用するように Ceph Object Gateway を設定するには、暗号化キーストアとして設定する必要があります。現在、Ceph Object Gateway は 2 つの異なるシークレットエンジンと 2 つの異なる認証方法をサポートしています。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • Ceph Object Gateway ソフトウェアのインストール。
  • Ceph Object Gateway ノードへのルートレベルのアクセス。

手順

  1. Ceph 設定ファイル (デフォルトでは /etc/ceph/ceph.conf) を編集するためにを開き、Vault を暗号化キーストアとして有効にします。

    rgw_crypt_s3_kms_backend = vault
  2. [client.radosgw.INSTANCE_NAME] セクションで、Token または Vault エージェントのいずれかの Vault 認証メソッドを選択します。

    1. Token を使用している場合は、以下の行を追加します。

      rgw_crypt_vault_auth = token
      rgw_crypt_vault_token_file = /etc/ceph/vault.token
      rgw_crypt_vault_addr = http://VAULT_SERVER:8200
    2. Vault エージェント を使用している場合は、以下の行を追加します。

      rgw_crypt_vault_auth = agent
      rgw_crypt_vault_addr = http://VAULT_SERVER:8100
  3. [client.radosgw.INSTANCE_NAME] セクションで、Key/Value または Transit のいずれかの Vault シークレットエンジンを選択します。

    1. Key/Value を使用している場合は、以下の行を追加します。

      rgw_crypt_vault_secret_engine = kv
    2. Transit を使用している場合は、以下の行を追加します。

      rgw_crypt_vault_secret_engine = transit
  4. 必要に応じて、[client.radosgw.INSTANCE_NAME] セクションで、暗号化キーを取得する Vault 名前空間を設定できます。

    rgw_crypt_vault_namespace = NAME_OF_THE_NAMESPACE
  5. パスの接頭辞を設定して、Ceph Object Gateway が Vault から暗号鍵を取得する場所を制限します。

    rgw_crypt_vault_prefix = /v1/secret/data

    1. エクスポート可能な移行キーの場合は、以下のようにプレフィックスパスを設定します。

      rgw_crypt_vault_prefix = /v1/transit/export/encryption-key

      Vault サーバーのドメイン名が vault-server である場合は、Ceph Object Gateway は以下の URL から暗号化されたトランジションキーを取得します。

      http://vault-server:8200/v1/transit/export/encryption-key

  6. Ceph 設定ファイルに変更を保存します。

関連情報

2.10.6. kv エンジンを使用したキーの作成

HashiCorp Vault Key/Value シークレットエンジン (kv) を設定し、Ceph Object Gateway で使用するためのキーを作成できるようにします。シークレットは、kv シークレットエンジンのキーと値のペアとして保存されます。

重要

サーバー側の暗号化のキーは 256 ビットの長さで、base64 を使用してエンコードする必要があります。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • HashiCorp Vault ソフトウェアのインストール
  • HashiCorp Vault ノードへのルートレベルのアクセス。

手順

  1. キー/値バージョン 2 シークレットエンジンを有効にします。

    [root@vault ~]# vault secrets enable kv-v2
  2. 新しいキーを作成します。

    構文

    vault kv put secret/PROJECT_NAME/BUCKET_NAME key=$(openssl rand -base64 32)

    [root@vault ~]# vault kv put secret/myproject/mybucketkey key=$(openssl rand -base64 32)
    
    ====== Metadata ======
    Key              Value
    ---              -----
    created_time     2020-02-21T17:01:09.095824999Z
    deletion_time    n/a
    destroyed        false
    version          1

2.10.7. 推移エンジンを使用した鍵の作成

HashiCorp Vault 遷移シークレットエンジン (transit) を設定して、Ceph Object Gateway で使用するキーを作成できるようにします。Ceph Object Gateway でのサーバー側の暗号化に使用するには、Transport Secret Engine でキーを作成する必要があります。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • HashiCorp Vault ソフトウェアのインストール
  • HashiCorp Vault ノードへのルートレベルのアクセス。

手順

  1. 移行シークレットエンジンを有効にします。

    [root@vault ~]# vault secrets enable transit
  2. 新しいエクスポート可能なキーを作成します。

    構文

    vault write -f transit/keys/BUCKET_NAME exportable=true

    [root@vault ~]# vault write -f transit/keys/mybucketkey exportable=true

    注記

    デフォルトでは、上記のコマンドは aes256-gcm96 タイプキーを作成します。

  3. キーの作成を確認します。

    構文

    vault read transit/export/encryption-key/BUCKET_NAME/VERSION_NUMBER

    [root@vault ~]# vault read transit/export/encryption-key/mybucketkey/1
    
    Key     Value
    ---     -----
    keys    map[1:-gbTI9lNpqv/V/2lDcmH2Nq1xKn6FPDWarCmFM2aNsQ=]
    name    mybucketkey
    type    aes256-gcm96

    注記

    キーバージョンを含む完全なキーパスを指定する必要があります。

2.10.8. AWS および vault を使用したオブジェクトのアップロード

Ceph Object Gateway にオブジェクトをアップロードする場合、Ceph Object Gateway は vault からキーを取得し、そのオブジェクトをバケットに暗号化して保存します。オブジェクトをダウンロードする要求が実行されると、Ceph Object Gateway は対応するキーを Vault から自動的に取得し、オブジェクトを復号化します。

注記

URL は、rgw_crypt_vault_addr オプションと、rgw_crypt_vault_prefix オプションで設定されたパス接頭辞を使用して構築されます。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • Ceph Object Gateway ソフトウェアのインストール。
  • HashiCorp Vault ソフトウェアのインストール
  • Ceph Object Gateway クライアントノードへのアクセス
  • Amazon Web Services(AWS)へのアクセス

手順

  1. AWS コマンドラインクライアントを使用してオブジェクトをアップロードします。

    [user@client ~]$ aws --endpoint=http://radosgw:8000 s3 cp plaintext.txt s3://mybucket/encrypted.txt --sse=aws:kms --sse-kms-key-id myproject/mybucketkey

    注記

    例で使用するキーフェッチ URL は http://vault-server:8200/v1/secret/data/myproject/mybucketkey です。

2.10.9. 関連情報

  • 詳細は、Vault のプロジェクトサイトにある「Install Vault」ドキュメントを参照してください。

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

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

2.11.1. S3 ユーザーの作成

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

注記

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

前提条件

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

手順

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

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

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

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

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

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

2.11.2. Swift ユーザーの作成

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

注記

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

前提条件

  • Ceph Object Gateway のインストール
  • Ceph Object Gateway ノードへのルートレベルのアクセス。

手順

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

    構文

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

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

    [root@rgw]# 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@rgw]# 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.11.3. S3 アクセスのテスト

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

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

  1. Red Hat Enterprise Linux 8 に、Red Hat Enterprise Linux 7 および High Availability リポジトリーの共通リポジトリーを有効にします。

    Red Hat Enterprise Linux 7

    # subscription-manager repos --enable=rhel-7-server-rh-common-rpms

    Red Hat Enterprise Linux 8

    # subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms

  2. python-boto パッケージをインストールします。

    Red Hat Enterprise Linux 7

    # yum install python-boto

    Red Hat Enterprise Linux 8

    # dnf install python3-boto3

  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. ACCESS および SECRET は、『Red Hat Ceph Storage Object Gateway 設定および管理ガイド』「S3 ユーザーの作成」セクションの access_key および secret_key の値に置き換えます。
  5. スクリプトを実行します。

    python s3test.py

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

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

2.11.4. Swift アクセスのテスト

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

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

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

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

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

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

以下に例を示します。

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

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

my-new-bucket

2.12. HAProxy/keepalived の設定

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

HAProxy および keepalived のもう 1 つのユースケースは、HAProxy サーバーで HTTPS を終了することです。HAProxy サーバーを使用して HAProxy サーバーで HTTPS を終了し、HAProxy サーバーと Civetweb ゲートウェイインスタンス間の HTTP を使用することができます。

注記

本セクションでは、Red Hat Enterprise Linux 7 向けの HAProxy および keepalived の設定を説明します。

Red Hat Enterprise Linux 8 の場合は、keepalived パッケージおよび haproxy パッケージをインストールして、ロードバランサーをインストールします。「How do we need any additional subscription for Load Balancing on Red Hat Enterprise Linux 8?」を参照してください。詳細は、ナレッジベースアーティクルを参照してください。

2.12.1. haproxy/keepalived の前提条件

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

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

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

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

2.12.2. HAProxy ノードの準備

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

  1. Red Hat Enterprise Linux 7 をインストールします。
  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.12.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.12.4. HAProxy のインストールおよび設定

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

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

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

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

    以下の行を追加します。

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

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

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

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

    以下の行を追加します。

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

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

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

    最後に、証明書とキーを PEM ファイルに配置します。

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

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

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

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

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

  6. haproxy の有効化/起動

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

2.12.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.13. 静的 Web ホスト用ゲートウェイの設定

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

2.13.1. 静的 Web ホストアライディングの前提条件

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

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

注記

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

2.13.2. 静的 Web ホストの要件

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

  1. S3 の静的 Web ホストは、標準の S3/Swift API のユースケースで使用されるインスタンスとは別の Ceph Object Gateway インスタンスを使用します。
  2. S3 静的 Web サイトをホストするゲートウェイインスタンスには、標準の S3/Swift API ゲートウェイインスタンスから別の、オーバーランディングされていないドメイン名が必要です。
  3. S3 静的 Web サイトをホストするゲートウェイインスタンスは、標準の S3/Swift API ゲートウェイインスタンスとは別の公開用 IP アドレスを使用する必要があります。
  4. S3 静的 Web サイトの負荷分散、および必要な場合には HAProxy/keepalived を使用して SSL が終了しているゲートウェイインスタンス。

2.13.3. 静的 Web ホストゲートウェイの設定

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

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

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

重要

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

2.13.4. 静的 Web ホスト DNS 設定

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

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

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

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

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

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

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

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

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

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

バケット名は bucket1 です。

hostname から一致しないバケット

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

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

バケット名は bucket2 です。

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

http://www.example.com

CNAME を使用した長いバケットへのホスト名

通常、AWS ではバケット名がドメイン名と一致する必要があります。CNAME を使用して静的 Web ホストに 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.13.5. 静的 Web ホストサイトの作成

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

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

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

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

注記

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

注記

Red Hat Ceph Storage では、バージョン付けされたバケットの NFS エクスポートはサポートされません。

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

注記

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

注記

NFS マウント IS を介したファイルの編集はサポートされていません。

注記

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

NFS を使用する Ceph Object Gateway は、ゲートウェイサーバーのインプロセスライブラリーパッケージングと、NFS-Ganesha NFS サーバー用の File System Abstraction Layer(FSAL)名前空間ドライバーに基づいています。ランタイム時に、Ceph Object Gateway デーモンと NFS のインスタンスは、完全な Ceph Object Gateway デーモン(Civetweb HTTP サービスなし)と 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-Ganesha は、別の NFS インスタンスが実行している場合は起動しません。
  2. root で Red Hat Ceph Storage Tools リポジトリーを有効にします。

    Red Hat Enterprise Linux 7

    # subscription-manager repos --enable=rhel-7-server-rhceph-4-tools-rpms

    Red Hat Enterprise Linux 8

    # subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-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 ノードから NFS-Ganesha ホストの /etc/ceph/ ディレクトリーに Ceph 設定ファイルをコピーし、必要に応じて編集します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    NFS_CORE_PARAM{
        mount_path_pseudo = true;
    }

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

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

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

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

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

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

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

    # systemctl restart ceph-radosgw.target

NFSv4 クライアントの設定

名前空間にアクセスするには、設定した NFS-Ganesha エクスポートをローカルの POSIX 名前空間にある任意の場所にマウントします。前述のように、この実装にはいくつかの特殊な制限があります。

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

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

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

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

注記

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

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

NFSv3 クライアントの設定

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

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

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

NFSv3 は、クライアント OPEN 操作および CLOSE 操作をファイルサーバーと通信しないため、RGW NFS はこれらの操作を使用してファイルのアップロードトランザクションの開始と終了をマークできません。代わりに、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 クラスターのプールに保存されます。デフォルトでは、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 の管理データを保存するプールは、多くの場合同じ CRUSH ルールセットを使用し、管理データには 10 プールがあるためです。詳細は、Red Hat Ceph Storage 4 の場合は、「プール」 および 『ストレージ戦略』ガイドを参照してください。

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

mon_pg_warn_max_per_osd = n

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

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

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

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

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

    構文

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

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

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

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

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

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

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

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

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

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

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

以下に例を示します。

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

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

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

Indexless バケットは、配置ターゲットが特定のバケットのオブジェクトを追跡しないメカニズムを提供します。これにより、オブジェクトの書き込みが行われ、Ceph Object Gateway が Ceph Storage クラスターに加える必要のあるラウンドトリップの数が減ります。これにより、同時操作やオブジェクト書き込みパフォーマンスが少なくなります。

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

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

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

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

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

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

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

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

    $ radosgw-admin period update --commit

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

重要

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

注記

indexless バケットを使用すると、単一バケットのオブジェクトの最大数の制限が削除されます。

注記

インデックスなしバケットのオブジェクトは NFS から一覧表示できません。

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

Ceph Object Gateway は、バケットインデックスデータをインデックスプール (index_pool) に格納します。デフォルトは .rgw.buckets.index です。クライアントが多数のオブジェクトを配置すると、数百から数百万ものオブジェクトバケットあたりのオブジェクトの最大数を設定せずにクォータを設定しない単一のバケットでは、インデックスプールのパフォーマンスが大幅に低下する可能性があります。

バケットインデックスのシャーディング は、バケットあたりのオブジェクト数が多い場合のパフォーマンスのボトルネックを防ぐのに役立ちます。Red Hat Ceph Storage 4.1 以降、バケットインデックスシャードのデフォルト数である bucket_index_max_shards が 1 から 11 に変更になりました。この変更により、小規模なバケットの書き込みスループットの量が増え、動的リシャードの開始が遅延します。この変更は新しいバケットおよびデプロイメントにのみ影響します。

既存のデプロイメントでこのデフォルト値を変更するには、以下のコマンドを実行します。

# radosgw-admin zonegroup modify --bucket-index-max-shards=10

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

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

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

重要

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

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

3.4.2. バケットライフサイクルの並列スレッド処理

Red Hat Ceph Storage 4.1 の新機能により、バケットライフサイクルの並行スレッド処理が可能となります。この並列化は Ceph Object Gateway インスタンスの数にスケーリングされ、順序内のインデックスシャードの列挙数を数字シーケンスに置き換えます。デフォルトのロックタイムアウトが 60 秒から 90 秒に延長されました。Ceph Object Gateway インスタンスごとに並行して実行するようにライフサイクルワーカースレッドを調整するために、新しい調整可能なオプションが追加されました。

rgw_lc_max_worker

このオプションは並行して実行するライフサイクルワーカースレッドの数を指定します。これにより、バケットとインデックスシャードを同時に処理します。rgw_lc_max_worker オプションのデフォルト値は 3 です。

rgw_lc_max_wp_worker

このオプションは、各ライフサイクルワーカーのワークプール内のスレッド数を指定します。このオプションは、各バケットの迅速な処理に役に立ちます。rgw_lc_max_wp_worker オプションのデフォルト値は 3 です。

関連情報

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

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

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

前提条件

手順

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

    number of objects expected in a bucket / 100,000

    シャードの最大数は 65521 であることに注意してください。

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

    rgw_override_bucket_index_max_shards = value

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

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

    # systemctl restart ceph-radosgw.target

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

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

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

インデックスプール(該当する場合)を SSD ベースの OSD の CRUSH ルールセットにマッピングすると、バケットインデックスのパフォーマンスにも役に立ちます。

前提条件

手順

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

    number of objects expected in a bucket / 100,000

    シャードの最大数は 65521 であることに注意してください。

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

    $ radosgw-admin zonegroup get > zonegroup.json
  3. zonegroup.json ファイルで、名前付きゾーンごとに 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.5. Dynamic Bucket Index Resharding

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

重要

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

前提条件

手順

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

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

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

    radosgw-admin reshard add --bucket bucket --num-shards number

    以下を置き換えます。

    • bucket を、再シャードするバケットの名前に
    • number を、新しいシャード数に

    以下に例を示します。

    $ radosgw-admin reshard add --bucket data --num-shards 10
  • 再シャードキューを一覧表示するには、以下を実行します。

    $ radosgw-admin reshard list
  • バケットのサイズ変更のステータスを確認するには、以下を実行します。

    radosgw-admin reshard status --bucket bucket

    以下を置き換えます。

    • bucket を、再シャードするバケットの名前に

    以下に例を示します。

    $ radosgw-admin reshard status --bucket data
  • 再シャードキューでエントリーを即時に処理するには、以下を実行します。

    $ radosgw-admin reshard process
  • 保留中のバケットのサイズ変更を中止するには、以下を実行します。

    radosgw-admin reshard cancel --bucket bucket

    以下を置き換えます。

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

    以下に例を示します。

    $ radosgw-admin reshard cancel --bucket data
    重要

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

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

3.4.6. Manual Bucket Index Resharding

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

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

この手順は、単純な設定でのみ使用してください。マルチサイト設定でシャードバケットを再シャードするには、「マルチサイトを使用した手動によるバケットのリシャード化」を参照してください。

前提条件

手順

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

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

    以下を置き換えます。

    • bucket を、再シャードするバケットの名前に

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

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

    radosgw-admin bucket reshard --bucket=bucket
    --num-shards=number

    以下を置き換えます。

    • bucket を、再シャードするバケットの名前に
    • number を、新しいシャード数に

    たとえば、data という名前のバケットおよび必要なシャード数が 100 の場合は、以下を入力します。

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

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

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

重要

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

前提条件

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

手順

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

    $ radosgw-admin reshard stale-instances list
  2. 古いインスタンスを消去します。

    $ radosgw-admin reshard stale-instances rm

3.5. 圧縮の有効化

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

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

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

設定

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

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

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

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

以下に例を示します。

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

圧縮の有効化または無効化後に、Ceph Object Gateway インスタンスを再起動します。これにより、変更が反映されます。

注記

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

統計

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

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

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

3.6. ユーザー管理

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

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

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

ユーザーおよびサブユーザーの作成、変更、表示、一時停止、および削除を行うことができます。

重要

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

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

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

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

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

3.6.1. マルチテナンシー

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

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

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

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

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

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

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

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

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

3.6.2. ユーザーの作成

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

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

以下に例を示します。

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

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

3.6.3. サブユーザーの作成

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

注記

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

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

以下に例を示します。

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

3.6.4. ユーザー情報の取得

ユーザーに関する情報を取得するには、user info ユーザー ID (--uid={username}) を指定します。

[root@master-zone]# radosgw-admin user info --uid=janedoe

テナントされたユーザーに関する情報を取得するには、ユーザー ID とテナントの名前の両方を指定します。

[root@master-zone]# radosgw-admin user info --uid=janedoe --tenant=test

3.6.5. ユーザー情報の変更

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

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

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

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

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

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

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

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

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

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

3.6.7. ユーザーの削除

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

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

以下に例を示します。

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

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

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

オプションは次のとおりです。

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

3.6.8. サブユーザーの削除

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

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

オプションは次のとおりです。

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

3.6.9. ユーザーの名前を変更

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

前提条件

  • 稼働中の Ceph クラスター
  • root または sudo アクセス
  • Ceph Object Gateway がインストールされていること。

手順

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

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

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

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

    ユーザーがテナント内にある場合は、ユーザー名とテナントの両方を指定します。

    構文

    radosgw-admin user rename --uid user-name --new-uid new-user-name --tenant tenant

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

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

  2. ユーザーの名前が正常に変更されたことを確認します。

    構文

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

    以下に例を示します。

    # radosgw-admin user info --uid=user2

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

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

関連情報

  • man ページの screen(1)

3.6.10. キーの作成

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

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

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

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

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

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

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

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

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

  1. 特定のユーザーのアクセスキーを見つけます。

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

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

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

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

    以下に例を示します。

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

3.6.12. 管理機能の追加および削除

Ceph Storage Cluster は管理 API を提供し、ユーザーが REST 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 remove --uid=johndoe --caps={caps}

3.7. クォータ管理

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

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

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

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

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

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

以下に例を示します。

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

オブジェクトと / または最大サイズに負の値を指定すると、特定のクォータ属性チェックが無効になります。

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 in bytes>]

オブジェクトと / または最大サイズに負の値を指定すると、特定のクォータ属性チェックが無効になります。

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>

テナントされたユーザーのクォータ設定を取得するには、ユーザー ID とテナントの名前を指定します。

+ radosgw-admin user info --uid=_user-id_ --tenant=_tenant_

3.7.6. クォータの統計の更新

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

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

3.7.7. ユーザークォータの使用状況の取得

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

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

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

3.7.8. クォータキャッシュ

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

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

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

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

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

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

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

3.8. 用途

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

オプションは次のとおりです。

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

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

3.8.1. 使用方法の表示

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

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

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

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

3.8.2. 使用方法のトリミング

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

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

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

3.9. バケット管理

ストレージ管理者は、Ceph Object Gateway を使用する場合、ユーザー間で移動して名前を変更することでバケットを管理することができます。Ceph Object Gateway 内で孤立したオブジェクトまたはリークオブジェクトを見つけることもできます。これはストレージクラスターのライフタイム時に発生する可能性があります。

さらに、バケットにマルチファクター認証(MFA)を設定できます。MFA は、ユーザーがバケットからデータを削除する前に標準認証に加えてワンタイムパスワードトークンの入力を要求することにより、誤ってデータ損失に対してセキュリティー層を追加します。

3.9.1. バケットの移動

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

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

3.9.1.1. 前提条件

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

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

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

手順

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

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

    以下を置き換えます。

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

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

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

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

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

    以下を置き換えます。

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

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

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

    # radosgw-admin bucket list --bucket=data

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

テナントされたユーザー間でバケットを別のユーザーに移動できます。

手順

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

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

    置き換え:

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

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

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

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

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

    以下を置き換えます。

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

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

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

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

3.9.1.4. テナントのないユーザーからテナントユーザーへのバケットの移動

バケットをテナント以外のユーザーからテナントユーザーに移動できます。

手順

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

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

    rgw_keystone_implicit_tenants = true

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

    # swift list

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

    # s3cmd ls

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

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

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

    置き換え:

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

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

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

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

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

    置き換え:

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

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

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

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

3.9.2. バケットの名前変更

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

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • Ceph Object Gateway がインストールされている。
  • バケット。

手順

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

    radosgw-admin bucket list

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

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

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

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

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

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

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

    以下に例を示します。

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

    radosgw-admin bucket list

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

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

3.9.3. 孤立したオブジェクトおよびリークオブジェクトの検索

正常なストレージクラスターには孤立したオブジェクトやリークオブジェクトがありませんが、場合によっては孤立したオブジェクトやリークオブジェクトが発生することがあります。たとえば、Ceph Object Gateway が操作の途中でダウンすると、一部のオブジェクトが孤立する可能性があります。また、検出されていないバグにより、孤立したオブジェクトが発生する可能性があります。

Red Hat Ceph Storage 4.1 以降、ストレージ管理者は Ceph Object Gateway オブジェクトが RADOS オブジェクトにマッピングする方法を確認することができます。radosgw-admin コマンドは、これらの潜在的な孤立オブジェクトまたはリークオブジェクトの一覧を検索して生成するための新しいツールを提供します。radoslist サブコマンドを使用すると、バケット内またはストレージクラスター内のすべてのバケットに保存されているオブジェクトが表示されます。rgw-orphan-list スクリプトは、プール内の孤立したオブジェクトを表示します。

重要

radoslist サブコマンドは、非推奨の orphans find サブコマンドおよび orphans finish サブコマンドを置き換えます。

前提条件

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

手順

  1. バケット内でデータを保持するオブジェクトの一覧を生成するには、以下を実行します。

    構文

    radosgw-admin bucket radoslist --bucket BUCKET_NAME

    [root@rgw ~]# radosgw-admin bucket radoslist --bucket mybucket

    注記

    BUCKET_NAME を省略すると、すべてのバケット内のすべてのオブジェクトが表示されます。

  2. プールの孤立した一覧を生成するには、以下を実行します。

    [root@rgw ~]# rgw-orphan-list

    Available pools:
        .rgw.root
        default.rgw.control
        default.rgw.meta
        default.rgw.log
        default.rgw.buckets.index
        default.rgw.buckets.data
        rbd
        default.rgw.buckets.non-ec
        ma.rgw.control
        ma.rgw.meta
        ma.rgw.log
        ma.rgw.buckets.index
        ma.rgw.buckets.data
        ma.rgw.buckets.non-ec
    Which pool do you want to search for orphans?

    孤立を検索する場合はプール名を入力します。

    重要

    メタデータプールではなく、rgw-orphan-list コマンドを使用する場合は、データプールを指定する必要があります。

  3. 一覧で孤立したオブジェクトを確認します。
  4. 孤立したオブジェクトを削除するには、以下を実行します。

    構文

    rados -p POOL_NAME rm OBJECT_NAME

    [root@rgw ~]# rados -p default.rgw.buckets.data rm myobject

    警告

    正しいオブジェクトを削除していることを確認します。rados rm コマンドを実行すると、ストレージクラスターからデータが削除されます。

関連情報

  • レガシーの radosgw-admin orphans find サブコマンドの詳細は、『Red Hat Ceph Storage 3 Object Gateway 管理ガイド』「孤立オブジェクトの検出」を参照してください。

3.9.4. マルチファクター認証用のトークンの設定

Ceph Object Gateway は S3 マルチファクター認証(MFA)をサポートします。MFA 対応バケットでは、データを削除する前に、標準の S3 認証に加えて、ユーザーは時間ベースのワンタイムパスワード(TOTP)トークンを入力する必要があります。これにより、バケットからのデータが正しくない削除に対してセキュリティーが強化されます。

注記

S3 API を使用してバケットの MFA およびバージョン管理を有効にします。

注記

MFA ID はユーザーのメタデータに設定されますが、実際の MFA ワンタイムパスワード設定はローカルゾーンの OSD にあります。マルチサイト環境では、ゾーンごとに異なるトークンを使用します。

前提条件

  • バージョン管理および MFA が有効にされているバケット。
  • Ceph Object Gateway ノードに oathtool パッケージがインストールされている。
  • Ceph Object Gateway へのルートレベルのアクセス。
  • Google Authenticator または FreeOTP などの認証ツール。

手順

  1. 秘密シードを生成します。

    構文

    SEED=$(head -10 /dev/urandom | sha512sum | cut -b 1-30)
    echo $SEED

    [root@rgw ~]# SEED=$(head -10 /dev/urandom | sha512sum | cut -b 1-30)
    [root@rgw ~]# echo $SEED
    4fe2d015680b1b88f787d83339925c

  2. シード値をコピーします。
  3. oathtool を起動し、コピーした値を Hex secret フィールドに貼り付けます。

    構文

    oathtool -v -d6 $SEED

    [root@rgw ~]# oathtool -v -d6 $SEED
    Hex secret: 4fe2d015680b1b88f787d83339925c
    Base32 secret: J7RNAFLIBMNYR54H3AZTTES4
    Digits: 6
    Window size: 0
    Start counter: 0x0 (0)
    
    315849

  4. Base32 シークレットと 6 桁の PIN を書き留めておきます。
  5. オーセンティケーターソフトウェアで + を選択し、Manual entry を選択します。
  6. ユーザーのメールを Account フィールドに追加します。
  7. Base32 シークレットを Key フィールドに入力します。

    注記

    Base32 シークレットをオーセンティケーターソフトウェアに入力する代わりに、qrencode を使用して QR コードを生成し、それをオーセンティケーターソフトウェアにインポートできます。qrencode の使用に関する詳細は、qrencode 多要素認証の設定」を参照してください。

  8. radosgw-admin を使用して、ユーザーの RGW に MFA トークンを作成します。

    構文

    radosgw-admin mfa create --uid=UID --totp-serial=TOTP-ID --totp-seed=SEED

    UID はユーザー ID です。

    TOTP_ID は、TOTP トークン用に作成する名前です。

    SEED は、以前に生成したシード値と 16 進数シークレットです。

    [root@rgw ~]# radosgw-admin mfa create --uid=hari --totp-serial=MFAtest --totp-seed=4fe2d015680b1b88f787d83339925c
    [root@rgw ~]# radosgw-admin mfa list --uid=hari
    {
        "entries": [
            {
                "type": 2,
                "id": "MFAtest",
                "seed": "4fe2d015680b1b88f787d83339925c",
                "seed_type": "hex",
                "time_ofs": 0,
                "step_size": 30,
                "window": 2
            }
        ]
    }

  9. オーセンティケーターの現在の 6 桁の PIN を書き留めておきます。
  10. 前と現在の 6 桁の PIN を入力して、トークンを再同期します。

    構文

    radosgw-admin mfa resync --uid=UID --totp-serial=TOTP_ID --debug_ms=0 --totp-pin=OLD_PIN --totp-pin=NEW_PIN

    [root@rgw ~]# radosgw-admin mfa resync --uid=hari --totp-serial=MFAtest --debug_ms=0 --totp-pin=440024 --totp-pin=245763

  11. google オーセンティケーターの現在のピンを確認します。

    構文

    radosgw-admin mfa check --uid=UID --totp-serial=TOTP_ID --debug_ms=0 --totp-pin=NEW_PIN

    [root@rgw ~]# radosgw-admin mfa check --uid=hari --totp-serial=MFAtest --debug_ms=0 --totp-pin=937498
    ok

    注記

    新規または現在の PIN を入力する前に、オーセンティケーターを常に確認してください。前の手順と現在のステップの間で PIN が変更された可能性があります。

正しくない PIN を入力すると、radosgw-admin がエラーを生成します。

+ .例

[root@rgw ~]# radosgw-admin mfa check --uid=hari --totp-serial=MFAtest --debug_ms=0 --totp-pin=123456
MFA check failed, error: (13) Permission denied

関連情報

3.9.5. qrencodeを使用したマルチファクター認証の設定

Base32 シークレットをオーセンティケーターソフトウェアに入力する代わりに、qrencode を使用して QR コードを生成し、それをオーセンティケーターソフトウェアにインポートできます。

注記

マルチファクター認証(MFA)ID はユーザーのメタデータに設定されますが、実際の MFA ワンタイムパスワード設定はローカルゾーンの OSD にあります。マルチサイト環境では、ゾーンごとに異なるトークンを使用します。

前提条件

  • バージョン管理および MFA が有効にされているバケット。
  • Ceph Object Gateway ノードに oathtool パッケージおよび qrencode パッケージがインストールされている。
  • Ceph Object Gateway へのルートレベルのアクセス。
  • Google Authenticator または FreeOTP などの認証ツール。

手順

  1. 秘密シードを生成します。

    構文

    SEED=$(head -10 /dev/urandom | sha512sum | cut -b 1-30)
    echo $SEED

    [root@rgw ~]# SEED=$(head -10 /dev/urandom | sha512sum | cut -b 1-30)
    [root@rgw ~]# echo $SEED
    4fe2d015680b1b88f787d83339925c

  2. シード値をコピーします。
  3. oathtool を起動し、コピーした値を Hex secret フィールドに貼り付けます。

    構文

    oathtool -v -d6 $SEED

    [root@rgw ~]# oathtool -v -d6 $SEED
    Hex secret: 4fe2d015680b1b88f787d83339925c
    Base32 secret: J7RNAFLIBMNYR54H3AZTTES4
    Digits: 6
    Window size: 0
    Start counter: 0x0 (0)
    
    315849

  4. Base32 シークレットと 6 桁の PIN を書き留めておきます。
  5. QR コードを生成します。

    構文

    qrencode -o /tmp/user.png 'otpauth://totp/TOTP_ID?secret=SEED'

    TOTP_ID は、TOTP トークン用に作成する名前です。

    SEED は、以前に生成したシード値と 16 進数シークレットです。

    [root@rgw ~]# qrencode -o /tmp/user.png 'otpauth://totp/MFAtest?secret=J7RNAFLIBMNYR54H3AZTTES4'

  6. オーセンティケーターソフトウェアで + を選択し、Scan barcode を選択します。
  7. バーコードをオーセンティケーターにスキャンします。
  8. radosgw-admin を使用して、ユーザーの RGW に MFA トークンを作成します。

    構文

    radosgw-admin mfa create --uid=UID --totp-serial=TOTP-ID --totp-seed=SEED

    UID はユーザー ID です。

    TOTP_ID は、TOTP トークン用に作成する名前です。

    SEED は、以前に生成したシード値と 16 進数シークレットです。

    [root@rgw ~]# radosgw-admin mfa create --uid=hari --totp-serial=MFAtest --totp-seed=4fe2d015680b1b88f787d83339925c
    [root@rgw ~]# radosgw-admin mfa list --uid=hari
    {
        "entries": [
            {
                "type": 2,
                "id": "MFAtest",
                "seed": "4fe2d015680b1b88f787d83339925c",
                "seed_type": "hex",
                "time_ofs": 0,
                "step_size": 30,
                "window": 2
            }
        ]
    }

  9. オーセンティケーターの現在の 6 桁の PIN を書き留めておきます。
  10. 前と現在の 6 桁の PIN を入力して、トークンを再同期します。

    構文

    radosgw-admin mfa resync --uid=UID --totp-serial=TOTP_ID --debug_ms=0 --totp-pin=OLD_PIN --totp-pin=NEW_PIN

    [root@rgw ~]# radosgw-admin mfa resync --uid=hari --totp-serial=MFAtest --debug_ms=0 --totp-pin=440024 --totp-pin=245763

  11. google オーセンティケーターの現在のピンを確認します。

    構文

    radosgw-admin mfa check --uid=UID --totp-serial=TOTP_ID --debug_ms=0 --totp-pin=NEW_PIN

    [root@rgw ~]# radosgw-admin mfa check --uid=hari --totp-serial=MFAtest --debug_ms=0 --totp-pin=937498
    ok

    注記

    新規または現在の PIN を入力する前に、オーセンティケーターを常に確認してください。前の手順と現在のステップの間で PIN が変更された可能性があります。

正しくない PIN を入力すると、radosgw-admin がエラーを生成します。

+ .例

[root@rgw ~]# radosgw-admin mfa check --uid=hari --totp-serial=MFAtest --debug_ms=0 --totp-pin=123456
MFA check failed, error: (13) Permission denied

3.9.6. バケットの通知

バケット通知により、バケットで特定のイベントが発生した場合に Ceph Object Gateway から情報を送信することができます。バケット通知は HTTP、AMQP0.9.1、および Kafka エンドポイントに送信できます。

特定のバケットおよび特定のトピックにイベントについてのバケット通知を送信するには、通知エントリーを作成する必要があります。バケット通知は、イベントタイプのサブセットに作成するか、すべてのイベントタイプについてデフォルトで作成できます。バケット通知は、キープレフィックスまたはサフィックス、キーに一致する正規表現、オブジェクトに割り当てられたメタデータ属性、またはオブジェクトタグに基づいてイベントをフィルターできます。バケット通知には、バケット通知メカニズムの設定および制御インターフェースを提供する REST API があります。

関連情報

3.9.7. バケット通知の作成

バケットレベルでバケット通知を作成します。通知設定には、Red Hat Ceph Storage Object Gateway S3イベント (ObjectCreated および ObjectRemoved) があります。バケット通知を送信するには、これらの公開と宛先が必要です。バケット通知は S3 操作です。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • ルートレベルのアクセス。
  • Red Hat Ceph Storage Object Gateway のインストール
  • ユーザーアクセスキーおよびシークレットキー。
  • エンドポイントパラメーター。
重要

Red Hat は、ObjectCreate イベント (例: putpostmultipartUpload、および copy) をサポートします。また、Red Hat は、object_deletes3_multi_object_delete などの ObjectRemove イベントをサポートしています。

手順

  1. HTTP サーバー、RabbitMQ サーバー、または Kafka サーバーを起動します。
  2. S3 バケットを作成します。
  3. httpamqp、または kafka プロトコルに SNS トピックを作成します。
  4. s3:objectCreate および s3:objectRemove イベントの s3 バケット通知を作成します。

    client.put_bucket_notification_configuration(
       Bucket=bucket_name,
       NotificationConfiguration={
           'TopicConfigurations': [
               {
                   'Id': notification_name,
                   'TopicArn': topic_arn,
                   'Events': ['s3:ObjectCreated:*', 's3:ObjectRemoved:*']
               }]})

  5. バケットに S3 オブジェクトを作成します。
  6. レシーバー httprabbitmq、または kafka でのオブジェクト作成イベントを確認します。
  7. オブジェクトを削除します。
  8. レシーバー httprabbitmq、または kafka でオブジェクトの削除イベントを確認します。

3.9.8. 関連情報

3.10. Ceph Object Gateway のガベージコレクションの最適化

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

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

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

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

前提条件

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

手順

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

    [root@rgw ~] radosgw-admin gc list

注記

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

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

一部のワークロードは、ガベージコレクションアクティビティーの速度を一時的に停止するか、または永続的に不足する可能性があります。これは特に、削除負荷に該当します。この場合、多数のオブジェクトは短期間保存され、削除されます。このようなワークロードでは、他の操作に関してガベージコレクションの操作の優先度を上げることを検討してください。Ceph Object Gateway ガベージコレクションに関する追加の質問は、Red Hat サポートにお問い合わせください。

前提条件

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

手順

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

    rgw_gc_max_concurrent_io = 20
    rgw_gc_max_trim_chunk = 64
  3. Ceph Object Gateway を再起動して、変更した設定を反映できるようにします。
  4. GC アクティビティー中にストレージクラスターを監視し、増加した値がパフォーマンスに悪影響を与えないことを確認します。
重要

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

第4章 設定リファレンス

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

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

4.1. 一般設定

名前詳細デフォルト

rgw_data

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

文字列

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

rgw_enable_apis

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

文字列

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

rgw_cache_enabled

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

ブール値

true

rgw_cache_lru_size

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

整数

10000

rgw_socket_path

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

文字列

該当なし

rgw_host

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

文字列

0.0.0.0

rgw_port

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

文字列

なし

rgw_dns_name

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

文字列

なし

rgw_script_uri

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

文字列

なし

rgw_request_uri

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

文字列

なし

rgw_print_continue

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

ブール値

true

rgw_remote_addr_param

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

文字列

REMOTE_ADDR

rgw_op_thread_timeout

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

整数

600

rgw_op_thread_suicide_timeout

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

整数

0

rgw_thread_pool_size

スレッドプールのサイズ。

整数

100 スレッド。

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

連続するガベージコレクションの処理サイクルの開始日までの最大時間。

整数

3600

rgw_gc_processor_period

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

整数

3600

rgw_s3 success_create_obj_status

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

整数

0

rgw_resolve_cname

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

ブール値

false

rgw_object_stripe_size

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

整数

4 << 20

rgw_extended_http_attrs

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

文字列

なし。例: "content_foo, content_bar"

rgw_exit_timeout_secs

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

整数

120

rgw_get_obj_window_size

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

整数

16 << 20

rgw_get_obj_max_req_size

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

整数

4 << 20

rgw_relaxed_s3_bucket_names

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

ブール値

false

rgw_list buckets_max_chunk

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

整数

1000

rgw_override_bucket_index_max_shards

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

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

整数

0

rgw_num_zone_opstate_shards

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

整数

128

rgw_opstate_ratelimit_sec

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

整数

30

rgw_curl_wait_timeout_ms

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

整数

1000

rgw_copy_obj_progress

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

ブール値

true

rgw_copy_obj_progress_every_bytes

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

整数

1024 * 1024

rgw_admin_entry

管理リクエスト URL のエントリーポイント。

文字列

admin

rgw_content_length_compat

CONTENT_LENGTH AND HTTP_CONTENT_LENGTH セットを使用して、FCGI 要求の互換性処理を有効にします。

ブール値

false

rgw_bucket_default_quota_max_objects

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

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

整数

-1

rgw_bucket_quota_ttl

キャッシュされたクォータ情報が信頼できる秒数です。このタイムアウト後、クォータ情報はクラスターから再取得されます。

整数

600

rgw_user_quota_bucket_sync_interval

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

整数

180

rgw_user_quota_sync_interval

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

整数

3600 * 24

4.2. プール

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

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

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

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

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: email プールには、ユーザー ID に関連するメールアドレスが含まれます。
  • .<zone-name>.meta:users.swift: Swift プールには、ユーザー ID の Swift サブユーザー情報が含まれます。

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

名前詳細デフォルト

rgw_zonegroup_root_pool

ゾーングループ固有の全情報を格納するプール。

文字列

.rgw.root

rgw_zone_root_pool

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

文字列

.rgw.root

4.3. Swift の設定

名前詳細デフォルト

rgw_enforce_swift_acls

Swift Access Control List(ACL)設定を強制します。

ブール値

true

rgw_swift_token_expiration

Swift トークンを期限切れにする時間(秒単位)。

整数

24 * 3600

rgw_swift_url

Ceph Object Gateway Swift API の URL。

文字列

なし

rgw_swift_url_prefix

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

swift

該当なし

rgw_swift_auth_url

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

文字列

なし

rgw_swift_auth_entry

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

文字列

auth

4.4. ロギング設定

名前詳細デフォルト

rgw_log_nonexistent_bucket

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

ブール値

false

rgw_log_object_name

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

Date

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

rgw_log_object_name_utc

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

ブール値

false

rgw_usage_max_shards

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

整数

32

rgw_usage_max_user_shards

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

整数

1

rgw_enable_ops_log

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

ブール値

false

rgw_enable_usage_log

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

ブール値

false

rgw_ops_log_rados

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

ブール値

true

rgw_ops_log_socket_path

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

文字列

なし

rgw_ops_log_data-backlog

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

整数

5 << 20

rgw_usage_log_flush_threshold

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

整数

1024

rgw_usage_log_tick_interval

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

整数

30

rgw_intent_log_object_name

意図するログメッセージ名のロギング形式。書式指定子の詳細は、man ページの日付を参照してください。

Date

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

rgw_intent_log_object_name_utc

目的のログメッセージ名に UTC 時間が含まれているかどうか。false の場合はローカルタイムを使用します。

ブール値

false

rgw_data_log_window

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

整数

30

rgw_data_log_changes_size

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

整数

1000

rgw_data_log_num_shards

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

整数

128

rgw_data_log_obj_prefix

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

文字列

data_log

rgw_replica_log_obj_prefix

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

文字列

replica log

rgw_md_log_max_shards

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

整数

64

4.5. Keystone の設定

名前詳細デフォルト

rgw_keystone_url

Keystone サーバーの URL。

文字列

なし

rgw_keystone_admin_token

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

文字列

なし

rgw_keystone_accepted_roles

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

文字列

Member, admin

rgw_keystone_token_cache_size

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

整数

10000

rgw_keystone_revocation_interval

トークン失効チェック間の秒数。

整数

15 * 60

4.6. LDAP の設定

名前詳細

rgw_ldap_uri

URI 形式の LDAP サーバーのスペース区切りリスト。

文字列

ldaps://<ldap.your.domain>

rgw_ldap_searchdn

LDAP 検索ドメイン名(ベースドメインとも呼ばれます)。

文字列

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

rgw_ldap_binddn

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

文字列

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

rgw_ldap_secret

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

文字列

/etc/openldap/secret

rgw_ldap_dnattr

Ceph オブジェクトゲートウェイユーザー名を含む LDAP 属性(form binddns)。

文字列

uid

第5章 マルチサイト

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

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

5.1. 要件および前提条件

マルチサイト構成には、Ceph ストレージクラスターが少なくとも 2 つ必要で、Ceph ストレージクラスターごとに 1 つずつ Ceph オブジェクトゲートウェイインスタンスが 2 つ必要です。

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

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

重要

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

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

5.2. プール

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

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

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

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

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

  • .rgw.root
  • us-east.rgw.control
  • us-east.rgw.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. オブジェクトゲートウェイのインストール

Ceph Object Gateway をインストールするには、Red Hat Ceph Storage 4 {install-rhel-guide}[「Red Hat Enterprise Linuxのインストールガイド」]を参照してください。

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

Ansible は、Ceph Storage クラスターで使用するために Ceph Object Gateways をインストールし、設定することができます。マルチサイトおよびマルチサイトグループのデプロイメントでは、ゾーンごとに Ansible を設定する必要があります。

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

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

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

注記

Ansible はゲートウェイが確実に実行されるようにするため、デフォルトのゾーンおよびプールは手動で削除する必要があります。本ガイドでは、これらの手順を説明します。

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

注記

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

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

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

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

5.4.1. レルムの作成

レルムには、ゾーングループおよびゾーンのマルチサイト構成が含まれ、レルム内でグローバルに固有の名前空間を適用するためにも機能します。

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

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

以下に例を示します。

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

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

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

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

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

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

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

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

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

以下に例を示します。

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

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

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

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

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

重要

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

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

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

以下に例を示します。

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

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

重要

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

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

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

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

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

重要

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

# ceph osd pool delete default.rgw.control default.rgw.control --yes-i-really-really-mean-it
# ceph osd pool delete default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-it
# ceph osd pool delete default.rgw.log default.rgw.log --yes-i-really-really-mean-it
# ceph osd pool delete default.rgw.users.uid default.rgw.users.uid --yes-i-really-really-mean-it

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

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

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

以下に例を示します。

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

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

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

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

5.4.6. 周期の更新

マスターゾーン設定を更新したら、期間を更新します。

# radosgw-admin period update --commit
注記

エポックを更新すると、エポックが変更され、他のゾーンが更新された設定を受け取るようになります。

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

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

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

以下に例を示します。

[client.rgw.rgw1.rgw0]
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`.rgw0

5.5. 2 番目のゾーンの確立

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

注記

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

重要

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

5.5.1. レルムのプル

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

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

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

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

5.5.2. 周期のプル

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

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

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

5.5.3. 2 番目のゾーンの作成

重要

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

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

構文

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

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

重要

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

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

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

最後に、Ceph Storage クラスターのデフォルトのプール(必要な場合)を削除します。

# ceph osd pool delete default.rgw.control default.rgw.control --yes-i-really-really-mean-it
# ceph osd pool delete default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-it
# ceph osd pool delete default.rgw.log default.rgw.log --yes-i-really-really-mean-it
# ceph osd pool delete 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.rgw0]
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`.rgw0

5.6. アーカイブ同期モジュールの設定(テクノロジープレビュー)

アーカイブ同期モジュールは、Ceph オブジェクトゲートウェイの S3 オブジェクトのバージョン管理機能を使用してアーカイブゾーンを持ちます。アーカイブゾーンには、アーカイブゾーンに関連付けられたゲートウェイでのみ削除できる S3 オブジェクトの履歴があります。すべてのデータ更新とメタデータを取得して、S3 オブジェクトのバージョンとして統合します。

重要

アーカイブ同期モジュールはテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat の本番環境のサービスレベルアグリーメント(SLA)ではサポートされず、機能的に完全ではないことがあるため、Red Hat では実稼働環境での使用は推奨していません。これらの機能により、今後の製品機能への早期アクセスが可能になり、開発プロセス中に機能のテストやフィードバックの提供が可能になります。詳細は、「Red Hat テクノロジープレビュー機能のサポート範囲」を参照してください。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • root または sudo アクセス
  • Ceph Object Gateway のインストール

手順

  1. archive 階層を使用して新しいゾーンを作成する際に、アーカイブ同期モジュールを設定します。

構文

radosgw-admin zone create --rgw-zonegroup={ZONE_GROUP_NAME} --rgw-zone={ZONE_NAME} --endpoints={http://fqdn:port}[,{http://fqdn:port] --tier-type=archive

[root@master-zone]# radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east --endpoints={http://fqdn:port}[,{http://fqdn:port}] --tier-type=archive

関連情報

5.7. フェイルオーバーおよび災害復旧

マスターゾーンが失敗すると、障害復旧のためにセカンダリーゾーンにフェイルオーバーします。

  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`.rgw0

以前のマスターゾーンが回復する場合は、操作を元に戻します。

  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`.rgw0
  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`.rgw0

5.8. 単一サイトシステムのマルチサイトへの移行

default ゾーングループとゾーンを持つシングルサイトシステムからマルチサイトシステムに移行するには、次の手順を使用します。

  1. レルムを作成します。<name> を、レルム名に置き換えます。

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

    [root@master-zone]# radosgw-admin zonegroup rename --rgw-zonegroup default --zonegroup-new-name=<name>
    [root@master-zone]# radosgw-admin zone rename --rgw-zone default --zone-new-name us-east-1 --rgw-zonegroup=<name>
  3. マスターゾーングループを設定します。<name> を、レルムまたはゾーングループ名に置き換えます。<fqdn> を、ゾーングループの完全修飾ドメイン名に置き換えます。

    [root@master-zone]# radosgw-admin zonegroup modify --rgw-realm=<name> --rgw-zonegroup=<name> --endpoints http://<fqdn>:80 --master --default
  4. マスターゾーンを設定します。<name> を、レルム、ゾーングループ、またはゾーン名に置き換えます。<fqdn> を、ゾーングループの完全修飾ドメイン名に置き換えます。

    [root@master-zone]# radosgw-admin zone modify --rgw-realm=<name> --rgw-zonegroup=<name> \
                                --rgw-zone=<name> --endpoints http://<fqdn>:80 \
                                --access-key=<access-key> --secret=<secret-key> \
                                --master --default
  5. システムユーザーを作成します。<user-id> を、ユーザー名に置き換えます。<display-name> を、表示名に置き換えます。スペースを含めることができます。

    [root@master-zone]# radosgw-admin user create --uid=<user-id> \
                                --display-name="<display-name>" \
                                --access-key=<access-key> --secret=<secret-key> \ --system
  6. 更新された設定をコミットします。

    # radosgw-admin period update --commit
  7. Ceph Object Gateway を再起動します。

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

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

5.9. マルチサイトコマンドラインの使用

5.9.1. レルム

レルムは、1 つ以上のゾーンを含む 1 つ以上のゾーングループとバケットを含むゾーンを含む 1 つ以上のゾーンで構成されるグローバルに固有の namespace を表します。レルムにより、Ceph Object Gateway は、同じハードウェア上で複数の名前空間とそれらの設定をサポートすることができます。

レルムにはピリオドの概念が含まれます。各期間は、ゾーングループおよびゾーン設定の状態(時間単位)を表します。ゾーングループまたはゾーンを変更するたびに、期間を更新してコミットします。

デフォルトでは、Ceph Object Gateway バージョン 2 は、バージョン 1.3 以前のリリースとの後方互換性を確保するためにレルムを作成しません。ただし、Red Hat では、ベストプラクティスとして、新規クラスター用のレルムを作成することを推奨します。

5.9.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.9.1.2. レルムのデフォルトの作成

レルム一覧内のレルムの 1 つがデフォルトのレルムである必要があります。デフォルトレルムは 1 つのみです。レルムが 1 つあり、作成時にデフォルトのレルムとして指定されていない場合は、デフォルトのレルムにします。デフォルトレルムを変更するには、以下を実行します。

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

レルムがデフォルトの場合、コマンドラインでは --rgw-realm=<realm-name> を引数と想定します。

5.9.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.9.1.4. レルムの取得

レルムを取得するには、realm get を実行してレルム名を指定します。

# 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.9.1.5. レルムの設定

レルムを設定するには、realm set を実行し、レルム名を指定し、--infile= を入力ファイル名で指定します。

[root@master-zone]# radosgw-admin realm set --rgw-realm=<name> --infile=<infilename>

以下に例を示します。

[root@master-zone]# radosgw-admin realm set --rgw-realm=movies --infile=filename.json

5.9.1.6. レルムの一覧表示

レルムを一覧表示するには、realm list を実行します。

# radosgw-admin realm list

5.9.1.7. レルム期間の一覧表示

レルムの期間を一覧表示するには、realm list-periods を実行します。

# radosgw-admin realm list-periods

5.9.1.8. レルムのプル

マスターゾーングループとマスターゾーンを含むノードからセカンダリゾーングループまたはゾーンを含むノードにレルムをプルするには、レルム構成を受け取るノードで realm pull を実行します。

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

5.9.1.9. レルムの名前変更

レルムは期間の一部ではありません。そのため、レルムの名前変更はローカルでのみ適用され、realm pull でプルされません。複数のゾーンを持つレルムの名前を変更する場合は、各ゾーンでこのコマンドを実行します。レルムの名前を変更するには、以下を実行します。

# radosgw-admin realm rename --rgw-realm=<current-name> --realm-new-name=<new-realm-name>
注記

realm set を使用して name パラメーターを変更しないでください。これにより、内部名のみが変更されます。--rgw-realm を指定すると、古いレルム名が使用されます。

5.9.2. ゾーングループ

Ceph Object Gateway は、ゾーングループの概念を使用して複数サイトのデプロイメントとグローバル名前空間をサポートします。以前はリージョンと呼ばれていたゾーングループは、1 つ以上のゾーン内の 1 つ以上の Ceph Object Gateway インスタンスの地理的ロケーションを定義します。

ゾーングループの設定は、通常の設定手順とは異なります。これは、すべての設定が Ceph 設定ファイルに残される訳ではありません。ゾーングループを一覧表示し、ゾーングループ設定を取得し、ゾーングループ設定を設定できます。

注記

期間を更新するステップはクラスター全体に変更を伝播するため、 radosgw-admin zonegroup 操作はレルム内の任意のノードで実行できます。ただし、radosgw-admin zone 操作は、ゾーン内のホストで実行する 必要があります

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

ゾーングループの作成は、ゾーングループ名を指定することで構成されます。ゾーンの作成では、--rgw-realm=<realm-name> が指定されていない限り、デフォルトのレルムで実行されていることを前提としています。ゾーングループがデフォルトのゾーングループの場合は、--default フラグを指定します。ゾーングループがマスターゾーングループの場合は、--master フラグを指定します。以下に例を示します。

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

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

5.9.2.2. ゾーングループのデフォルトの作成

ゾーングループの一覧に含まれるゾーングループは、デフォルトのゾーングループである必要があります。デフォルトゾーングループは 1 つのみです。ゾーングループが 1 つあり、作成時にデフォルトのゾーングループとして指定されていない場合は、デフォルトのゾーングループにします。デフォルトである zonegroup を変更するには、次のコマンドを実行します。

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

ゾーングループがデフォルトの場合、コマンドラインは --rgw-zonegroup=<zonegroup-name> を引数として想定します。

次に、期間を更新します。

# radosgw-admin period update --commit

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

ゾーングループにゾーンを追加するには、ゾーンに追加するホストでこの手順を実行する必要があります。ゾーングループにゾーンを追加するには、次のコマンドを実行します。

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

次に、期間を更新します。

# radosgw-admin period update --commit

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

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

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

次に、期間を更新します。

# radosgw-admin period update --commit

5.9.2.5. ゾーングループの名前変更

zonegroup の名前を変更するには、次のコマンドを実行します。

# radosgw-admin zonegroup rename --rgw-zonegroup=<name> --zonegroup-new-name=<name>

次に、期間を更新します。

# radosgw-admin period update --commit

5.9.2.6. ゾーングループの削除

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

# radosgw-admin zonegroup delete --rgw-zonegroup=<name>

次に、期間を更新します。

# radosgw-admin period update --commit

5.9.2.7. ゾーングループの一覧表示

Ceph クラスターにはゾーングループの一覧が含まれます。ゾーングループを一覧表示するには、次のコマンドを実行します。

# radosgw-admin zonegroup list

radosgw-admin は、JSON 形式のゾーングループの一覧を返します。

{
    "default_info": "90b28698-e7c3-462c-a42d-4aa780d24eda",
    "zonegroups": [
        "us"
    ]
}

5.9.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.9.2.9. ゾーングループの設定

ゾーングループの定義は、JSON オブジェクトの作成で構成されており、最低でも必要な設定を指定します。

  1. name: ゾーングループの名前。必須。
  2. api_name: ゾーングループの API 名。任意です。
  3. is_master: ゾーングループがマスターゾーングループであるかどうかを指定します。必須。注記: マスターゾーングループを 1 つだけ指定できます。
  4. endpoints: ゾーングループ内のエンドポイントの一覧。たとえば、複数のドメイン名を使用して、同じゾーングループを参照できます。忘れずに前方スラッシュ (\/) エスケープしてください。各エンドポイントにポート (fqdn:port) を指定することもできます。任意です。
  5. hostnames: ゾーングループのホスト名の一覧。たとえば、複数のドメイン名を使用して、同じゾーングループを参照できます。任意です。rgw dns name 設定は、このリストに自動的に含まれます。この設定を変更したら、ゲートウェイデーモンを再起動する必要があります。
  6. master_zone: ゾーングループのマスターゾーン。任意です。指定されていない場合は、デフォルトゾーンを使用します。注記: ゾーングループごとにマスターゾーンを 1 つだけ指定できます。
  7. zones: ゾーングループ内のゾーンの一覧。各ゾーンには名前(必須)、エンドポイントの一覧(任意)、およびゲートウェイがメタデータおよびデータ操作をログに記録するかどうか(デフォルトでは false)があります。
  8. placement_targets: 配置ターゲットの一覧 (任意)。各配置ターゲットには、配置ターゲットの名前 (必須) とタグのリスト (任意) が含まれているため、タグを持つユーザーのみが配置ターゲットを使用できます (つまり、ユーザー情報のユーザーの placement_tags フィールド)。
  9. default_placement: オブジェクトインデックスおよびオブジェクトデータのデフォルトの配置ターゲット。デフォルトでは default-placement に設定されます。各ユーザーのユーザー情報に、ユーザーごとのデフォルト配置を設定することもできます。

ゾーングループを設定するには、必須フィールドで構成される JSON オブジェクトを作成し、オブジェクトをファイル (たとえば、zonegroup.json) に保存します。次に、次のコマンドを実行します。

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

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

重要

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

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

# radosgw-admin period update --commit

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

ゾーングループマップの設定は、1 つ以上のゾーングループで構成される JSON オブジェクトの作成と、クラスターの master_zonegroupの 設定で構成されます。ゾーングループマップの各ゾーングループは、キーと値のペアで構成されます。key 設定は、個々のゾーングループ構成の 名前 設定と同等であり、val は、個々のゾーングループ構成で構成される JSON オブジェクトです。

is_mastertrue と同等のゾーングループを 1 つだけ持つ可能性があり、ゾーングループマップの最後に master_zonegroup として指定する必要があります。以下の JSON オブジェクトは、デフォルトゾーングループマップの例です。

{
    "zonegroups": [
        {
            "key": "90b28698-e7c3-462c-a42d-4aa780d24eda",
            "val": {
                "id": "90b28698-e7c3-462c-a42d-4aa780d24eda",
                "name": "us",
                "api_name": "us",
                "is_master": "true",
                "endpoints": [
                    "http:\/\/rgw1:80"
                ],
                "hostnames": [],
                "hostnames_s3website": [],
                "master_zone": "9248cab2-afe7-43d8-a661-a40bf316665e",
                "zones": [
                    {
                        "id": "9248cab2-afe7-43d8-a661-a40bf316665e",
                        "name": "us-east",
                        "endpoints": [
                            "http:\/\/rgw1"
                        ],
                        "log_meta": "true",
                        "log_data": "true",
                        "bucket_index_max_shards": 0,
                        "read_only": "false"
                    },
                    {
                        "id": "d1024e59-7d28-49d1-8222-af101965a939",
                        "name": "us-west",
                        "endpoints": [
                            "http:\/\/rgw2:80"
                        ],
                        "log_meta": "false",
                        "log_data": "true",
                        "bucket_index_max_shards": 0,
                        "read_only": "false"
                    }
                ],
                "placement_targets": [
                    {
                        "name": "default-placement",
                        "tags": []
                    }
                ],
                "default_placement": "default-placement",
                "realm_id": "ae031368-8715-4e27-9a99-0c9468852cfe"
            }
        }
    ],
    "master_zonegroup": "90b28698-e7c3-462c-a42d-4aa780d24eda",
    "bucket_quota": {
        "enabled": false,
        "max_size_kb": -1,
        "max_objects": -1
    },
    "user_quota": {
        "enabled": false,
        "max_size_kb": -1,
        "max_objects": -1
    }
}

ゾーングループマップを設定するには、次のコマンドを実行します。

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

ここで、zonegroupmap.json は作成した JSON ファイルです。ゾーングループマップで指定されたゾーンが作成されていることを確認します。最後に、期間を更新します。

# radosgw-admin period update --commit

5.9.3. ゾーン

Ceph Object Gateway はゾーンの概念をサポートします。ゾーンは、1 つ以上の Ceph Object Gateway インスタンスで構成される論理グループを定義します。

ゾーンの設定は、Ceph 設定ファイル内のすべての設定が終わる訳ではないので、通常の設定手順とは異なります。ゾーンの一覧表示、ゾーン設定の取得、ゾーン設定の設定を行うことができます。

重要

radosgw-admin zone 操作はすべて、ゾーン内で動作するまたはこれから動作するホストで実行する 必要があります

5.9.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.9.3.2. ゾーンの削除

ゾーンを削除するには、最初にゾーングループから削除します。

# 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 に他のアクティブなレルムが含まれていないことを確認します。

# ceph osd pool delete <del-zone>.rgw.control <del-zone>.rgw.control --yes-i-really-really-mean-it
# ceph osd pool delete <del-zone>.rgw.data.root <del-zone>.rgw.data.root --yes-i-really-really-mean-it
# ceph osd pool delete <del-zone>.rgw.log <del-zone>.rgw.log --yes-i-really-really-mean-it
# ceph osd pool delete <del-zone>.rgw.users.uid <del-zone>.rgw.users.uid --yes-i-really-really-mean-it

5.9.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.9.3.4. ゾーンの一覧

root でクラスター内のゾーンを一覧表示するには、以下を実行します。

# radosgw-admin zone list

5.9.3.5. ゾーンの取得

root でゾーンの設定を取得するには、次のコマンドを実行します。

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

default ゾーンは以下のようになります。

{ "domain_root": ".rgw",
  "control_pool": ".rgw.control",
  "gc_pool": ".rgw.gc",
  "log_pool": ".log",
  "intent_log_pool": ".intent-log",
  "usage_log_pool": ".usage",
  "user_keys_pool": ".users",
  "user_email_pool": ".users.email",
  "user_swift_pool": ".users.swift",
  "user_uid_pool": ".users.uid",
  "system_key": { "access_key": "", "secret_key": ""},
  "placement_pools": [
      {  "key": "default-placement",
         "val": { "index_pool": ".rgw.buckets.index",
                  "data_pool": ".rgw.buckets"}
      }
    ]
  }

5.9.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 ファイルです。

次に、root でピリオドを更新します。

# radosgw-admin period update --commit

5.9.3.7. ゾーンの名前変更

ゾーンの名前を変更するには、ゾーン名と新しいゾーン名を指定します。ゾーン内のホストで以下のコマンドを実行します。

[root@zone]# radosgw-admin zone rename --rgw-zone=<name> --zone-new-name=<name>

次に、期間を更新します。

# radosgw-admin period update --commit

5.10. ゾーングループおよびゾーン設定

デフォルトゾーングループおよびゾーンを設定する場合、プール名にはゾーン名が含まれます。以下に例を示します。

  • default.rgw.control

デフォルトを変更するには、各 [client.rgw.{instance-name}] インスタンスの配下にある Ceph 設定ファイルに以下の設定を追加します。

名前詳細デフォルト

rgw_zone

ゲートウェイインスタンスのゾーン名。

文字列

なし

rgw_zonegroup

ゲートウェイインスタンスのゾーングループの名前。

文字列

なし

rgw_zonegroup_root_pool

ゾーングループの root プール。

文字列

.rgw.root

rgw_zone_root_pool

ゾーンのルートプール。

文字列

.rgw.root

rgw_default_zone_group_info_oid

デフォルトゾーングループを保存するための OID。この設定を変更することは推奨していません。

文字列

default.zonegroup

rgw_num_zone_opstate_shards

ゾーン間グループの同期の進捗を維持するためのシャードの最大数。

整数

128

5.11. マルチサイトでの手動によるバケットのリシャード化

Red Hat Ceph Storage は、マルチサイトクラスターの動的なバケットリシャード化をサポート しません。マルチサイトクラスターでシャードバケットを手動でリシャードするには、以下の手順を使用します。

注記

手動によるリシャード化は、特に手動のリシャードを保証する大規模なバケットについて非常にコストのかかるプロセスです。すべてのセカンダリーゾーンはすべてのオブジェクトを削除してから、マスターゾーンからそれらを再同期します。

前提条件

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

手順

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

    構文

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

    すべてのゾーンsync status が、データの同期が最新であることを報告するのを待ちます。

  2. すべて のゾーンで すべてceph-radosgw デーモンを停止します。
  3. マスターゾーングループのマスターゾーン内のノードで、バケットを再シャードします。

    構文

    # radosgw-admin bucket reshard --bucket=BUCKET_NAME --num-shards=NEW_SHARDS_NUMBER

  4. セカンダリーゾーンで、以下を実行します。

    構文

    # radosgw-admin bucket rm --purge-objects --bucket=BUCKET_NAME

  5. すべて のゾーンで すべてceph-radosgw デーモンを再起動します。
  6. マスターゾーングループのマスターゾーン内のノードで、以下のコマンドを実行します。

    構文

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

メタデータ同期プロセスは、更新されたバケットエントリーポイントおよびバケットインスタンスのメタデータを取得します。データ同期プロセスは完全な同期を実行します。

関連情報

5.12. レプリケーションのない複数ゾーンの設定

相互に複製しない複数のゾーンを設定できます。たとえば、会社内の各チーム専用ゾーンを作成できます。

前提条件

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

手順

  1. レルムを作成します。

    radosgw-admin realm create --rgw-realm=realm-name [--default]

    以下に例を示します。

    [root@master-zone]# radosgw-admin realm create --rgw-realm=movies --default
    {
        "id": "0956b174-fe14-4f97-8b50-bb7ec5e1cf62",
        "name": "movies",
        "current_period": "1950b710-3e63-4c41-a19e-46a715000980",
        "epoch": 1
    }
  2. ゾーングループを作成します。

    radosgw-admin zonegroup create --rgw-zonegroup=zone-group-name --endpoints=url [--rgw-realm=realm-name|--realm-id=realm-id] --master --default

    以下に例を示します。

    [root@master-zone]# radosgw-admin zonegroup create --rgw-zonegroup=us --endpoints=http://rgw1:80 --rgw-realm=movies --master --default
    {
        "id": "f1a233f5-c354-4107-b36c-df66126475a6",
        "name": "us",
        "api_name": "us",
        "is_master": "true",
        "endpoints": [
            "http:\/\/rgw1:80"
        ],
        "hostnames": [],
        "hostnames_s3webzone": [],
        "master_zone": "",
        "zones": [],
        "placement_targets": [],
        "default_placement": "",
        "realm_id": "0956b174-fe14-4f97-8b50-bb7ec5e1cf62"
    }
  3. ユースケースに応じて、ゾーンを 1 つ以上作成します。

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

    以下に例を示します。

    [root@master-zone]# radosgw-admin zone create --rgw-zonegroup=us \
                                                  --rgw-zone=us-east \
                                                  --master --default \
                                                  --endpoints=http://rgw1:80
  4. ゾーングループの設定が含まれる JSON ファイルを取得します。

    radosgw-admin zonegroup get --rgw-zonegroup=zone-group-name > zonegroup.json

    以下に例を示します。

    [root@master-zone]# radosgw-admin zonegroup get --rgw-zonegroup=us > zonegroup.json
  5. ファイルで、log_meta パラメーター、log_data パラメーター、および sync_from_all パラメーターを false に設定します。

        {
            "id": "72f3a886-4c70-420b-bc39-7687f072997d",
            "name": "default",
            "api_name": "",
            "is_master": "true",
            "endpoints": [],
            "hostnames": [],
            "hostnames_s3website": [],
            "master_zone": "a5e44ecd-7aae-4e39-b743-3a709acb60c5",
            "zones": [
                {
                    "id": "975558e0-44d8-4866-a435-96d3e71041db",
                    "name": "testzone",
                    "endpoints": [],
                    "log_meta": "false",
                    "log_data": "false",
                    "bucket_index_max_shards": 0,
                    "read_only": "false",
                    "tier_type": "",
                    "sync_from_all": "false",
                    "sync_from": []
                },
                {
                    "id": "a5e44ecd-7aae-4e39-b743-3a709acb60c5",
                    "name": "default",
                    "endpoints": [],
                    "log_meta": "false",
                    "log_data": "false",
                    "bucket_index_max_shards": 0,
                    "read_only": "false",
                    "tier_type": "",
                    "sync_from_all": "false",
                    "sync_from": []
                }
            ],
            "placement_targets": [
                {
                    "name": "default-placement",
                    "tags": []
                }
            ],
            "default_placement": "default-placement",
            "realm_id": "2d988e7d-917e-46e7-bb18-79350f6a5155"
        }
  6. 更新された JSON ファイルを使用します。

    radosgw-admin zonegroup set --rgw-zonegroup=zone-group-name --infile=zonegroup.json

    以下に例を示します。

    [root@master-zone]# radosgw-admin zonegroup set --rgw-zonegroup=us --infile=zonegroup.json
  7. 期間を更新します。

    # radosgw-admin period update --commit

5.13. 同じストレージクラスターでの複数のレルムの設定

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

注記

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

前提条件

  • ストレージクラスター内の各データセンターのアクセスキーおよびシークレットキー。
  • ストレージクラスターで稼働中の Red Hat Ceph Storage データセンター 2 つ。
  • 各データセンターには独自のローカルレルムがあります。これらは両方のサイトで複製されるレルムを共有します。
  • Ceph Object Gateway ノード上で、『Red Hat Ceph Storage インストールガイド』「Red Hat Ceph Storage のインストール要件」に記載のタスクを実行します。
  • 各 Ceph Object Gateway ノードについて、『Red Hat Ceph Storage インストールガイド』「Ceph Object Gateway のインストール」セクションに記載のステップ 1 から 7 を実施します。

手順

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

    構文

    radosgw-admin user create --uid="SYNCHRONIZATION_USER" --display-name="Synchronization User" --system

  2. ストレージクラスター内の最初のデータセンターに、ローカルレルムを 1 つ作成します。

    構文

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

    [user@rgw1]$ radosgw-admin realm create --rgw-realm=ldc1 --default

  3. 最初のデータセンターに、ローカルのマスターゾーングループを 1 つ作成します。

    構文

    radosgw-admin zonegroup create --rgw-zonegroup=ZONE_GROUP_NAME --endpoints=http://RGW_NODE_NAME:80 --rgw-realm=REALM_NAME --master --default

    [user@rgw1]$ radosgw-admin zonegroup create --rgw-zonegroup=ldc1zg --endpoints=http://rgw1:80 --rgw-realm=ldc1 --master --default

  4. 最初のデータセンターにローカルゾーンを 1 つ作成します。

    構文

    radosgw-admin zone create --rgw-zonegroup=ZONE_GROUP_NAME --rgw-zone=ZONE_NAME --master --default --endpoints=HTTP_FQDN[,HTTP_FQDN]

    [user@rgw1]$ radosgw-admin zone create --rgw-zonegroup=ldc1zg --rgw-zone=ldc1z --master --default --endpoints=http://rgw.example.com

  5. 期間をコミットします。

    [user@rgw1]$ radosgw-admin period update --commit

  6. ceph.conf を、rgw_realm 名、rgw_zonegroup 名、および rgw_zone 名で更新します。

    構文

    rgw_realm = REALM_NAME
    rgw_zonegroup = ZONE_GROUP_NAME
    rgw_zone = ZONE_NAME

    rgw_realm = ldc1
    rgw_zonegroup = ldc1zg
    rgw_zone = ldc1z

  7. RGW デーモンを再起動します。

    構文

    systemctl restart ceph-radosgw@rgw.$(hostname -s).rgw0.service

  8. ストレージクラスター内の 2 番目のデータセンターに 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.conf を、rgw_realm 名、rgw_zonegroup 名、および rgw_zone 名で更新します。

    構文

    rgw_realm = REALM_NAME
    rgw_zonegroup = ZONE_GROUP_NAME
    rgw_zone = ZONE_NAME

    rgw_realm = ldc2
    rgw_zonegroup = ldc2zg
    rgw_zone = ldc2z

  13. RGW デーモンを再起動します。

    構文

    systemctl restart ceph-radosgw@rgw.$(hostname -s).rgw0.service

  14. レプリケーション/同期ユーザーを作成します。

    構文

    radosgw-admin user create --uid="r_REPLICATION_SYNCHRONIZATION_USER_" --display-name="Replication-Synchronization User" --system

  15. ストレージクラスター内の最初のデータセンターに複製されたレルムを作成します。

    構文

    radosgw-admin realm create --rgw-realm=REPLICATED_REALM_1

    [user@rgw1] radosgw-admin realm create --rgw-realm=rdc1

  16. 最初のデータセンターのマスターゾーングループを作成します。

    構文

    radosgw-admin zonegroup create --rgw-zonegroup=RGW_ZONE_GROUP --endpoints=http://_RGW_NODE_NAME:80 --rgw-realm=_RGW_REALM_NAME --master --default

    [user@rgw1] radosgw-admin zonegroup create --rgw-zonegroup=rdc1zg --endpoints=http://rgw1:80 --rgw-realm=rdc1 --master --default

  17. 最初のデータセンターにマスターゾーンを作成します。

    構文

    radosgw-admin zone create --rgw-zonegroup=RGW_ZONE_GROUP --rgw-zone=_MASTER_RGW_NODE_NAME --master --default --endpoints=HTTP_FQDN[,HTTP_FQDN]

    [user@rgw1] radosgw-admin zone create --rgw-zonegroup=rdc1zg --rgw-zone=rdc1z --master --default --endpoints=http://rgw.example.com

  18. 期間をコミットします。

    構文

    radosgw-admin period update --commit

  19. 最初のデータセンターの rgw_realm 名、rgw_zonegroup 名、および rgw_zone 名で ceph.conf を更新します。

    構文

    rgw_realm = REALM_NAME
    rgw_zonegroup = ZONE_GROUP_NAME
    rgw_zone = ZONE_NAME

    rgw_realm = rdc1
    rgw_zonegroup = rdc1zg
    rgw_zone = rdc1z

  20. RGW デーモンを再起動します。

    構文

    systemctl restart ceph-radosgw@rgw.$(hostname -s).rgw0.service

  21. 2 番目のデータセンターで複製されたレルムをプルします。

    構文

    radosgw-admin realm pull --url=https://tower-osd1.cephtips.com --access-key=ACCESS_KEY --secret-key=SECRET_KEY

    radosgw-admin realm pull --url=https://tower-osd1.cephtips.com --access-key=3QV0D6ZMMCJZMSCXJ2QJ --secret-key=VpvQWcsfI9OPzUCpR4kynDLAbqa1OIKqRB6WEnH8

  22. 最初のデータセンターから期間をプルします。

    構文

    radosgw-admin period pull --url=https://tower-osd1.cephtips.com --access-key=ACCESS_KEY --secret-key=SECRET_KEY

    radosgw-admin period pull --url=https://tower-osd1.cephtips.com --access-key=3QV0D6ZMMCJZMSCXJ2QJ --secret-key=VpvQWcsfI9OPzUCpR4kynDLAbqa1OIKqRB6WEnH8

  23. 2 番目のデータセンターにセカンダリーゾーンを作成します。

    構文

    radosgw-admin zone create --rgw-zone=RGW_ZONE --rgw-zonegroup=RGW_ZONE_GROUP --endpoints=https://tower-osd4.cephtips.com --access-key=_ACCESS_KEY --secret-key=SECRET_KEY

    [user@rgw2] radosgw-admin zone create --rgw-zone=rdc2z --rgw-zonegroup=rdc1zg --endpoints=https://tower-osd4.cephtips.com --access-key=3QV0D6ZMMCJZMSCXJ2QJ --secret-key=VpvQWcsfI9OPzUCpR4kynDLAbqa1OIKqRB6WEnH8

  24. 期間をコミットします。

    構文

    radosgw-admin period update --commit

  25. 2 番目のデータセンターの rgw_realm 名、rgw_zonegroup 名、および rgw_zone 名を持つ ceph.conf を更新します。

    構文

    rgw_realm = REALM_NAME
    rgw_zonegroup = ZONE_GROUP_NAME
    rgw_zone = ZONE_NAME

    rgw realm = rdc1
    rgw zonegroup = rdc1zg
    rgw zone = rdc2z

  26. RGW デーモンを再起動します。

    構文

    systemctl restart ceph-radosgw@rgw.$(hostname -s).rgw0.service

  27. 2 番目のデータセンターのエンドポイントに root としてログインします。
  28. マスターレルムで同期ステータスを確認します。

    構文

    radosgw-admin sync status

    [root@tower-osd4 ceph-ansible]# radosgw-admin sync status
              realm 59762f08-470c-46de-b2b1-d92c50986e67 (ldc2)
          zonegroup 7cf8daf8-d279-4d5c-b73e-c7fd2af65197 (ldc2zg)
               zone 034ae8d3-ae0c-4e35-8760-134782cb4196 (ldc2z)
      metadata sync no sync (zone is master)

  29. 最初のデータセンターのエンドポイントに root としてログインします。
  30. replication-syncation レルムの同期ステータスを確認します。

    構文

    radosgw-admin sync status --rgw-realm RGW_REALM_NAME

    以下に例を示します。

    [root@tower-osd4 ceph-ansible]# [root@tower-osd4 ceph-ansible]# radosgw-admin sync status --rgw-realm rdc1
              realm 73c7b801-3736-4a89-aaf8-e23c96e6e29d (rdc1)
          zonegroup d67cc9c9-690a-4076-89b8-e8127d868398 (rdc1zg)
               zone 67584789-375b-4d61-8f12-d1cf71998b38 (rdc2z)
      metadata sync syncing
                    full sync: 0/64 shards
                    incremental sync: 64/64 shards
                    metadata is caught up with master
          data sync source: 705ff9b0-68d5-4475-9017-452107cec9a0 (rdc1z)
                            syncing
                            full sync: 0/128 shards
                            incremental sync: 128/128 shards
                            data is caught up with source
              realm 73c7b801-3736-4a89-aaf8-e23c96e6e29d (rdc1)
          zonegroup d67cc9c9-690a-4076-89b8-e8127d868398 (rdc1zg)
               zone 67584789-375b-4d61-8f12-d1cf71998b38 (rdc2z)
      metadata sync syncing
                    full sync: 0/64 shards
                    incremental sync: 64/64 shards
                    metadata is caught up with master
          data sync source: 705ff9b0-68d5-4475-9017-452107cec9a0 (rdc1z)
                            syncing
                            full sync: 0/128 shards
                            incremental sync: 128/128 shards
                            data is caught up with source
  31. ローカルサイトにデータを保存し、アクセスするには、ローカルレルムのユーザーを作成します。

    radosgw-admin user create --uid="LOCAL_USER" --display-name="Local user" --rgw-realm=_REALM_NAME --rgw-zonegroup=ZONE_GROUP_NAME --rgw-zone=ZONE_NAME

    [user@rgw2] #radosgw-admin user create --uid="local-user" --display-name="Local user" --rgw-realm=ldc1 --rgw-zonegroup=ldc1zg --rgw-zone=ldc1z

重要

デフォルトでは、ユーザーはマルチサイト設定に追加されます。ユーザーがローカルゾーン内のデータにアクセスするには、radosgw-admin コマンドに --rgw-realm 引数が必要です。

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.