適用項目 SUSE Enterprise Storage 7.1

21 Ceph Object Gateway #

この章では、サービスの状態の確認、アカウントの管理、マルチサイトゲートウェイ、LDAP認証など、Object Gatewayに関連する管理タスクについて詳しく説明します。

21.1 Object Gatewayの制約と命名の制限 #

次に、Object Gatewayの重要な制限のリストを示します。

21.1.1 バケットの制限 #

S3 API経由でObject Gatewayに接続する場合、バケット名はDNSに準拠した名前(ダッシュ文字「-」は使用可能)に制限されます。Swift API経由でObject Gatewayに接続する場合は、UTF-8でサポートされている文字(スラッシュ文字「/」を除く)を自由に組み合わせて使用できます。バケット名の最大長は255文字です。バケット名は固有でなければなりません。

ヒント: DNSに準拠したバケット名

Swift API経由ではUTF-8ベースのバケット名を使用できますが、同じバケットにS3 API経由でアクセスする際に問題が起きないよう、バケットにはS3の命名制限に従った名前を付けることをお勧めします。

21.1.2 保存オブジェクトの制限 #

ユーザあたりのオブジェクトの最大数: デフォルトでは制限はありません(最大2^63に制限)。
バケットあたりのオブジェクトの最大数: デフォルトでは制限はありません(最大2^63に制限)。
アップロード/保存するオブジェクトの最大サイズ: 1回のアップロードは5GBに制限されます。これより大きいオブジェクトサイズにはマルチパートを使用してください。マルチパートチャンクの最大数は10000です。

21.1.3 HTTPヘッダの制限 #

HTTPヘッダと要求の制限は、使用するWebフロントエンドによって異なります。デフォルトのBeastでは、HTTPヘッダのサイズは16kBに制限されています。

21.2 Object Gatewayの展開 #

Ceph Object Gatewayの展開方法は、その他のCephサービスの展開手順と同じ、つまりcephadmを使用します。詳細については、8.2項「サービス仕様と配置仕様」、また、具体的には8.3.4項「Object Gatewayの展開」を参照してください。

21.3 Object Gatewayサービスの操作 #

その他のCephサービスと同じようにObject Gatewayを操作できます。その場合、まず、ceph orch psコマンドを使用してサービス名を特定し、次のコマンドを実行してサービスを操作します。次に例を示します。

ceph orch daemon restart OGW_SERVICE_NAME

Cephサービスの操作の詳細については、第14章「Cephサービスの運用」を参照してください。

21.4 設定オプション #

Object Gatewayの設定オプションのリストについては、28.5項「Ceph Object Gateway」を参照してください。

21.5 Object Gatewayのアクセスの管理 #

S3またはSwiftと互換性のあるインタフェースを使用してObject Gatewayと通信できます。S3インタフェースは、Amazon S3 RESTful APIの大規模なサブセットと互換性があります。Swiftインタフェースは、OpenStack Swift APIの大規模なサブセットと互換性があります。

どちらのインタフェースも、ユーザの秘密鍵を使用してゲートウェイと通信するには、特定のユーザを作成し、関連するクライアントソフトウェアをインストールする必要があります。

21.5.1 Object Gatewayへのアクセス #

21.5.1.1 S3インタフェースへのアクセス #

S3インタフェースにアクセスするには、RESTクライアントが必要です。S3cmdはコマンドラインのS3クライアントです。これは、OpenSUSEビルドサービスにあります。このリポジトリには、SUSE Linux EnterpriseベースおよびopenSUSEベースの両方の配布パッケージ用のバージョンがあります。

S3インタフェースへのアクセスをテストする場合、簡単なPythonスクリプトを作成することもできます。このスクリプトは、Object Gatewayに接続して新しいバケットを作成し、すべてのバケットを一覧にします。aws_access_key_idおよびaws_secret_access_keyの値は、21.5.2.1項「S3およびSwiftユーザの追加」のradosgw_adminコマンドによって返されるaccess_keyおよびsecret_keyの値から取得されます。

python-botoパッケージをインストールします。
```
# zypper in python-boto
```

次の内容で、s3test.pyという名前の新しいPythonスクリプトを作成します。

import boto
import boto.s3.connection
access_key = '11BS02LGFB6AL6H1ADMW'
secret_key = 'vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY'
conn = boto.connect_s3(
aws_access_key_id = access_key,
aws_secret_access_key = secret_key,
host = 'HOSTNAME',
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\tCREATED".format(
  name = bucket.name,
  created = bucket.creation_date,
  )

HOSTNAMEは、Object Gatewayサービスを設定したホストのホスト名に置き換えてください。たとえば、gateway_hostです。

スクリプトを実行します。
```
python s3test.py
```
次のような内容が出力されます。
```
my-new-bucket 2015-07-22T15:37:42.000Z
```

21.5.1.2 Swiftインタフェースへのアクセス #

SwiftインタフェースでObject Gatewayにアクセスするには、swiftコマンドラインクライアントが必要です。コマンドラインオプションについては、マニュアルページman 1 swiftを参照してください。

このパッケージは、SP3以降のSUSE Linux Enterprise 12およびSUSE Linux Enterprise 15の「パブリッククラウド」モジュールに含まれています。パッケージをインストールする前に、このモジュールを有効にしてソフトウェアリポジトリを更新する必要があります。

# SUSEConnect -p sle-module-public-cloud/12/SYSTEM-ARCH
sudo zypper refresh

または

# SUSEConnect -p sle-module-public-cloud/15/SYSTEM-ARCH
# zypper refresh

swiftコマンドをインストールするには、次のコマンドを実行します。

# zypper in python-swiftclient

Swiftにアクセスするには、次の構文を使用します。

> swift -A http://IP_ADDRESS/auth/1.0 \
-U example_user:swift -K 'SWIFT_SECRET_KEY' list

IP_ADDRESSは、ゲートウェイサーバのIPアドレスに置き換えてください。SWIFT_SECRET_KEYは、21.5.2.1項「S3およびSwiftユーザの追加」でswiftユーザを対象に実行したradosgw-admin key createコマンドの出力の値に置き換えてください。

例:

> swift -A http://gateway.example.com/auth/1.0 -U example_user:swift \
-K 'r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h' list

出力は次のとおりです。

my-new-bucket

21.5.2 S3およびSwiftアカウントの管理 #

21.5.2.1 S3およびSwiftユーザの追加 #

エンドユーザがゲートウェイを操作できるようにするには、ユーザ、アクセスキー、および秘密を作成する必要があります。ユーザには、「ユーザ」と「サブユーザ」の2種類があります。「ユーザ」はS3インタフェースを操作する場合に使用し、「サブユーザ」はSwiftインタフェースのユーザです。各サブユーザは特定のユーザに関連付けられます。

Swiftユーザを作成するには、次の手順に従います。

Swiftユーザ(ここでの用語では「サブユーザ」)を作成するために、まず関連付けられた「ユーザ」を作成する必要があります。

cephuser@adm > radosgw-admin user create --uid=USERNAME \
 --display-name="DISPLAY-NAME" --email=EMAIL

例:

cephuser@adm > radosgw-admin user create \
   --uid=example_user \
   --display-name="Example User" \
   --email=penguin@example.com

このユーザのサブユーザ(Swiftインタフェース)を作成するために、ユーザID (--uid=USERNAME)、サブユーザID、およびサブユーザのアクセスレベルを指定する必要があります。

cephuser@adm > radosgw-admin subuser create --uid=UID \
 --subuser=UID \
 --access=[ read | write | readwrite | full ]

例:

cephuser@adm > radosgw-admin subuser create --uid=example_user \
 --subuser=example_user:swift --access=full

ユーザの秘密鍵を生成します。

cephuser@adm > radosgw-admin key create \
   --gen-secret \
   --subuser=example_user:swift \
   --key-type=swift

どちらのコマンドでも、ユーザの状態を示すJSON形式のデータが出力されます。次の行に注意し、secret_keyの値を覚えます。
```
"swift_keys": [
   { "user": "example_user:swift",
     "secret_key": "r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h"}],
```

S3インタフェースを介してObject Gatewayにアクセスする場合、次のコマンドを実行してS3ユーザを作成する必要があります。

cephuser@adm > radosgw-admin user create --uid=USERNAME \
 --display-name="DISPLAY-NAME" --email=EMAIL

例:

cephuser@adm > radosgw-admin user create \
   --uid=example_user \
   --display-name="Example User" \
   --email=penguin@example.com

このコマンドは、ユーザのアクセスキーと秘密鍵も生成します。access_keyおよびsecret_keyのキーワードの出力とそれらの値を確認します。

[...]
 "keys": [
       { "user": "example_user",
         "access_key": "11BS02LGFB6AL6H1ADMW",
         "secret_key": "vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY"}],
 [...]

21.5.2.2 S3およびSwiftユーザの削除 #

ユーザを削除する手順は、S3ユーザでもSwiftユーザでも同様です。ただし、Swiftユーザの場合、そのサブユーザを含むユーザを削除する必要があります。

S3またはSwiftユーザ(その全サブユーザを含む)を削除するには、次のコマンドでuser rmとユーザIDを指定します。

cephuser@adm > radosgw-admin user rm --uid=example_user

サブユーザを削除するには、subuser rmとサブユーザIDを指定します。

cephuser@adm > radosgw-admin subuser rm --uid=example_user:swift

次のオプションを利用できます。

--purge-data: ユーザIDに関連付けられたすべてのデータをパージします。
--purge-keys: ユーザIDに関連付けられたすべてのキーをパージします。

ヒント: サブユーザの削除

サブユーザを削除すると、Swiftインタフェースへのアクセスも削除されます。そのユーザはシステムに残ります。

21.5.2.3 S3およびSwiftユーザのアクセスキーと秘密鍵の変更 #

access_keyおよびsecret_keyのパラメータは、ゲートウェイにアクセスする際にObject Gatewayユーザを識別します。既存のユーザのキーを削除すると、古いキーは上書きされます。そのため、これは新しいユーザを作成することと同じです。

S3ユーザの場合、次のコマンドを実行します。

cephuser@adm > radosgw-admin key create --uid=EXAMPLE_USER --key-type=s3 --gen-access-key --gen-secret

Swiftユーザの場合、次のコマンドを実行します。

cephuser@adm > radosgw-admin key create --subuser=EXAMPLE_USER:swift --key-type=swift --gen-secret

--key-type=TYPE: キーのタイプを指定します。swiftまたはs3です。
--gen-access-key: ランダムなアクセスキーを生成します(デフォルトではS3ユーザ用)。
--gen-secret: ランダムな秘密鍵を生成します。
--secret=KEY: 秘密鍵を指定します。たとえば、手動で生成した秘密鍵を指定します。

21.5.2.4 ユーザクォータの管理の有効化 #

