自己管理型シャーディングされたクラスターをキーファイル認証に更新

キーファイルを作成します。

キーファイル 認証では、シャーディングされたクラスター内の各mongodまたはmongosインスタンスは、配置内の他のノードを認証するための共有パスワードとしてキーファイルの内容を使用します。 正しいキーファイルを持つmongodまたはmongosインスタンスのみがシャーディングされたクラスターに参加できます。

キーの長さは 6 文字から 1024 文字の間で、base64 セット内の文字のみを含めることができます。 シャーディングされたクラスターのすべてのノードは、少なくとも 1 つの共通キーを共有する必要があります。

キーファイルは、選択した任意の方法で生成できます。たとえば、次の操作では、openssl を使用して、共有パスワードとして使用する疑似ランダムの複雑な 1024 文字の文字列を生成します。次に、chmod を使用してファイル権限を変更し、ファイル所有者のみに読み取り権限を付与します。

openssl rand -base64 756 > <path-to-keyfile>
chmod 400 <path-to-keyfile>

キーファイルの使用に関する詳細と要件については、「キーファイル」を参照してください。

Copy the keyfile to each component in the sharded cluster.

Every server hosting a mongod or mongos component of the sharded cluster must contain a copy of the keyfile.

シャーディングされたクラスターをホストしている各サーバーにキー ファイルをコピーします。 mongodまたはmongosインスタンスを実行中のユーザーがファイルの所有者であり、キーファイルにアクセスできるようにしてください。

キーファイルを、 mongodまたはmongosインスタンスをホストしているハードウェアから簡単に切断できるストレージメディア（Windows ドライブやネットワーク接続ストレージデバイスなど）にキーファイルを保存しないでください。

バランサーを無効にします。

mongoshをmongosに接続します。

sh.stopBalancer()

The balancer may not stop immediately if a migration is in progress. The sh.stopBalancer() method blocks the shell until the balancer stops.

MongoDB 6.0.3以降、 自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。

MongoDB バージョン 6.0.3 より前では、sh.stopBalancer() によってシャーディングされたクラスターの自動分割も無効になります。

Use sh.getBalancerState() to verify that the balancer has stopped.

sh.getBalancerState()

See シャーディングされたクラスター バランサーの管理 for tutorials on configuring sharded cluster balancer behavior.

Shut down all mongos instances for the sharded cluster.

接続 mongosh to each mongos and shut them down.

Use the db.shutdownServer() method on the admin database to safely shut down the mongos:

db.getSiblingDB("admin").shutdownServer()

Repeat until all mongos instances in the cluster are offline.

Once this step is complete, all mongos instances in the cluster should be offline.

Shut down config server mongod instances.

接続 mongosh to each mongod in the config server deployment and shut them down.

For replica set config server deployments, shut down the primary member last.

Use the db.shutdownServer() method on the admin database to safely shut down the mongod:

db.getSiblingDB("admin").shutdownServer()

Repeat until all config servers are offline.

Shut down shard replica set mongod instances.

For each shard replica set, connect mongosh to each mongod member in the replica set and shut them down. Shut down the primary member last.

Use the db.shutdownServer() method on the admin database to safely shut down the mongod:

db.getSiblingDB("admin").shutdownServer()

Repeat this step for each shard replica set until all mongod instances in all shard replica sets are offline.

Once this step is complete, the entire sharded cluster should be offline.

Enforce Access Control on the Config Servers.

始める each mongod in the config server replica set. Include the keyFile setting. The keyFile setting enforces both 自己管理型内部認証とメンバーシップ認証 and 自己管理型配置におけるロールベースのアクセス制御.

mongod設定は、構成ファイルまたはコマンドラインで指定できます。

構成ファイル

If using a 構成ファイル, for a config server replica set, set security.keyFile to the keyfile's path, sharding.clusterRole to configsvr, and replication.replSetName to the name of the config server replica set.

security:
  keyFile: <path-to-keyfile>
sharding:
  clusterRole: configsvr
replication:
  replSetName: <setname>
storage:
   dbpath: <path>

構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを使用して配置に接続する場合や、配置ノードを異なるホスト上で実行する場合は、 net.bindIp設定を指定します。

--configオプションと構成ファイルへのパスを指定して、mongod を起動します。

mongod --config <path-to-config>

コマンドライン

If using the command line parameters, for a config server replica set, start the mongod with the -keyFile, --configsvr, and --replSet parameters.

mongod --keyFile <path-to-keyfile> --configsvr --replSet <setname> --dbpath <path>

構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを配置に接続する場合、または配置ノードを異なるホスト上で実行する場合は、 --bind_ipを指定します。

For more information on command line options, see the mongod reference page.

Make sure to use the original replica set name when restarting each member. You cannot change the name of a replica set.

Enforce Access Control for each Shard in the Sharded Cluster.

keyFileパラメータを使用してmongodを実行すると、自己管理型配置で 自己管理型内部認証とメンバーシップ認証とロールベースのアクセス制御 の両方が強制されます。

構成ファイルまたはコマンドラインのいずれかを使用して、レプリカセット内の各mongodを起動します。

構成ファイル

If using a 構成ファイル, set the security.keyFile option to the keyfile's path and the replication.replSetName option to the original name of the replica set.

security:
  keyFile: <path-to-keyfile>
replication:
  replSetName: <setname>
storage:
   dbPath: <path>

構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを使用して配置に接続する場合や、配置ノードを異なるホスト上で実行する場合は、 net.bindIp設定を指定します。

--configオプションと構成ファイルへのパスを指定して、mongod を起動します。

mongod --config <path-to-config-file>

コマンドライン

If using the command line parameters, start the mongod and specify the --keyFile and --replSet parameters.

