第5章 ユーザー管理

Red Hat Ceph Storage クラスターのユーザーは、個人またはアプリケーションなどのシステムアクターです。ユーザーを作成すると、ストレージクラスター、そのプール、およびプール内のデータにアクセスできる対象を制御できます。

Ceph の概念にはユーザーの タイプ があります。ユーザー管理の目的で、タイプは常に client になります。Cephは、ピリオド (.) で区切られたユーザータイプとユーザーID で構成される形式でユーザーを識別します (例: TYPE.ID、client.admin、または client.user1)。ユーザーの入力は、Ceph Monitor および OSD も Cephx プロトコルを使用しますが、それらはクライアントではないために必要になります。ユーザータイプの分類することにより、クライアントユーザーと他のユーザーを区別でき、アクセス制御、ユーザーの監視および追跡可能性をさらに単純化します。

Ceph コマンドラインを使用すると、コマンドラインでの使用に応じて、タイプを使用せずにユーザーを指定できるため、Ceph のユーザータイプが混乱する場合があります。--user または --id を指定した場合は、タイプを省略できます。そのため、client.user1 は user1 として簡単に入力できます。--name または -n を指定する場合は、client.user1 などのタイプおよび名前を指定する必要があります。ベストプラクティスとして、可能な限りタイプと名前を使用することが推奨されます。

Ceph では、認証されたユーザーがモニターおよび OSD の機能を実行するために行う承認を「capabilities」(caps) という用語を使用して表現しています。ケイパビリティーは、プール内のデータやプール内の namespace へのアクセスを制限することもできます。ユーザーを作成または更新する際に、Ceph 管理ユーザーはユーザーのケイパビリティーを設定します。

ケイパビリティーの構文は以下の形式に従います。

<daemon_type> 'allow <capability>' [<daemon_type> 'allow <capability>']

以下のエントリーは、それぞれのケイパビリティーについて説明します。

プールは Ceph クライアントのストレージストラテジーを定義し、そのストラテジーの論理パーティションとして機能します。

Ceph デプロイメントでは、さまざまなタイプのユースケース (クラウドボリューム/イメージ、オブジェクトストレージ、ホットストレージ、コールドストレージなど) をサポートするプールを作成するのが一般的です。OpenStack のバックエンドとして Ceph をデプロイする場合、標準的なデプロイメントにはボリューム、イメージ、バックアップと、client.glance、client.cinder などユーザーのプールが含まれます。

プール内のオブジェクトは、プール内のオブジェクトの論理グループである namespace に関連付けることができます。ユーザーのプールへのアクセスは、ユーザーによる読み書きが名前空間内でのみ行われるように、その名前空間と関連付けることができます。プール内の名前空間に書き込まれたオブジェクトには、その名前空間にアクセスできるユーザーのみがアクセスできます。

名前空間の合理的な理由は、各プールが OSD にマッピングされる配置グループのセットを作成するため、プールはユースケース別にデータを分離するために計算量の多い方法になる可能性があるからです。複数のプールが同じ CRUSH 階層とルールセットを使用する場合、OSD のパフォーマンスは負荷の増加に応じて低下する可能性があります。

たとえば、プールには、OSD ごとに約 100 個の配置グループが必要です。そのため、1000 個 の OSD を持つ模範的なクラスタは、1 つのプールに対して 10 万個の配置グループを持つことになります。同じ CRUSH 階層とルールセットにマップされた各プールは、例示的なクラスターにさらに 10 万の配置グループを作成します。一方、namespace にオブジェクトを書き込むと、別のプールの計算オーバーヘッドを排除して、namespace をオブジェクト名に関連付けられます。ユーザーまたはユーザーセットに個別のプールを作成するのではなく、名前空間を使用できます。