Ceph Object Gatewayでは、ユーザと、ユーザが所有するバケットにクォータを設定できます。バケット内のオブジェクトの最大数や、最大ストレージサイズ(メガバイト単位)などのクォータがあります。

ユーザクォータを有効にする前に、まずそのパラメータを設定する必要があります。

cephuser@adm > radosgw-admin quota set --quota-scope=user --uid=EXAMPLE_USER \
 --max-objects=1024 --max-size=1024

--max-objects: オブジェクトの最大数を指定します。負の値を指定すると、クォータの確認が無効になります。
--max-size: 最大バイト数を指定します。負の値を指定すると、クォータの確認が無効になります。
--quota-scope: クォータのスコープを設定します。オプションはbucketおよびuserです。バケットクォータは、ユーザが所有するバケットに適用されます。ユーザクォータはユーザに適用されます。

ユーザクォータを選択したら、そのクォータを有効にできます。

cephuser@adm > radosgw-admin quota enable --quota-scope=user --uid=EXAMPLE_USER

クォータを無効にするには、次のコマンドを実行します。

cephuser@adm > radosgw-admin quota disable --quota-scope=user --uid=EXAMPLE_USER

クォータの設定を一覧にするには、次のコマンドを実行します。

cephuser@adm > radosgw-admin user info --uid=EXAMPLE_USER

クォータの統計を更新するには、次のコマンドを実行します。

cephuser@adm > radosgw-admin user stats --uid=EXAMPLE_USER --sync-stats

21.6 HTTPフロントエンド #

Ceph Object Gatewayは、2つの埋め込みHTTPフロントエンド(「Beast」と「Civetweb」)をサポートしています。

Beastフロントエンドは、HTTPの解析のためにBoost.Beastライブラリを使用し、非同期ネットワークI/OのためにBoost.Asioライブラリを使用します。

Civetwebフロントエンドは、MongooseのフォークであるCivetweb HTTPライブラリを使用します。

これらはrgw_frontendsオプションを使用して設定できます。設定オプションのリストについては、28.5項「Ceph Object Gateway」を参照してください。

21.7 Object GatewayでのHTTPS/SSLの有効化 #

Object Gatewayを有効にしてSSLで安全に通信するには、CAによって発行された証明書を持っているか、自己署名証明書を作成する必要があります。

21.7.1 自己署名証明書の作成 #

ヒント

CAによって署名された有効な証明書をすでに持っている場合、このセクションはスキップしてください。

次の手順では、Salt Master上で自己署名SSL証明書を生成する方法について説明します。

Object Gatewayを追加のサブジェクトIDで認識する必要がある場合は、それらを/etc/ssl/openssl.cnfファイルの[v3_req]セクションのsubjectAltNameオプションに追加します。
```
[...]
[ v3_req ]
subjectAltName = DNS:server1.example.com DNS:server2.example.com
[...]
```
ヒント: subjectAltNameのIPアドレス
subjectAltNameオプションのドメイン名の代わりにIPアドレスを使用するには、上の例に示されている行を以下で置き換えてください。
```
subjectAltName = IP:10.0.0.10 IP:10.0.0.11
```
opensslを使用して、キーと証明書を作成します。証明書に含める必要があるデータをすべて入力します。FQDNを一般名として入力することをお勧めします。証明書に署名する前に、「Requested Extensions」に「X509v3 Subject Alternative Name:」が含まれていること、および生成された証明書に「X509v3 Subject Alternative Name:」が設定されていることを確認します。
```
root@master # openssl req -x509 -nodes -days 1095 \
 -newkey rsa:4096 -keyout rgw.key
 -out rgw.pem
```
キーを証明書ファイルに追加します。
```
root@master # cat rgw.key >> rgw.pem
```

21.7.2 SSLを使用するようにObject Gatewayを設定する #

SSL証明書を使用するようにObject Gatewayを設定するには、rgw_frontendsオプションを使用します。例:

cephuser@adm > ceph config set WHO rgw_frontends \
 beast ssl_port=443 ssl_certificate=config://CERT ssl_key=config://KEY

CERTとKEYの設定キーを指定しない場合、Object Gatewayサービスは、次の設定キーの下にあるSSL証明書およびキーを探します。

rgw/cert/RGW_REALM/RGW_ZONE.key
rgw/cert/RGW_REALM/RGW_ZONE.crt

デフォルトのSSLキーおよび証明書の場所を上書きする場合、次のコマンドを使用してそれらを設定データベースにインポートします。

ceph config-key set CUSTOM_CONFIG_KEY -i PATH_TO_CERT_FILE

config://ディレクティブを使用してカスタム設定キーを使用します。

21.8 同期モジュール #

Object Gatewayは、マルチサイトサービスとして展開されます。また、データおよびメタデータをゾーン間でミラーリングできます。「同期モジュール」は、データとメタデータを別の外部層へ転送できるようにするマルチサイトフレームワーク上に構築されています。同期モジュールにより、データの変更が発生した場合に一連のアクションを実行できます(たとえば、バケットやユーザの作成などのメタデータの操作)。Object Gatewayでのマルチサイトの変更は最終的にリモートサイトで一貫性が保たれるので、変更は非同期で伝搬されます。これは、外部のクラウドクラスタへのObject Storageのバックアップ、テープドライブを使用するカスタムバックアップソリューション、ElasticSearchでのメタデータのインデックス作成といった使用事例に対応しています。

21.8.1 同期モジュールの設定 #

すべての同期モジュールは同様の方法で設定します。新しいゾーンを作成し(詳細については21.13項「マルチサイトObject Gateway」を参照)、その--tier_typeオプションを設定する必要があります。たとえば、クラウド同期モジュールの場合は、--tier-type=cloudに設定します。

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --endpoints=http://endpoint1.example.com,http://endpoint2.example.com, [...] \
 --tier-type=cloud

次のコマンドを使用して特定の層を設定できます。

cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=KEY1=VALUE1,KEY2=VALUE2

設定のKEYには更新する設定変数を指定し、VALUEにその新しい値を指定します。ネストされた値にはピリオドを使用してアクセスできます。例:

cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=connection.access_key=KEY,connection.secret=SECRET

参照されているエントリに角括弧「[]」を追加して、配列エントリにアクセスできます。角括弧「[]」を使用して、新しい配列エントリを追加できます。インデックス値の-1は、配列の最後のエントリを参照します。新しいエントリを作成し、同じコマンドで再びそれを参照することはできません。たとえば、PREFIXで始まるバケットの新しいプロファイルを作成するコマンドは次のとおりです。

cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=profiles[].source_bucket=PREFIX'*'
cephuser@adm > radosgw-admin zone modify --rgw-zonegroup=ZONE-GROUP-NAME \
 --rgw-zone=ZONE-NAME \
 --tier-config=profiles[-1].connection_id=CONNECTION_ID,profiles[-1].acls_id=ACLS_ID

ヒント: 設定エントリの追加と削除

--tier-config-add=KEY=VALUEパラメータを使用して、新しい層の設定エントリを追加できます。

--tier-config-rm=KEYを使用して、既存のエントリを削除できます。

21.8.2 ゾーンの同期 #

同期モジュール設定はゾーンにローカルです。同期モジュールは、ゾーンがデータをエクスポートするのか、それとも別のゾーンで変更されたデータを使用できるだけかを判断します。Luminousの時点でサポートされている同期プラグインは、ElasticSearch、rgw (ゾーン間でデータを同期するデフォルトの同期プラグイン)、およびlog (リモートゾーンで実行されるメタデータ操作を記録する単純な同期プラグイン)です。以降のセクションでは、ElasticSearch同期モジュールを使用するゾーンを例にして説明します。他の同期プラグインでも設定のプロセスは同様です。

注記: デフォルトの同期プラグイン

rgwはデフォルトの同期プラグインで、明示的な設定は必要はありません。

21.8.2.1 要件と前提 #

21.13項「マルチサイトObject Gateway」で説明されているような、2つのゾーンus-eastとus-westで構成される単純なマルチサイト設定を前提にしましょう。ここでは、他のサイトからのメタデータのみを処理するゾーンである3つ目のゾーンus-east-esを追加します。このゾーンは、us-eastと同じCephクラスタにあっても、別のクラスタにあっても構いません。このゾーンは他のゾーンからのメタデータのみを使用し、このゾーンのObject Gatewayはエンドユーザの要求を直接実行することはありません。

21.8.2.2 ゾーンの設定 #

21.13項「マルチサイトObject Gateway」で説明されているものと同様の3つ目のゾーンを作成します。次に例を示します。

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-es \
--access-key=SYSTEM-KEY --secret=SECRET --endpoints=http://rgw-es:80

次のコマンドを使用して、このゾーンに対して同期モジュールを設定できます。

cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --tier-type=TIER-TYPE \
--tier-config={set of key=value pairs}

たとえば、ElasticSearch同期モジュールでは、次のコマンドを実行します。
```
cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --tier-type=elasticsearch \
--tier-config=endpoint=http://localhost:9200,num_shards=10,num_replicas=1
```
サポートされているさまざまなtier-configオプションについては、21.8.3項「ElasticSearch同期モジュール」を参照してください。

最後にピリオドを更新します。

cephuser@adm > radosgw-admin period update --commit

続いて、ゾーンでObject Gatewayを起動します。
```
cephuser@adm > ceph orch start rgw.REALM-NAME.ZONE-NAME
```

21.8.3 ElasticSearch同期モジュール #

この同期モジュールは、他のゾーンからElasticSearchにメタデータを書き込みます。Luminousの時点では、これは、現在ElasticSearchに保存しているJSON形式のデータフィールドです。

{
  "_index" : "rgw-gold-ee5863d6",
  "_type" : "object",
  "_id" : "34137443-8592-48d9-8ca7-160255d52ade.34137.1:object1:null",
  "_score" : 1.0,
  "_source" : {
    "bucket" : "testbucket123",
    "name" : "object1",
    "instance" : "null",
    "versioned_epoch" : 0,
    "owner" : {
      "id" : "user1",
      "display_name" : "user1"
    },
    "permissions" : [
      "user1"
    ],
    "meta" : {
      "size" : 712354,
      "mtime" : "2017-05-04T12:54:16.462Z",
      "etag" : "7ac66c0f148de9519b8bd264312c4d64"
    }
  }
}

21.8.3.1 ElasticSearchの層タイプの設定パラメータ #