mongod --keyfile <path-to-keyfile> --replSet <setname> --dbpath <path>

構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを配置に接続する場合、または配置ノードを異なるホスト上で実行する場合は、 --bind_ipを指定します。

For more information on startup parameters, see the mongod reference page.

Make sure to use the original replica set name when restarting each member. You cannot change the name of a replica set.

Repeat this step until all shards in the cluster are online.

Create a Shard-Local User Administrator (Optional).

For each shard replica set in the cluster, connect mongosh to the primary member over the localhost interface. You must run mongosh on the same machine as the target mongod to use the localhost interface.

Create a user with the userAdminAnyDatabase role on the admin database. This user can create additional users for the shard replica set as necessary. Creating this user also closes the 自己管理型配置における Localhost 例外.

The following example creates the shard-local user fred on the admin database.

admin = db.getSiblingDB("admin")
admin.createUser(
  {
    user: "fred",
    pwd: passwordPrompt(),  // or cleartext password
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
  }
)

Enforce Access Control for the mongos servers.

keyFileパラメータを使用してmongodを実行すると、自己管理型配置で 自己管理型内部認証とメンバーシップ認証とロールベースのアクセス制御 の両方が強制されます。

構成ファイルまたはコマンドラインのいずれかを使用して、レプリカセット内の各mongosを起動します。

構成ファイル

If using a 構成ファイル, set the security.keyFile to the keyfile`s path and the sharding.configDB to the replica set name and at least one member of the replica set in <replSetName>/<host:port> format.

security:
  keyFile: <path-to-keyfile>
sharding:
  configDB: <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019,...

構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを使用して配置に接続する場合や、配置ノードを異なるホスト上で実行する場合は、 net.bindIp設定を指定します。

--configオプションと構成ファイルへのパスを指定して、mongos を起動します。

mongos --config <path-to-config-file>

コマンドライン

コマンドラインmongos --keyFile--configdbパラメータを使用する場合は、 を起動し、 パラメータと パラメータを指定します。

mongos --keyFile <path-to-keyfile> --configdb <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019,...

構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを配置に接続する場合、または配置ノードを異なるホスト上で実行する場合は、 --bind_ipを指定します。

At this point, the entire sharded cluster is back online and can communicate internally using the keyfile specified. However, external programs like mongosh need to use a correctly provisioned user in order to read or write to the cluster.

Connect to the mongos instance over the localhost interface.

mongosh をローカルホスト インターフェース経由で mongos インスタンスの 1 つに接続します。mongosh は mongos インスタンスと同じ物理マシン上で実行する必要があります。

配置用のユーザーが作成されていないため、ローカルホスト インターフェースのみ使用できます。最初のユーザーが作成された後に、 ローカルホスト インターフェースは閉じます。

ユーザー管理者を作成します。

db.createUser() メソッドを使用してユーザーを追加します。このユーザーには、admin データベース上で userAdminAnyDatabase 以上のロールを付与する必要があります。

次の例では、 adminデータベースにユーザーfredを作成しています。

admin = db.getSiblingDB("admin")
admin.createUser(
  {
    user: "fred",
    pwd:  passwordPrompt(),     // or cleartext password
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
  }
)

データベース管理操作に関連する組み込みロールの全リストは、「データベースユーザー ロール」を参照してください。

ユーザー管理者として認証します。

ユーザー管理者として認証し、追加のユーザーを作成するには、次のようにしdb.auth() 。

db.getSiblingDB("admin").auth("fred", passwordPrompt()) // or cleartext password

パスワードの入力を求められたら、入力します。

または、 -u <username> 、 -p <password> 、 --authenticationDatabase "admin"パラメータを使用して、新しいmongoshセッションを対象レプリカセット ノードに接続します。 に接続するには 、 自己管理型配置で Localhost 例外 をmongos 使用する必要があります。

mongosh -u "fred" -p  --authenticationDatabase "admin"

-pコマンドライン オプションにパスワードを指定しない場合、 mongoshはパスワードの入力を要求します。

クラスターマネジメントの管理ユーザーの作成

The cluster administrator user has the clusterAdmin role for the sharded cluster and not the shard-local cluster administrator.

次の例では、 adminデータベースにユーザーraviを作成しています。

db.getSiblingDB("admin").createUser(
  {
    "user" : "ravi",
    "pwd" : passwordPrompt(),     // or cleartext password
    roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
  }
)

レプリカセットとシャーディングされたクラスターの操作に関連する組み込みロールの完全なリストについては、「クラスター管理ロール」を参照してください。

Authenticate as cluster admin.

To perform sharding operations, authenticate as a clusterAdmin user with either the db.auth() method or a new mongosh session with the username, password, and authenticationDatabase parameters.

Start the balancer.

Start the balancer.

sh.startBalancer()

MongoDB 6.0.3以降、 自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。

MongoDB バージョン 6.0.3 より前では、sh.startBalancer() によってシャーディングされたクラスターの自動分割も有効になります。

Use the sh.getBalancerState() to verify the balancer has started.

See シャーディングされたクラスター バランサーの管理 for tutorials on the sharded cluster balancer.

追加のユーザーを作成します（任意）。

ユーザーを作成して、クライアントがシャーディングされたクラスターに接続してアクセスできるようにします。 使用可能な組み込みロールについては、「 データベースユーザーのロール 」を参照してください。たとえば、 readやreadWriteなどです。 また、管理ユーザーを追加することもできます。 ユーザーの詳細については、「自己管理型配置のユーザー 」を参照してください。

追加のユーザーを作成するには、 userAdminAnyDatabaseまたはuserAdminロールを持つユーザーとして認証する必要があります。