endpoint: アクセスするElasticSearchサーバエンドポイントを指定します。
num_shards: (整数)データ同期初期化時にElasticSearchに設定するシャードの数。初期化後は変更できないことに注意してください。ここで変更を行った場合、ElasticSearchのインデックスの再構築と、データ同期プロセスの再初期化が必要になります。
num_replicas: (整数)データ同期初期化時にElasticSearchに設定するレプリカの数。
explicit_custom_meta: (true | false)すべてのユーザカスタムメタデータのインデックスを作成するか、それともカスタムメタデータエントリのインデックスを作成する対象をユーザが(バケットレベルで)設定する必要があるかを指定します。デフォルトではfalseになっています。
index_buckets_list: (文字列のコンマ区切りリスト)空の場合、すべてのバケットのインデックスが作成されます。空でない場合、ここで指定したバケットのインデックスのみが作成されます。バケットのプレフィックス(「foo*」など)またはサフィックス(「*bar」など)を指定できます。
approved_owners_list: (文字列のコンマ区切りリスト)空の場合、すべての所有者のバケットのインデックスが作成されます(他の制約に依存)。空でない場合、指定した所有者が所有するバケットのインデックスのみが作成されます。サフィックスとプレフィックスを指定することもできます。
override_index_path: (文字列)空でない場合、この文字列がElasticSearchのインデックスパスとして使用されます。空の場合、インデックスパスは同期初期化時に決定されて生成されます。
ユーザ名: 認証が必要な場合にElasticSearchのユーザ名を指定します。
password: 認証が必要な場合にElasticSearchのパスワードを指定します。

21.8.3.2 メタデータクエリ #

ElasticSearchクラスタにオブジェクトメタデータが保存されるようになったので、ElasticSearchエンドポイントを一般に公開しないようにし、エンドポイントにはクラスタ管理者のみがアクセスできるようにすることが重要です。ユーザが自身のメタデータのみを問い合わせ、他のユーザのメタデータは問い合わせないようにする必要があるため、メタデータクエリをエンドユーザそのものに公開すると、問題が発生します。このためには、ElasticSearchクラスタでもRGWと同様の方法でユーザを認証する必要がありますが、これが問題になります。

Luminousから、メタデータマスタゾーンのRGWでエンドユーザの要求を実行できるようになりました。これにより、ElasticSearchエンドポイントを一般に公開しないようにできると同時に、RGWそのものがエンドユーザの要求を認証できるので、認証と権限付与の問題も解決します。このために、RGWでは、バケットAPIにElasticSearchの要求を実行できる新しいクエリが導入されています。これらの要求はすべてメタデータマスタゾーンに送信する必要があります。

ElasticSearchクエリの取得

GET /BUCKET?query=QUERY-EXPR

要求パラメータ:

max-keys: 返されるエントリの最大数
marker: ページ分割マーカ

expression := [(]<arg> <op> <value> [)][<and|or> ...]

演算子は、<、<=、==、>=、>の1つです。

例:

GET /?query=name==foo

ユーザが読み込み許可を持つ、「foo」という名前のインデックス作成済みキーをすべて返します。出力は、S3のバケット一覧の応答に似たXML形式のキーのリストになります。

カスタムメタデータフィールドの設定

インデックスの作成が必要なカスタムメタデータエントリ(指定したバケットの下層)と、これらのキーのタイプを定義します。カスタムメタデータのインデックス作成が明示的に設定されている場合、rgwによって指定のカスタムメタデータ値のインデックスが作成されるようにするため、これが必要になります。それ以外の場合は、インデックスが作成されるメタデータキーのタイプが文字列以外のときに必要です。

POST /BUCKET?mdsearch
x-amz-meta-search: <key [; type]> [, ...]

複数のメタデータフィールドはコンマで区切る必要があります。「;」を使用して、フィールドに対してタイプを強制的に適用できます。現在許可されているタイプは、文字列(デフォルト)、整数、および日付です。たとえば、カスタムオブジェクトメタデータx-amz-meta-yearを整数、x-amz-meta-dateを日付タイプ、およびx-amz-meta-titleを文字列としてインデックスを作成する場合、次のように指定します。

POST /mybooks?mdsearch
x-amz-meta-search: x-amz-meta-year;int, x-amz-meta-release-date;date, x-amz-meta-title;string

カスタムメタデータ設定の削除

カスタムメタデータのバケット設定を削除します。

DELETE /BUCKET?mdsearch

カスタムメタデータ設定の取得

カスタムメタデータのバケット設定を取得します。

GET /BUCKET?mdsearch

21.8.4 クラウド同期モジュール #

このセクションでは、ゾーンデータをリモートクラウドサービスに同期するモジュールについて説明します。同期は単一方向のみです。日付はリモートゾーンから同期されません。このモジュールの主な目的は、データを複数のクラウドサービスプロバイダと同期できるようにすることです。現在のところ、AWS (S3)と互換性のあるクラウドプロバイダがサポートされています。

データをリモートクラウドサービスに同期するには、ユーザ資格情報を設定する必要があります。多くのクラウドサービスでは、各ユーザが作成できるバケットの数に制限を導入しているため、ソースオブジェクトとバケット、異なるターゲットから異なるバケットとバケットプレフィックスへのマッピングを設定できます。ソースのアクセスリスト(ACL)は保持されないことに注意してください。特定のソースユーザの許可を特定の宛先ユーザにマッピングできます。

APIの制限のため、元のオブジェクト変更時刻とHTTP ETag (エンティティタグ)を保持する方法はありません。クラウド同期モジュールは、これらを宛先オブジェクトのメタデータ属性として保存します。

21.8.4.1 クラウド同期モジュールの設定 #

以下はクラウド同期モジュールの単純な設定と複雑な設定の例です。単純な設定は複雑な設定と競合する可能性があることに注意してください。

例 21.1: 単純な設定 #

{
  "connection": {
    "access_key": ACCESS,
    "secret": SECRET,
    "endpoint": ENDPOINT,
    "host_style": path | virtual,
  },
  "acls": [ { "type": id | email | uri,
    "source_id": SOURCE_ID,
    "dest_id": DEST_ID } ... ],
  "target_path": TARGET_PATH,
}

例 21.2: 複雑な設定 #

{
  "default": {
    "connection": {
      "access_key": ACCESS,
      "secret": SECRET,
      "endpoint": ENDPOINT,
      "host_style" path | virtual,
    },
    "acls": [
    {
      "type": id | email | uri,   #  optional, default is id
      "source_id": ID,
      "dest_id": ID
    } ... ]
    "target_path": PATH # optional
  },
  "connections": [
  {
    "connection_id": ID,
    "access_key": ACCESS,
    "secret": SECRET,
    "endpoint": ENDPOINT,
    "host_style": path | virtual,  # optional
  } ... ],
  "acl_profiles": [
  {
    "acls_id": ID, # acl mappings
    "acls": [ {
      "type": id | email | uri,
      "source_id": ID,
      "dest_id": ID
    } ... ]
  }
  ],
  "profiles": [
  {
   "source_bucket": SOURCE,
   "connection_id": CONNECTION_ID,
   "acls_id": MAPPINGS_ID,
   "target_path": DEST,          # optional
  } ... ],
}

使用される設定用語の説明は次のとおりです。

接続

リモートクラウドサービスへの接続を表します。「connection_id」、「access_key」、「secret」、「endpoint」、および「host_style」が含まれます。

access_key

特定の接続に使用されるリモートクラウドアクセスキー。

secret

リモートクラウドサービスの秘密鍵。

endpoint

リモートクラウドサービスエンドポイントのURL。

host_style

リモートクラウドエンドポイントにアクセスする際に使用されるホストスタイルのタイプ(「path」または「virtual」)。デフォルトは「path」です。

acls

アクセスリストマッピングの配列。

acl_mapping

各「acl_mapping」構造には、「type」、「source_id」、および「dest_id」が含まれます。これらは、各オブジェクトのACL変換を定義します。ACL変換により、ソースユーザIDを宛先IDに変換できます。

type

ACLのタイプ: 「id」はユーザIDを定義し、「email」は電子メールでユーザを定義し、「uri」はuri (グループ)でユーザを定義します。

source_id

ソースゾーンでのユーザのID。

dest_id

宛先でのユーザのID。

target_path

ターゲットパスの作成方法を定義する文字列。ターゲットパスは、ソースオブジェクト名の追加先のプレフィックスを指定します。ターゲットパスの設定可能項目には、次の任意の変数を含めることができます。

SID: 同期インスタンスIDを表す固有の文字列。
ZONEGROUP: ゾーングループの名前。
ZONEGROUP_ID: ゾーングループのID。
ZONE: ゾーンの名前。
ZONE_ID: ゾーンのID。
BUCKET: ソースバケットの名前。
OWNER: ソースバケット所有者のID。

例: target_path = rgwx-ZONE-SID/OWNER/BUCKET

acl_profiles

アクセスリストプロファイルの配列。

acl_profile

各プロファイルには、プロファイルを表す「acls_id」と、「acl_mapping」のリストを格納する「acls」配列が含まれます。

プロファイル

プロファイルのリスト。各プロファイルには以下が含まれます。

source_bucket: バケット名、またはこのプロファイルのソースバケットを定義するバケットプレフィックス(*で終わる場合)のいずれか。
target_path: 説明については上記を参照。
connection_id: このプロファイルに使用する接続のID。
acls_id: このプロファイルに使用するACLのプロファイルのID。

21.8.4.2 S3固有の設定 #

クラウド同期モジュールは、AWS S3と互換性のあるバックエンドでのみ機能します。S3クラウドサービスにアクセスする場合、その動作を微調整するために使用できる設定可能項目がいくつかあります。

{
  "multipart_sync_threshold": OBJECT_SIZE,
  "multipart_min_part_size": PART_SIZE
}

multipart_sync_threshold: サイズがこの値以上のオブジェクトは、マルチパートアップロードを使用してクラウドサービスと同期されます。
multipart_min_part_size: マルチパートアップロードを使用してオブジェクトを同期する際に使用する最小パーツサイズ。

21.8.5 アーカイブ同期モジュール #

アーカイブ同期モジュールは、Object GatewayのS3オブジェクトのバージョン管理機能を利用します。アーカイブゾーンを設定することで、時間の経過とともに他のゾーンで異なるバージョンのS3オブジェクトが発生した場合にそれらをキャプチャできます。アーカイブゾーンが保持するバージョンの履歴は、アーカイブゾーンに関連付けられているゲートウェイを介してのみ削減できます。

このようなアーキテクチャにより、バージョン管理されていない複数のゾーンがゾーンゲートウェイを介してデータとメタデータをミラーリングし、エンドユーザに高可用性を提供できると同時に、アーカイブゾーンはすべてのデータ更新をキャプチャし、それらをS3オブジェクトのバージョンとして統合します。

マルチゾーン設定にアーカイブゾーンを含めることにより、一方のゾーンでS3オブジェクト履歴の柔軟性を利用しながら、残りのゾーンでは、バージョン管理されたS3オブジェクトのレプリカが使用する領域を節約できます。

21.8.5.1 アーカイブ同期モジュールの設定 #

ヒント: 詳細

マルチサイトゲートウェイの設定の詳細については、21.13項「マルチサイトObject Gateway」を参照してください。

同期モジュールの設定の詳細については、21.8項「同期モジュール」を参照してください。

アーカイブ同期モジュールを使用するには、層タイプがarchiveに設定された新しいゾーンを作成する必要があります。

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=ZONE_GROUP_NAME \
 --rgw-zone=OGW_ZONE_NAME \
 --endpoints=http://OGW_ENDPOINT1_URL[,http://OGW_ENDPOINT2_URL,...]
 --tier-type=archive

21.9 LDAP 認証 #

デフォルトのローカルユーザ認証とは別に、Object GatewayでLDAPサーバのサービスを使用してユーザを認証することもできます。

21.9.1 認証メカニズム #

Object GatewayがトークンからユーザのLDAP資格情報を抽出します。ユーザ名から検索フィルタが構成されます。Object Gatewayは、設定済みのユーザアカウントを使用して、一致するエントリをディレクトリで検索します。エントリが見つかった場合、Object Gatewayは、トークンから抽出したパスワードを使用して、見つかった識別名へのバインドを試みます。資格情報が有効であれば、バインドが成功し、Object Gatewayはアクセスを許可します。

許可するユーザを制限するには、検索ベースを特定の部門に設定するか、カスタム検索フィルタを指定します。たとえば、特定のグループメンバーシップ、カスタムオブジェクトクラス、またはカスタム属性を要求できます。

21.9.2 要件 #

「LDAPまたはActive Directory」: Object Gatewayがアクセス可能な動作中のLDAPインスタンス。
「サービスアカウント」: Object Gatewayが検索許可と共に使用するLDAP資格情報。
「ユーザアカウント」: LDAPディレクトリ内の1つ以上のユーザアカウント。

重要: LDAPユーザとローカルユーザを重複させない

ローカルユーザの名前と、LDAPを使用して認証するユーザの名前に同じユーザ名を使用することはできません。Object Gatewayはこれらのユーザを区別できず、同じユーザとして扱います。

ヒント: 正常性チェック

サービスアカウントまたはLDAP接続を確認するには、ldapsearchユーティリティを使用します。例:

> ldapsearch -x -D "uid=ceph,ou=system,dc=example,dc=com" -W \
-H ldaps://example.com -b "ou=users,dc=example,dc=com" 'uid=*' dn

想定される問題を排除するため、必ずCephの設定ファイルと同じLDAPパラメータを使用してください。

21.9.3 LDAP認証を使用するためのObject Gatewayの設定 #

次のパラメータはLDAP認証と関連があります。

rgw_s3_auth_use_ldap: このオプションをtrueに設定すると、LDAPを使用したS3認証が有効になります。
rgw_ldap_uri: 使用するLDAPサーバを指定します。プレーンテキストの資格情報がオープンに転送されるのを避けるため、必ずldaps://FQDN:PORTパラメータを使用してください。
rgw_ldap_binddn: Object Gatewayが使用するサービスアカウントの識別名(DN)。
rgw_ldap_secret: サービスアカウントのパスワード。
rgw_ldap_searchdn: ユーザを検索するための、ディレクトリ情報ツリーのベースを指定します。users部門または具体的なOU(部門)にすることができます。
rgw_ldap_dnattr: ユーザ名を照合するために、構成された検索フィルタで使用される属性。DIT (ディレクトリ情報ツリー)に応じて、uidまたはcnになります。
rgw_search_filter: 指定されていない場合、Object Gatewayは自動的にrgw_ldap_dnattr設定を使用して検索フィルタを構成します。このパラメータは、許可するユーザのリストを非常に柔軟な方法で絞り込む場合に使用します。詳細については、21.9.4項「カスタム検索フィルタを使用したユーザアクセスの制限」を参照してください。

21.9.4 カスタム検索フィルタを使用したユーザアクセスの制限 #

rgw_search_filterパラメータは2つの方法で使用できます。

21.9.4.2 完全なフィルタ #

完全なフィルタには、認証試行中にユーザ名に置き換えられるUSERNAMEトークンが含まれる必要があります。この場合、rgw_ldap_dnattrパラメータは使用されなくなります。たとえば、有効なユーザを特定のグループに制限するには、次のフィルタを使用します。

"(&(uid=USERNAME)(memberOf=cn=ceph-users,ou=groups,dc=mycompany,dc=com))"

注記: memberOf属性

LDAP検索でmemberOf属性を使用するには、特定のLDAPサーバ実装からのサーバサイドのサポートが必要です。

21.9.5 LDAP認証用アクセストークンの生成 #

radosgw-tokenユーティリティは、LDAPユーザ名とパスワードに基づいてアクセストークンを生成します。実際のアクセストークンであるBase-64エンコード文字列を出力します。好みのS3クライアント(21.5.1項「Object Gatewayへのアクセス」を参照)を使用し、このトークンをアクセスキーとして指定し、空の秘密鍵を使用します。

> export RGW_ACCESS_KEY_ID="USERNAME"
> export RGW_SECRET_ACCESS_KEY="PASSWORD"
cephuser@adm > radosgw-token --encode --ttype=ldap

重要: クリアテキスト資格情報

アクセストークンはBase-64エンコードのJSON構造で、LDAP資格情報がクリアテキストで含まれます。

注記: Active Directory

Active Directoryでは、--ttype=adパラメータを使用します。

21.10 バケットインデックスのシャーディング #

Object Gatewayは、バケットインデックスデータをインデックスプール(デフォルトでは.rgw.buckets.index)に保存します。1つのバケットに配置するオブジェクトが多すぎる(数十万個)場合、バケットあたりのオブジェクトの最大数のクォータ(rgw bucket default quota max objects)を設定しないと、インデックスプールのパフォーマンスが低下することがあります。「バケットインデックスのシャーディング」は、このようなパフォーマンス低下を防止し、各バケットで大量のオブジェクトを使用できるようになります。

21.10.1 バケットインデックスのリシャーディング #

バケットが大容量になり、初期設定が十分ではなくなった場合、バケットのインデックスプールをリシャーディングする必要があります。オンラインの自動バケットインデックスリシャーディングを使用することも(21.10.1.1項「動的リシャーディング」を参照)、バケットインデックスをオフラインで手動でリシャーディングすることもできます(21.10.1.2項「手動リシャーディング」を参照)。

21.10.1.1 動的リシャーディング #

SUSE Enterprise Storage 5から、オンラインのバケットリシャーディングがサポートされています。これは、バケットあたりのオブジェクト数が一定のしきい値に達しているかどうかを検出し、バケットインデックスで使用されるシャードの数を自動的に増やします。このプロセスにより、各バケットインデックスシャードのエントリの数が減ります。

検出プロセスは次の条件で実行されます。

バケットに新しいオブジェクトが追加された場合。
すべてのバケットを定期的にスキャンするバックグラウンドプロセス内。これは、更新されない既存のバケットに対応するために必要です。

リシャーディングが必要なバケットはreshard_logキューに追加され、後でリシャーディングするようスケジュールされます。リシャードスレッドはバックグラウンドで動作し、スケジュールされたリシャーディングを一度に1つずつ実行します。

動的リシャーディングの設定 #

rgw_dynamic_resharding: 動的バケットインデックスリシャーディングを有効/無効にします。設定可能な値は「true」または「false」です。デフォルトは「true」です。
rgw_reshard_num_logs: リシャーディングログの対象にするシャードの数。デフォルトは16です。
rgw_reshard_bucket_lock_duration: リシャーディング中のバケットオブジェクトに対するロック期間。デフォルトは120秒です。
rgw_max_objs_per_shard: バケットインデックスシャードあたりのオブジェクトの最大数。デフォルトは100000オブジェクトです。
rgw_reshard_thread_interval: リシャードスレッド処理のラウンド間の最大時間。デフォルトは600秒です。

リシャーディングプロセスを管理するためのコマンド #

リシャーディングキューへのバケットの追加

cephuser@adm > radosgw-admin reshard add \
 --bucket BUCKET_NAME \
 --num-shards NEW_NUMBER_OF_SHARDS

リシャーディングキューの一覧

cephuser@adm > radosgw-admin reshard list

バケットリシャーディングの処理/スケジュール

cephuser@adm > radosgw-admin reshard process

バケットリシャーディングの状態の表示

cephuser@adm > radosgw-admin reshard status --bucket BUCKET_NAME

保留中のバケットリシャーディングのキャンセル

cephuser@adm > radosgw-admin reshard cancel --bucket BUCKET_NAME

21.10.1.2 手動リシャーディング #

21.10.1.1項「動的リシャーディング」で説明されている動的リシャーディングは、単純なObject Gateway設定でのみサポートされます。マルチサイト設定の場合は、このセクションで説明する手動リシャーディングを使用します。

バケットインデックスをオフラインで手動でリシャーディングするには、次のコマンドを使用します。

cephuser@adm > radosgw-admin bucket reshard

bucket reshardコマンドは次の処理を実行します。

指定したオブジェクトに対してバケットインデックスオブジェクトの新しいセットを作成する
これらのインデックスオブジェクトのすべてのエントリを分散する
新しいバケットインスタンスを作成する
新しいバケットインスタンスをバケットにリンクし、すべての新規インデックス操作が新しいバケットインデックスを経由するようにする
新旧のバケットIDを標準出力に出力する

ヒント

多数のシャードを選択する場合、以下に注意をし、シャードあたり100000エントリ以下を目指してください。素数であるバケットインデックスのシャードは、シャード間で均等に分散しているバケットインデックスエントリで優れた動作になる傾向があります。たとえば、503個のバケットインデックスのシャードは素数であるため、500個のシャードよりも優れています。

手順 21.1: バケットインデックスのリシャーディング #

バケットに対するすべての操作が停止していることを確認します。

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

cephuser@adm > radosgw-admin bi list \
 --bucket=BUCKET_NAME \
 > BUCKET_NAME.list.backup

バケットインデックスをリシャーディングします。
```
 cephuser@adm > radosgw-admin bucket reshard \
 --bucket=BUCKET_NAME \
 --num-shards=NEW_SHARDS_NUMBER
```
ヒント: 古いバケットID
このコマンドは、出力の一部として新旧のバケットIDも出力します。

21.10.2 新しいバケットのバケットインデックスシャーディング #

バケットインデックスシャーディングを制御するオプションは2つあります。

単純な設定の場合は、rgw_override_bucket_index_max_shardsオプションを使用します。
マルチサイト設定の場合は、bucket_index_max_shardsオプションを使用します。

これらのオプションを0に設定すると、バケットインデックスシャーディングが無効になります。0より大きい値にすると、バケットインデックスシャーディングが有効になり、シャードの最大数が設定されます。

シャードの推奨数を計算するには、次の式が役立ちます。

number_of_objects_expected_in_a_bucket / 100000

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

21.10.2.1 マルチサイト設定 #

マルチサイト設定では、フェールオーバーを管理するために別のインデックスプールを設定できます。1つのゾーングループ内のゾーン全体に一貫したシャード数を設定するには、ゾーングループの設定でbucket_index_max_shardsオプションを設定します。

ゾーングループの設定をzonegroup.jsonファイルにエクスポートします。
```
cephuser@adm > radosgw-admin zonegroup get > zonegroup.json
```
zonegroup.jsonファイルを編集して、指定した各ゾーンに対してbucket_index_max_shardsオプションを設定します。

ゾーングループをリセットします。

cephuser@adm > radosgw-admin zonegroup set < zonegroup.json

ピリオドを更新します。21.13.2.6項「ピリオドの更新」を参照してください。

21.11 OpenStack Keystoneの統合 #

OpenStack Keystoneは、OpenStack製品の識別情報サービスです。Object GatewayをKeystoneと統合して、Keystoneの認証トークンを受け付けるゲートウェイを設定できます。Keystoneによってゲートウェイにアクセスする権限が付与されたユーザは、Ceph Object Gateway側で確認され、必要であれば自動的に作成されます。Object Gatewayは、取り消されたトークンのリストを定期的にKeystoneに問い合わせます。

21.11.1 OpenStackの設定 #

Ceph Object Gatewayを設定する前に、Swiftサービスを有効にしてCeph Object Gatewayを指すようにOpenStack Keystoneを設定する必要があります。

Swiftサービスを設定します。OpenStackを使用してSwiftユーザを検証するには、まずSwiftサービスを作成します。
```
> openstack service create \
 --name=swift \
 --description="Swift Service" \
 object-store
```
エンドポイントを設定します。Swiftサービスを作成した後、Ceph Object Gatewayを指すようにします。REGION_NAMEは、ゲートウェイのゾーングループ名またはリージョン名に置き換えます。
```
> openstack endpoint create --region REGION_NAME \
 --publicurl   "http://radosgw.example.com:8080/swift/v1" \
 --adminurl    "http://radosgw.example.com:8080/swift/v1" \
 --internalurl "http://radosgw.example.com:8080/swift/v1" \
 swift
```
設定を確認します。Swiftサービスを作成してエンドポイントを設定した後、エンドポイントを表示して、すべての設定が正しいことを確認します。
```
> openstack endpoint show object-store
```

21.11.2 Ceph Object Gatewayの設定 #

21.11.2.1 SSL証明書の設定 #

Ceph Object Gatewayは、取り消されたトークンのリストを定期的にKeystoneに問い合わせます。これらの要求はエンコードおよび署名されています。同様にエンコードおよび署名された自己署名トークンを提供するようKeystoneを設定することもできます。これらの署名されたメッセージをデコードして検証できるようゲートウェイを設定する必要があります。したがって、Keystoneが要求を作成するために使用するOpenSSL証明書を「nss db」フォーマットに変換する必要があります。

# mkdir /var/ceph/nss
# openssl x509 -in /etc/keystone/ssl/certs/ca.pem \
 -pubkey | certutil -d /var/ceph/nss -A -n ca -t "TCu,Cu,Tuw"
rootopenssl x509 -in /etc/keystone/ssl/certs/signing_cert.pem \
 -pubkey | certutil -A -d /var/ceph/nss -n signing_cert -t "P,P,P"

Ceph Object GatewayがOpenStack Keystoneと対話できるようにするため、OpenStack Keystoneで自己署名SSL証明書を使用できます。Ceph Object Gatewayが実行されているノードにKeystoneのSSL証明書をインストールするか、オプションrgw keystone verify sslの値を「false」に設定します。rgw keystone verify sslを「false」に設定すると、ゲートウェイが証明書の検証を試行しないことを意味します。

21.11.2.2 Object Gatewayのオプションの設定 #

次のオプションを使用してKeystone統合を設定できます。

rgw keystone api version: Keystone APIのバージョン。有効なオプションは2または3です。デフォルトは2です。
rgw keystone url: Keystoneサーバの管理RESTful APIのURLとポート番号。SERVER_URL:PORT_NUMBERというパターンに従います。
rgw keystone admin token: 管理要求に対してKeystone内部で設定されるトークンと共有シークレット。
rgw keystone accepted roles: 要求を実行するために必要な役割。デフォルトは「Member, admin」です。
rgw keystone accepted admin roles: ユーザが管理特権を得られるようにする役割のリスト。
rgw keystone token cache size: Keystoneトークンキャッシュのエントリの最大数。
rgw keystone revocation interval: 拒否されたトークンを確認するまでの秒数。デフォルトは15 * 60です。
rgw keystone implicit tenants: 新しいユーザを同じ名前の専用のテナント内に作成します。デフォルトは「false」です。
rgw s3 auth use keystone: 「true」に設定すると、Ceph Object GatewayはKeystoneを使用してユーザを認証します。デフォルトは「false」です。
nss db path: NSSデータベースのパス。

OpenStackサービスの設定と同様の方法で、Keystoneサービステナント、およびKeystoneのユーザとパスワード(OpenStack Identity APIのバージョン2.0の場合)を設定することもできます。これにより、設定ファイルで共有シークレットrgw keystone admin tokenを設定するのを避けることができます。このような設定は運用環境では無効にする必要があります。サービステナントの資格情報には管理者特権を含める必要があります。詳細については、公式のOpenStack Keystoneのドキュメントを参照してください。関連する設定オプションは次のとおりです。

rgw keystone admin user: Keystone管理者ユーザの名前。
rgw keystone admin password: Keystone管理者ユーザのパスワード。
rgw keystone admin tenant: Keystoneバージョン2.0の管理者ユーザのテナント。

Ceph Object GatewayのユーザはKeystoneテナントにマップされます。Keystoneユーザには、多くの場合、複数のテナントで複数の役割が割り当てられます。Ceph Object Gatewayは、チケットを取得すると、そのチケットに割り当てられているテナントとユーザの役割を確認し、rgw keystone accepted rolesオプションの設定に従って要求を受け入れるか拒否します。

ヒント: OpenStackテナントのマッピング

SwiftテナントはデフォルトでObject Gatewayユーザにマップされますが、rgw keystone implicit tenantsオプションを使用してOpenStackテナントにマップすることもできます。これにより、コンテナは、Object GatewayのデフォルトであるS3同様のグローバルネームスペースではなく、テナントのネームスペースを使用するようになります。混乱を避けるため、計画段階でマッピング方法を決定することをお勧めします。その理由は、後でこのオプションを切り替えた場合、テナント下にマッピングされた新しい要求のみが対象となり、前に作成された古いバケットはグローバルネームスペースに存在し続けるためです。

OpenStack Identity APIのバージョン3では、rgw keystone admin tenantオプションを次の内容に置き換える必要があります。

rgw keystone admin domain: Keystone管理者ユーザのドメイン。
rgw keystone admin project: Keystone管理者ユーザのプロジェクト。

21.12 プールの配置とストレージクラス #

21.12.1 配置ターゲットの表示 #

配置ターゲットは、特定のバケットにどのプールを関連付けるかを制御します。バケットの配置ターゲットは作成時に選択し、変更することはできません。次のコマンドを実行して、そのplacement_ruleを表示できます。

cephuser@adm > radosgw-admin bucket stats

ゾーングループ設定には、「default-placement」という名前の初期ターゲットが設定された配置ターゲットのリストが含まれています。ゾーン設定により、各ゾーングループの配置ターゲットの名前がそのローカルストレージにマップされます。このゾーン配置情報には、バケットインデックスの「index_pool」の名前、不完全なマルチパートアップロードに関するメタデータの「data_extra_pool」の名前、および各ストレージクラスの「data_pool」の名前が含まれています。

21.12.2 ストレージクラス #

ストレージクラスは、オブジェクトデータの配置をカスタマイズするのに役立ちます。S3バケットのライフサイクルルールを使用すると、ストレージクラス間でのオブジェクトの移行を自動化できます。

ストレージクラスは、配置ターゲットの観点から定義します。各ゾーングループ配置ターゲットには、使用可能なストレージクラスが「STANDARD」という名前の初期クラスで一覧にされます。ゾーン設定は、各ゾーングループのストレージクラスに「data_pool」プール名を提供する処理を受け持ちます。

21.12.3 ゾーングループおよびゾーンの設定 #

ゾーングループおよびゾーンに対してradosgw-adminコマンドを使用し、その配置を設定します。次のコマンドを使用して、ゾーングループ配置設定を問い合わせることができます。

cephuser@adm > radosgw-admin zonegroup get
{
    "id": "ab01123f-e0df-4f29-9d71-b44888d67cd5",
    "name": "default",
    "api_name": "default",
    ...
    "placement_targets": [
        {
            "name": "default-placement",
            "tags": [],
            "storage_classes": [
                "STANDARD"
            ]
        }
    ],
    "default_placement": "default-placement",
    ...
}

ゾーン配置設定を問い合わせるには、次のコマンドを実行します。

cephuser@adm > radosgw-admin zone get
{
    "id": "557cdcee-3aae-4e9e-85c7-2f86f5eddb1f",
    "name": "default",
    "domain_root": "default.rgw.meta:root",
    ...
    "placement_pools": [
        {
            "key": "default-placement",
            "val": {
                "index_pool": "default.rgw.buckets.index",
                "storage_classes": {
                    "STANDARD": {
                        "data_pool": "default.rgw.buckets.data"
                    }
                },
                "data_extra_pool": "default.rgw.buckets.non-ec",
                "index_type": 0
            }
        }
    ],
    ...
}

注記: 以前のマルチサイト設定がない場合

以前にマルチサイト設定を実行したことがない場合は、「デフォルト」のゾーンとゾーングループが自動的に作成され、このゾーン/ゾーングループへの変更はCeph Object Gatewaysを再起動するまで有効になりません。マルチサイトのレルムを作成している場合は、ゾーン/ゾーングループの変更は、radosgw-admin period update --commitコマンドで変更をコミットした後で有効になります。

21.12.3.1 配置ターゲットの追加 #

「temporary」という名前の新しい配置ターゲットを作成するには、まずそれをゾーングループに追加します。

cephuser@adm > radosgw-admin zonegroup placement add \
      --rgw-zonegroup default \
      --placement-id temporary

次に、そのターゲットのゾーン配置情報を指定します。

cephuser@adm > radosgw-admin zone placement add \
      --rgw-zone default \
      --placement-id temporary \
      --data-pool default.rgw.temporary.data \
      --index-pool default.rgw.temporary.index \
      --data-extra-pool default.rgw.temporary.non-ec

21.12.3.2 ストレージクラスの追加 #

「COLD」という名前の新しいストレージクラスを「default-placement」ターゲットに追加するには、まずそれをゾーングループに追加します。

cephuser@adm > radosgw-admin zonegroup placement add \
      --rgw-zonegroup default \
      --placement-id default-placement \
      --storage-class COLD

次に、そのストレージクラスのゾーン配置情報を指定します。

cephuser@adm > radosgw-admin zone placement add \
      --rgw-zone default \
      --placement-id default-placement \
      --storage-class COLD \
      --data-pool default.rgw.cold.data \
      --compression lz4

21.12.4 配置のカスタマイズ #

21.12.4.1 ゾーングループのデフォルトの配置の編集 #

デフォルトでは、新しいバケットはそのゾーングループのdefault_placementターゲットを使用します。次のコマンドを使用して、このゾーングループ設定を変更できます。

cephuser@adm > radosgw-admin zonegroup placement default \
      --rgw-zonegroup default \
      --placement-id new-placement

21.12.4.2 ユーザのデフォルトの配置の編集 #

Ceph Object Gatewayユーザは、ユーザ情報に空ではないdefault_placementフィールドを設定することにより、ゾーングループのデフォルトの配置ターゲットを上書きすることができます。同様に、default_storage_classを設定すると、デフォルトでオブジェクトに適用されるSTANDARDストレージクラスを上書きできます。

cephuser@adm > radosgw-admin user info --uid testid
{
    ...
    "default_placement": "",
    "default_storage_class": "",
    "placement_tags": [],
    ...
}

ゾーングループの配置ターゲットにタグが含まれている場合、ユーザは、その配置ターゲットを使用してバケットを作成できません。ただし、そのユーザ情報の「placement_tags」フィールドに、一致するタグが少なくとも1つ含まれている場合を除きます。これは、特定のタイプのストレージへのアクセスを制限するのに役立つ場合があります。

radosgw-adminコマンドでこれらのフィールドを直接変更することはできません。そのため、JSONフォーマットを手動で編集する必要があります。

cephuser@adm > radosgw-admin metadata get user:USER-ID > user.json
> vi user.json     # edit the file as required
cephuser@adm > radosgw-admin metadata put user:USER-ID < user.json

21.12.4.3 S3のデフォルトのバケットの配置の編集 #

S3プロトコルでバケットを作成する場合、配置ターゲットをLocationConstraintの一部として指定し、ユーザとゾーングループのデフォルトの配置ターゲットを上書きすることができます。

通常、LocationConstraintは、ゾーングループのapi_nameに一致する必要があります。

<LocationConstraint>default</LocationConstraint>

カスタム配置ターゲットを、コロンに続くapi_nameに追加できます。

<LocationConstraint>default:new-placement</LocationConstraint>

21.12.4.4 Swiftのバケットの配置の編集 #

Swiftプロトコルでバケットを作成する場合、HTTPヘッダのX-Storage-Policyで配置ターゲットを指定できます。

X-Storage-Policy: NEW-PLACEMENT

21.12.5 ストレージクラスの使用 #

すべての配置ターゲットには、新しいオブジェクトにデフォルトで適用されるSTANDARDストレージクラスがあります。このデフォルトを、そのdefault_storage_classで上書きできます。

デフォルト以外のストレージクラスにオブジェクトを作成するには、要求のHTTPヘッダでそのストレージクラス名を指定します。S3プロトコルではX-Amz-Storage-Classヘッダを使用し、SwiftプロトコルではX-Object-Storage-Classヘッダを使用します。

Transitionアクションを使用してストレージクラス間でオブジェクトデータを移動するには、S3オブジェクトライフサイクル管理を使用できます。

21.13 マルチサイトObject Gateway #

Cephは、Ceph Object Gateway用のマルチサイト設定オプションを複数サポートしています。

マルチゾーン: ゾーングループと複数のゾーンから構成されている設定で、それぞれのゾーンに1つまたは複数のceph-radosgwインスタンスがあります。それぞれのゾーンは、その独自のCeph Storage Clusterを利用しています。ゾーンの1つで重大な障害が発生した場合、ゾーングループ内の複数のゾーンがゾーングループに障害復旧を提供します。それぞれのゾーンがアクティブで、書き込み操作を受け付ける場合があります。障害復旧に加えて、複数のアクティブゾーンがコンテンツ配信ネットワークの基盤としても動作する場合があります。
マルチゾーングループ: Ceph Object Gatewayは、複数のゾーングループをサポートしていて、それぞれのゾーングループに1つまたは複数のゾーンがあります。同じレルム内の1つのゾーングループのゾーンに別のゾーングループとして保存されているオブジェクトは、グルーバルオブジェクトネームスペースを共有するため、ゾーングループおよびゾーン間で固有のオブジェクトIDになります。
注記
ゾーングループはそのゾーングループ内のメタデータのみを同期するということに留意することが重要です。データおよびメタデータは、ゾーングループ内のゾーンの間で複製されます。データやメタデータはレルム間では共有されません。
複数のレルム: Ceph Object Gatewayは、グローバルに固有のネームスペースであるレルムという概念をサポートしています。1つまたは複数のゾーングループを含む複数のレルムがサポートされます。

アクティブ-アクティブゾーン設定で動作するようにそれぞれのObject Gatewayを設定し、非マスタゾーンへの書き込みを許可できます。マルチサイト設定はレルムと呼ばれるコンテナ内に保存されます。レルムは、ゾーングループ、ゾーン、および複数のエポックを含むピリオドを保存し、設定変更を追跡します。rgwデーモンが同期を処理するため、個別の同期エージェントは不要です。この同期方法では、Ceph Object Gatewayは、アクティブ-パッシブ設定ではなくアクティブ-アクティブ設定で動作できます。

21.13.1 要件と前提 #

マルチサイト設定では、2つ以上のCephストレージクラスタおよび2つ以上のCeph Object Gatewayインスタンス(各Cephストレージクラスタに1つ)が必要です。次の設定は、地理的に離れた場所に2つ以上のCephストレージクラスタがあることを想定しています。ただし、設定は同じサイトで動作できます。たとえば、rgw1とrgw2という名前であるとします。

マルチサイト設定では、マスタゾーングループおよびマスタゾーンが必要です。マスタゾーンは、マルチサイトクラスタのすべてのメタデータ操作に関する真実を語る資料です。また、それぞれのゾーングループにはマスタゾーンが必要です。ゾーングループには、1つまたは複数のセカンダリゾーンまたは非マスタゾーンがある場合があります。このガイドでは、rgw1ホストがマスタゾーングループのマスタゾーンとして動作し、rgw2ホストがマスタゾーングループのセカンダリゾーンとして動作します。

21.13.2 マスタゾーンの設定 #

マルチサイト設定のすべてのゲートウェイは、マスタゾーングループおよびマスタゾーン内のホストのceph-radosgwデーモンから設定を取得します。マルチサイト設定でゲートウェイを設定するには、ceph-radosgwインスタンスを選択してマスタゾーングループおよびマスタゾーンを設定します。

21.13.2.1 レルムの作成 #

レルムは、1つまたは複数のゾーンを含む1つまたは複数のゾーングループから構成されるグローバルに固有のネームスペースを表します。ゾーンにはバケットが含まれていて、バケットにはオブジェクトが含まれています。レルムは、Ceph Object Gatewayを有効にし、同じハードウェアの複数のネームスペースおよびその設定をサポートします。レルムにはピリオドの概念が含まれています。それぞれのピリオドは、ゾーングループおよびゾーンの設定の状態を時間で表します。ゾーングループまたはゾーンを変更するたびに、ピリオドを更新し、コミットします。デフォルトでは、Ceph Object Gatewayは、下位互換性を満たすためにレルムを作成しません。ベストプラクティスとして、新しいクラスタにはレルムを作成することをお勧めします。

マルチサイト設定用にgoldという新しいレルムを作成します。そのためには、マスタゾーングループおよびゾーンで使用するホストでコマンドラインインタフェースを開きます。次のコマンドを実行します。

cephuser@adm > radosgw-admin realm create --rgw-realm=gold --default

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

レルムを作成した後、radosgw-adminは、レルムの設定を返します。

{
  "id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "name": "gold",
  "current_period": "09559832-67a4-4101-8b3f-10dfcd6b2707",
  "epoch": 1
}

注記

Cephは、レルム用に固有のIDを生成します。必要に応じてレルムの名前を変更できます。

21.13.2.2 マスタゾーングループの作成 #

レルムには、レルムのマスタゾーングループとして動作する1つ以上のゾーングループが必要です。マルチサイト設定用に新しいマスタゾーングループを作成します。そのためには、マスタゾーングループおよびゾーンで使用するホストでコマンドラインインタフェースを開きます。次のコマンドを実行してusというマスタゾーングループを作成します。

cephuser@adm > radosgw-admin zonegroup create --rgw-zonegroup=us \
--endpoints=http://rgw1:80 --master --default

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

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

{
 "id": "d4018b8d-8c0d-4072-8919-608726fa369e",
 "name": "us",
 "api_name": "us",
 "is_master": "true",
 "endpoints": [
     "http:\/\/rgw1:80"
 ],
 "hostnames": [],
 "hostnames_s3website": [],
 "master_zone": "",
 "zones": [],
 "placement_targets": [],
 "default_placement": "",
 "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"
}

21.13.2.3 マスタゾーンの作成 #

重要

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

マルチサイト設定用に新しいマスタゾーンを作成します。そのためには、マスタゾーングループおよびゾーンで使用するホストでコマンドラインインタフェースを開きます。次のコマンドを実行します。

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-1 \
--endpoints=http://rgw1:80 --access-key=SYSTEM_ACCESS_KEY --secret=SYSTEM_SECRET_KEY

注記

上の例では、--access-keyオプションと--secretオプションを指定していません。これらの設定は、次のセクションでユーザを作成したときにゾーンに追加されます。

マスタゾーンを作成した後、radosgw-adminは、ゾーンの設定を返します。例:

  {
      "id": "56dfabbb-2f4e-4223-925e-de3c72de3866",
      "name": "us-east-1",
      "domain_root": "us-east-1.rgw.meta:root",
      "control_pool": "us-east-1.rgw.control",
      "gc_pool": "us-east-1.rgw.log:gc",
      "lc_pool": "us-east-1.rgw.log:lc",
      "log_pool": "us-east-1.rgw.log",
      "intent_log_pool": "us-east-1.rgw.log:intent",
      "usage_log_pool": "us-east-1.rgw.log:usage",
      "reshard_pool": "us-east-1.rgw.log:reshard",
      "user_keys_pool": "us-east-1.rgw.meta:users.keys",
      "user_email_pool": "us-east-1.rgw.meta:users.email",
      "user_swift_pool": "us-east-1.rgw.meta:users.swift",
      "user_uid_pool": "us-east-1.rgw.meta:users.uid",
      "otp_pool": "us-east-1.rgw.otp",
      "system_key": {
          "access_key": "1555b35654ad1656d804",
          "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
      },
      "placement_pools": [
          {
              "key": "us-east-1-placement",
              "val": {
                  "index_pool": "us-east-1.rgw.buckets.index",
                  "storage_classes": {
                      "STANDARD": {
                          "data_pool": "us-east-1.rgw.buckets.data"
                      }
                  },
                  "data_extra_pool": "us-east-1.rgw.buckets.non-ec",
                  "index_type": 0
              }
          }
      ],
      "metadata_heap": "",
      "realm_id": ""
  }

21.13.2.4 デフォルトのゾーンとグループの削除 #

重要

次の手順では、まだデータを保存していない新しくインストールしたシステムを使用するマルチサイト設定を想定しています。デフォルトのゾーンおよびそのプールを使用してデータを保存済みの場合、これらを削除しないでください。削除するとデータが削除され、回復できなくなります。

Object Gatewayをデフォルトインストールすると、defaultという名前のデフォルトのゾーングループが作成されます。デフォルトのゾーンがある場合、削除します。まず、デフォルトのゾーングループからデフォルトのゾーンを削除します。

cephuser@adm > radosgw-admin zonegroup delete --rgw-zonegroup=default

Cephストレージクラスタにデフォルトのプールがある場合、削除します。

重要

次の手順では、現時点でデータが保存されていない新しくインストールしたシステムを使用するマルチサイト設定を想定しています。デフォルトのゾーングループを使用してデータを保存済みの場合、これらを削除しないでください。

cephuser@adm > ceph osd pool rm default.rgw.control default.rgw.control --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.gc default.rgw.gc --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.log default.rgw.log --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.meta default.rgw.meta --yes-i-really-really-mean-it

警告

デフォルトのゾーングループを削除すると、システムユーザも削除されます。管理ユーザキーが伝搬されない場合、CephダッシュボードのObject Gateway管理機能は動作しません。この手順を続行する場合、次のセクションに進み、システムユーザを再作成します。

21.13.2.5 システムユーザの作成 #

レルムおよびピリオドの情報を取得するにはその前に、ceph-radosgwデーモンを認証する必要があります。マスタゾーンで、システムユーザを作成し、デーモン間の認証を簡略化します。

cephuser@adm > radosgw-admin user create --uid=zone.user \
--display-name="Zone User" --access-key=SYSTEM_ACCESS_KEY \
--secret=SYSTEM_SECRET_KEY --system

セカンダリゾーンではaccess_keyとsecret_keyをマスタゾーンで認証する必要があるため、これらをメモします。

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

cephuser@adm > radosgw-admin zone modify --rgw-zone=us-east-1 \
--access-key=ACCESS-KEY --secret=SECRET

ピリオドを更新して変更を有効にします。

cephuser@adm > radosgw-admin period update --commit

21.13.2.6 ピリオドの更新 #

マスタゾーンの設定を更新した後、ピリオドを更新します。

cephuser@adm > radosgw-admin period update --commit

ピリオドを更新した後、radosgw-adminは、ピリオドの設定を返します。例:

{
  "id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "epoch": 1, "predecessor_uuid": "", "sync_status": [], "period_map":
  {
    "id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "zonegroups": [], "short_zone_ids": []
  }, "master_zonegroup": "", "master_zone": "", "period_config":
  {
     "bucket_quota": {
     "enabled": false, "max_size_kb": -1, "max_objects": -1
     }, "user_quota": {
       "enabled": false, "max_size_kb": -1, "max_objects": -1
     }
  }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 1
}

注記

ピリオドを更新すると、エポックが変更され、その他のゾーンが更新した設定を受け取るようになります。

21.13.2.7 Gatewayの起動 #

Object Gatewayホストで、Ceph Object Gatewayサービスを起動し、有効にします。クラスタ固有のFSIDを識別するには、ceph fsidを実行します。Object Gatewayのデーモン名を識別するには、ceph orch ps --hostname HOSTNAMEを実行します。

cephuser@ogw > systemctl start ceph-FSID@DAEMON_NAME
cephuser@ogw > systemctl enable ceph-FSID@DAEMON_NAME

21.13.3 セカンダリゾーンの設定 #

ゾーングループ内のゾーンは、各ゾーンに同じデータが存在するようにするため、すべてのデータを複製します。セカンダリゾーンを作成する場合は、セカンダリゾーンにサービスを提供するよう指定されたホスト上で次の操作をすべて実行します。

注記

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

重要

ユーザ作成などのメタデータ操作は、マスタゾーン内のホストで実行する必要があります。マスタゾーンおよびセカンダリゾーンは、バケット操作を受け取ることができますが、セカンダリゾーンは、バケット操作をマスタゾーンにリダイレクトします。マスタゾーンがダウンしている場合、バケット操作は失敗します。

21.13.3.1 レルムのインポート #

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

cephuser@adm > radosgw-admin realm pull --url=url-to-master-zone-gateway --access-key=access-key --secret=secret

注記

レルムをインポートすると、リモートホストの現在のピリオドの設定も取得され、また、それがこのホストの現在のピリオドになります。

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

cephuser@adm > radosgw-admin realm default --rgw-realm=REALM-NAME

21.13.3.2 セカンダリゾーンの作成 #

マルチサイト設定用にセカンダリゾーンを作成します。そのためには、セカンダリゾーンで使用するホストでコマンドラインインタフェースを開きます。ゾーングループID、新しいゾーン名およびゾーンのエンドポイントを指定します。--masterフラグは使用しないでください。デフォルトでは、すべてのゾーンがアクティブ-アクティブ設定で動作します。セカンダリゾーンが書き込み操作を受け付けないようにする場合、--read-onlyフラグを指定して、マスタゾーンとセカンダリゾーンの間にアクティブ-パッシブ設定を作成します。また、マスタゾーングループのマスタゾーンに保存されている、生成済みのシステムユーザのaccess_keyとsecret_keyを指定します。次のコマンドを実行します。

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=ZONE-GROUP-NAME\
 --rgw-zone=ZONE-NAME --endpoints=URL \
 --access-key=SYSTEM-KEY --secret=SECRET\
 --endpoints=http://FQDN:80 \
 [--read-only]

例:

cephuser@adm > radosgw-admin zone create --rgw-zonegroup=us --endpoints=http://rgw2:80 \
--rgw-zone=us-east-2 --access-key=SYSTEM_ACCESS_KEY --secret=SYSTEM_SECRET_KEY
{
  "id": "950c1a43-6836-41a2-a161-64777e07e8b8",
  "name": "us-east-2",
  "domain_root": "us-east-2.rgw.data.root",
  "control_pool": "us-east-2.rgw.control",
  "gc_pool": "us-east-2.rgw.gc",
  "log_pool": "us-east-2.rgw.log",
  "intent_log_pool": "us-east-2.rgw.intent-log",
  "usage_log_pool": "us-east-2.rgw.usage",
  "user_keys_pool": "us-east-2.rgw.users.keys",
  "user_email_pool": "us-east-2.rgw.users.email",
  "user_swift_pool": "us-east-2.rgw.users.swift",
  "user_uid_pool": "us-east-2.rgw.users.uid",
  "system_key": {
      "access_key": "1555b35654ad1656d804",
      "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
  },
  "placement_pools": [
      {
          "key": "default-placement",
          "val": {
              "index_pool": "us-east-2.rgw.buckets.index",
              "data_pool": "us-east-2.rgw.buckets.data",
              "data_extra_pool": "us-east-2.rgw.buckets.non-ec",
              "index_type": 0
          }
      }
  ],
  "metadata_heap": "us-east-2.rgw.meta",
  "realm_id": "815d74c2-80d6-4e63-8cfc-232037f7ff5c"
}

重要

次の手順では、まだデータが保存されていない新しくインストールしたシステムを使用するマルチサイト設定を想定しています。デフォルトのゾーンおよびそのプールを使用してデータを保存済みの場合、これらを削除しないでください。削除するとデータが失われ、回復できなくなります。

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

cephuser@adm > radosgw-admin zone delete --rgw-zone=default

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

cephuser@adm > ceph osd pool rm default.rgw.control default.rgw.control --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.gc default.rgw.gc --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.log default.rgw.log --yes-i-really-really-mean-it
cephuser@adm > ceph osd pool rm default.rgw.users.uid default.rgw.users.uid --yes-i-really-really-mean-it

21.13.3.3 Ceph設定ファイルの更新 #

セカンダリゾーンのホストでCeph設定ファイルを更新します。そのためには、rgw_zone設定オプションとセカンダリゾーンの名前をインスタンスのエントリに追加します。

そのためには、次のコマンドを実行します。

cephuser@adm > ceph config set SERVICE_NAME rgw_zone us-west

21.13.3.4 ピリオドの更新 #

マスタゾーンの設定を更新した後、ピリオドを更新します。

cephuser@adm > radosgw-admin period update --commit
{
  "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
  "epoch": 2,
  "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707",
  "sync_status": [ "[...]"
  ],
  "period_map": {
      "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",
      "zonegroups": [
          {
              "id": "d4018b8d-8c0d-4072-8919-608726fa369e",
              "name": "us",
              "api_name": "us",
              "is_master": "true",
              "endpoints": [
                  "http:\/\/rgw1:80"
              ],
              "hostnames": [],
              "hostnames_s3website": [],
              "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
              "zones": [
                  {
                      "id": "83859a9a-9901-4f00-aa6d-285c777e10f0",
                      "name": "us-east-1",
                      "endpoints": [
                          "http:\/\/rgw1:80"
                      ],
                      "log_meta": "true",
                      "log_data": "false",
                      "bucket_index_max_shards": 0,
                      "read_only": "false"
                  },
                  {
                      "id": "950c1a43-6836-41a2-a161-64777e07e8b8",
                      "name": "us-east-2",
                      "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": "4a367026-bd8f-40ee-b486-8212482ddcd7"
          }
      ],
      "short_zone_ids": [
          {
              "key": "83859a9a-9901-4f00-aa6d-285c777e10f0",
              "val": 630926044
          },
          {
              "key": "950c1a43-6836-41a2-a161-64777e07e8b8",
              "val": 4276257543
          }

      ]
  },
  "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e",
  "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0",
  "period_config": {
      "bucket_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      },
      "user_quota": {
          "enabled": false,
          "max_size_kb": -1,
          "max_objects": -1
      }
  },
  "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7",
  "realm_name": "gold",
  "realm_epoch": 2
}

注記

ピリオドを更新すると、エポックが変更され、その他のゾーンが更新した設定を受け取るようになります。

21.13.3.5 Object Gatewayの起動 #

Object Gatewayホストで、Ceph Object Gatewayサービスを起動し、有効にします。

cephuser@adm > ceph orch start rgw.us-east-2

21.13.3.6 同期の状態の確認 #

セカンダリゾーンが稼働しているときに、同期の状態を確認します。同期では、マスタゾーンで作成したユーザとバケットがセカンダリゾーンにコピーされます。

cephuser@adm > radosgw-admin sync status

同期操作の状態が出力に表示されます。例:

realm f3239bc5-e1a8-4206-a81d-e1576480804d (gold)
    zonegroup c50dbb7e-d9ce-47cc-a8bb-97d9b399d388 (us)
         zone 4c453b70-4a16-4ce8-8185-1893b05d346e (us-west)
metadata sync syncing
              full sync: 0/64 shards
              metadata is caught up with master
              incremental sync: 64/64 shards
    data sync source: 1ee9da3e-114d-4ae3-a8a4-056e8a17f532 (us-east)
                      syncing
                      full sync: 0/128 shards
                      incremental sync: 128/128 shards
                      data is caught up with source

注記

セカンダリゾーンは、バケット操作を受け付けますが、これをマスタゾーンにリダイレクトし、マスタゾーンと同期を取り、バケット操作の結果を受け取ります。マスタゾーンがダウンしている場合、セカンダリゾーンで実行されたバケット操作は失敗しますが、オブジェクト操作は成功します。

21.13.3.7 オブジェクトの検証 #

デフォルトでは、オブジェクトの同期が成功した後、オブジェクトは再度検証されません。検証を有効にするには、rgw_sync_obj_etag_verifyオプションをtrueに設定します。有効にした後で、オプションのオブジェクトが同期されます。追加のMD5チェックサムは、ソースと宛先で計算されていることを確認します。これは、マルチサイト同期を含むHTTP経由でリモートサーバからフェッチされたオブジェクトの整合性を確保するためです。このオプションを使用すると、より多くの計算が必要になるため、RGWのパフォーマンスが低下する可能性があります。

21.13.4 Object Gatewayの一般的な保守 #

21.13.4.1 同期の状態の確認 #

次のコマンドを使用して、ゾーンの複製の状態に関する情報を問い合わせることができます。

cephuser@adm > radosgw-admin sync status
        realm b3bc1c37-9c44-4b89-a03b-04c269bea5da (gold)
    zonegroup f54f9b22-b4b6-4a0e-9211-fa6ac1693f49 (us)
         zone adce11c9-b8ed-4a90-8bc5-3fc029ff0816 (us-west)
        metadata sync syncing
              full sync: 0/64 shards
              incremental sync: 64/64 shards
              metadata is behind on 1 shards
              oldest incremental change not applied: 2017-03-22 10:20:00.0.881361s
data sync source: 341c2d81-4574-4d08-ab0f-5a2a7b168028 (us-east)
                  syncing
                  full sync: 0/128 shards
                  incremental sync: 128/128 shards
                  data is caught up with source
          source: 3b5d1a3f-3f27-4e4a-8f34-6072d4bb1275 (us-3)
                  syncing
                  full sync: 0/128 shards
                  incremental sync: 128/128 shards
                  data is caught up with source

出力は同期ステータスによって異なる可能性があります。シャードは、同期中に2つの異なるタイプとして記述されます。

背後シャード: 背後シャードには、完全なデータ同期が必要なシャードと、最新ではないために増分データ同期が必要なシャードがあります。
回復シャード: 回復シャードは、同期中にエラーが発生し、再試行のマークが付けられたシャードです。このエラーは主に、バケットのロックを取得するなどの小さな問題で発生します。これは通常、自動的に解決されます。

21.13.4.2 ログの確認 #

マルチサイトの場合のみ、メタデータログ(mdlog)、バケットインデックスログ(bilog)、およびデータログ(datalog)を確認できます。これらのログを一覧にしたり、トリミングしたりすることもできます。rgw_sync_log_trim_intervalオプションはデフォルトとして20分に設定されているため、ほとんどの場合、この操作は必要ありません。手動で0に設定されていない場合は、副作用が発生する可能性があるため、いつでもトリミングする必要はありません。

21.13.4.3 メタデータマスタゾーンの変更 #

重要

メタデータマスタにするゾーンを変更する際には注意してください。ゾーンで現在のマスタゾーンからのメタデータの同期が完了していない場合、マスタに昇格するときに残っていたエントリを操作できず、これらの変更は失われます。そのため、ゾーンのradosgw-adminの同期の状態がメタデータの同期に追いつくまで待機してからそのゾーンをマスタに昇格することをお勧めします。同様に、メタデータの変更が現在のマスタゾーンで処理されていて、別のゾーンがマスタに昇格している場合、これらの変更は失われる可能性が高いです。これを回避するには、前のマスタゾーンのObject Gatewayインスタンスをシャットダウンすることをお勧めします。別のゾーンを昇格した後、その新しいピリオドはradosgw-adminピリオドの取得によってフェッチでき、そのゲートウェイを再起動できます。

ゾーン(たとえばゾーングループusのゾーンus-west)をメタデータマスタに昇格するには、そのゾーンで次のコマンドを実行します。

cephuser@ogw > radosgw-admin zone modify --rgw-zone=us-west --master
cephuser@ogw > radosgw-admin zonegroup modify --rgw-zonegroup=us --master
cephuser@ogw > radosgw-admin period update --commit

新しいピリオドが生成され、ゾーンus-westのObject Gatewayインスタンスによって、このピリオドがその他のゾーンに送信されます。

21.13.5 フェールオーバーと障害復旧機能を提供 #

マスタゾーンに障害が発生した場合、障害復旧のためにセカンダリゾーンにフェールオーバーします。

セカンダリゾーンをマスタおよびデフォルトのゾーンにします。例:
```
cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default
```
デフォルトでは、Ceph Object Gatewayはアクティブ-アクティブ設定で動作します。クラスタがアクティブ-パッシブ設定で動作するように設定されていた場合、セカンダリゾーンは読み込み専用ゾーンになっています。--read-onlyの状態を削除して、このゾーンが書き込み操作を受け付けることができるようにします。例:
```
cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default \
                                                   --read-only=false
```
ピリオドを更新して変更を有効にします。
```
cephuser@adm > radosgw-admin period update --commit
```
Ceph Object Gatewayを再起動します。
```
cephuser@adm > ceph orch restart rgw
```

前のマスタゾーンが復旧したら、操作を元に戻します。

復旧したゾーンで、現在のマスタゾーンから最新のレルムの設定をインポートします。

cephuser@adm > radosgw-admin realm pull --url=URL-TO-MASTER-ZONE-GATEWAY \
                           --access-key=ACCESS-KEY --secret=SECRET

復旧したゾーンをマスタおよびデフォルトのゾーンにします。
```
cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --master --default
```
ピリオドを更新して変更を有効にします。
```
cephuser@adm > radosgw-admin period update --commit
```
復旧したゾーンでCeph Object Gatewayを再起動します。
```
cephuser@adm > ceph orch restart rgw@rgw
```
セカンダリゾーンを読み込み専用設定にする必要がある場合、セカンダリゾーンを更新します。
```
cephuser@adm > radosgw-admin zone modify --rgw-zone=ZONE-NAME --read-only
```
ピリオドを更新して変更を有効にします。
```
cephuser@adm > radosgw-admin period update --commit
```
セカンダリゾーンでCeph Object Gatewayを再起動します。
```
cephuser@adm > ceph orch restart@rgw
```

21 Ceph Object Gateway #

21.1 Object Gatewayの制約と命名の制限 #

21.1.1 バケットの制限 #

21.1.2 保存オブジェクトの制限 #

21.1.3 HTTPヘッダの制限 #

21.2 Object Gatewayの展開 #

21.3 Object Gatewayサービスの操作 #

21.4 設定オプション #

21.5 Object Gatewayのアクセスの管理 #

21.5.1 Object Gatewayへのアクセス #

21.5.1.1 S3インタフェースへのアクセス #

21.5.1.2 Swiftインタフェースへのアクセス #

21.5.2 S3およびSwiftアカウントの管理 #

21.5.2.1 S3およびSwiftユーザの追加 #

21.5.2.2 S3およびSwiftユーザの削除 #

21.5.2.3 S3およびSwiftユーザのアクセスキーと秘密鍵の変更 #

21.5.2.4 ユーザクォータの管理の有効化 #

21.6 HTTPフロントエンド #

21.7 Object GatewayでのHTTPS/SSLの有効化 #

21.7.1 自己署名証明書の作成 #

21.7.2 SSLを使用するようにObject Gatewayを設定する #

21.8 同期モジュール #

21.8.1 同期モジュールの設定 #

21.8.2 ゾーンの同期 #

21.8.2.1 要件と前提 #

21.8.2.2 ゾーンの設定 #

21.8.3 ElasticSearch同期モジュール #

21.8.3.1 ElasticSearchの層タイプの設定パラメータ #

21.8.3.2 メタデータクエリ #

21.8.4 クラウド同期モジュール #

21.8.4.1 クラウド同期モジュールの設定 #

21.8.4.2 S3固有の設定 #

21.8.5 アーカイブ同期モジュール #

21.8.5.1 アーカイブ同期モジュールの設定 #

21.9 LDAP 認証 #

21.9.1 認証メカニズム #

21.9.2 要件 #

21.9.3 LDAP認証を使用するためのObject Gatewayの設定 #

21.9.4 カスタム検索フィルタを使用したユーザアクセスの制限 #

21.9.4.1 構成された検索フィルタをさらに制限するための部分フィルタ #

21.9.4.2 完全なフィルタ #

21.9.5 LDAP認証用アクセストークンの生成 #

21.10 バケットインデックスのシャーディング #

21.10.1 バケットインデックスのリシャーディング #

21.10.1.1 動的リシャーディング #

21.10.1.2 手動リシャーディング #

21.10.2 新しいバケットのバケットインデックスシャーディング #

21.10.2.1 マルチサイト設定 #

21.11 OpenStack Keystoneの統合 #

21.11.1 OpenStackの設定 #

21.11.2 Ceph Object Gatewayの設定 #

21.11.2.1 SSL証明書の設定 #

21.11.2.2 Object Gatewayのオプションの設定 #

21.12 プールの配置とストレージクラス #

21.12.1 配置ターゲットの表示 #

21.12.2 ストレージクラス #

21.12.3 ゾーングループおよびゾーンの設定 #

21.12.3.1 配置ターゲットの追加 #

21.12.3.2 ストレージクラスの追加 #

21.12.4 配置のカスタマイズ #

21.12.4.1 ゾーングループのデフォルトの配置の編集 #

21.12.4.2 ユーザのデフォルトの配置の編集 #

21.12.4.3 S3のデフォルトのバケットの配置の編集 #

21.12.4.4 Swiftのバケットの配置の編集 #

21.12.5 ストレージクラスの使用 #

21.13 マルチサイトObject Gateway #

21.13.1 要件と前提 #

21.13.2 マスタゾーンの設定 #

21.13.2.1 レルムの作成 #

21.13.2.2 マスタゾーングループの作成 #

21.13.2.3 マスタゾーンの作成 #

21.13.2.4 デフォルトのゾーンとグループの削除 #

21.13.2.5 システムユーザの作成 #

21.13.2.6 ピリオドの更新 #

21.13.2.7 Gatewayの起動 #

21.13.3 セカンダリゾーンの設定 #

21.13.3.1 レルムのインポート #

21.13.3.2 セカンダリゾーンの作成 #

21.13.3.3 Ceph設定ファイルの更新 #

21.13.3.4 ピリオドの更新 #