すべての人に良い一日を！ 最近、著者は、x.509証明書を使用した認証だけでなく、レプリケーションとシャーディングの設定でMongoDBクラスターを展開するという刺激的な仕事を著者に投げかけました。 この記事では、まず自分の考えを述べ、経験を共有したいと思います。 些細なことではなく、初めて行うことができないものもあるため、データのシャーディングと一般的なMongoDBの操作に精通している人にとっては、ステップバイステップの手順が役立つと思います。
また、クラスター構成の追加/変更に関する推奨事項と、記事自体または主題に関する質問または批判に非常に満足しています。
エントリー
クラスターが導入されたプロジェクトは、クライアントデバイスの統計を収集し、サイトまたはRest-APIを介してそのプロビジョニングを集約するサービスです。 プロジェクトは長い間、低負荷で安定して動作しており、その結果、「そのまま」インストールされたMongoDBサーバーは（シャーディングとデータ複製なしで）完璧に機能し、冠のデータベースの毎日のバックアップによって「静かな睡眠」が提供されました。 Thunderは、多数のデバイス、データ、およびリクエストを持ついくつかの大規模なクライアントが到着した後、通常どおり素晴らしい瞬間を迎えました。 その結果、古いデータベースへのクエリの許容できないほど長い実行が行われ、その結果、データがほとんど失われたときにサーバーが中断しました。
したがって、一晩で、将来のスケーラビリティの可能性とともに、フォールトトレランス、データセキュリティ、および生産性を向上させる作業を実行する必要が生じました。 MongoDBの既存の可能性を使用して、発生した問題を排除すること、つまり、レプリケーションを使用してシャードクラスターを整理し、既存のデータをそこに移行することが決定されました。
理論のビット
まず、ShardedCluster MongoDBとその主要コンポーネントについて少し理解してください。
シャーディング自体は、データを保存してデータへのアクセスを提供するコンピューティングシステムの
水平スケーリングの方法です。
垂直スケーリングとは異なり、たとえば、より強力なCPUに切り替えたり、使用可能なRAMまたはディスク領域を追加するなど、単一サーバーのパフォーマンスを向上させることでシステムパフォーマンスを向上できる場合、シャーディングはデータセットと負荷を複数のサーバーに分散することで機能します必要に応じて新しいサーバーを追加します（これは単なるケースです）。
このようなスケーリングの利点は、拡張の可能性がほぼ無限であることです。一方、垂直方向にスケーラブルなシステムは、たとえばホスティングプロバイダーから利用可能なハードウェアによって意図的に制限されます。
MongoDBシャードクラスターへの切り替えから何が期待されますか？ まず、クラスターのシャード間で読み取り/書き込み操作の負荷分散を取得する必要があります。次に、高いフォールトトレランス（一定のデータ可用性）と過剰なコピー（レプリケーション）によるデータの安全性を実現する必要があります。
MongoDBの場合、データシャーディングはコレクションレベルで発生します。つまり、既存のクラスターシャード間でどのコレクションデータを分散するかを明示的に指定できます。 これは、分割可能なコレクションのドキュメントセット全体が同じサイズの部分（チャンク（チャンク）に分割されることを意味します。チャンク（チャンク）は、モンガバランサーによってクラスターのシャレード間でほぼ均等に移行されます）。
すべてのデータベースとコレクションのシャーディングはデフォルトで無効になっており、
adminや
configなどのクラスターシステムデータベースをシャードすることはできません。 これを実行しようとすると、Mongaから明確な拒否が得られます。
mongos> sh.enableSharding("admin") { "ok" : 0, "errmsg" : "can't shard admin database" }
シャッフルされたMongoDBクラスターには、3つの前提条件があります。実際、
シャードの存在、クラスターとそのクライアント間のすべての通信は排他的に
mongosルーターを介して実行される必要があります。瀬田）
mongodbの公式ドキュメントには、
「実稼働環境では
、すべてのシャードはレプリカセットである必要があります」と書かれてい
ます。 レプリカ
セットであるため
、各シャードは、データの複数のコピーにより、フォールトトレランスを向上させ（レプリカの任意のインスタンスでのデータ可用性の面で）、そしてもちろん、最高の保存を保証します。
レプリカセットは、同じデータセットのコピーを保存する複数の実行中のmongodインスタンスの組み合わせです。 シャードレプリカの場合、これはmongaバランサーによってこのシャードに渡されるチャンクのセットになります。
レプリカインスタンスの1つがメインインスタンス（
PRIMARY ）として割り当てられ、すべてのデータ書き込み操作を（保守および読み取り中に）受け入れ、残りのモンゴッドは
SECONDARYと宣言され、PRIMARYとの非同期通信で、データセットのコピーを更新します。 データの読み取りにも使用できます。 何らかの理由でPRIMARYがアクセス不能になり、レプリカの他のメンバーとのやり取りをやめると、レプリカの使用可能なすべてのメンバーのうち、新しいPRIMARYの役割に対する
投票が発表されます。 実際、PRIMARYおよびSECONDARYに加えて、レプリカセットには第3の種類の参加者が存在する可能性があります。これがアービター（
ARBITER ）です。
レプリカのアービターは、データセットをコピーする役割を果たさず、代わりに投票の重要なタスクを解決し、投票の行き止まりからレプリカを保護するように設計されています。 レプリカに偶数人の参加者がいて、同じ合計投票数で2人の応募者に半数で投票する状況を想像してください。そのような「偶数」の発言に仲裁人を追加すると、彼は「データセットの別のコピーを処理するためのリソースを必要とせずに、「PRIMARY」の位置。
レプリカセットは、まさにmongodインスタンスの結合であることに注意してください。つまり、1台のサーバーにレプリカを構築し、異なる物理メディアにあるフォルダーをデータストレージとして指定し、データセキュリティを実現することを妨げませんが、それでも理想的なオプションです。これは、異なるサーバーでmongodを起動するレプリカ組織です。 一般的に、これに関して、MongoDBシステムは非常に柔軟であり、厳しい制限を課すことなく、ニーズと機能に基づいて必要な構成を組み立てることができます。 シャードクラスターのコンテキスト外のレプリカセットは、典型的なMongoDBサーバー組織スキームの1つであり、高度なフォールトトレランスとデータ保護を提供します。 この場合、レプリカの各参加者は、シャードチャンクのセットで定義された部分ではなく、データベースデータセット全体の完全なコピーを保存します。
インフラ
以下のクラスター構成は、3つのOpenVZ仮想コンテナー（VBO）で構築されています。 各仮想マシンは、個別の専用サーバーに配置されます。
2つの仮想マシン（以降
server1.cluster.comおよび
server2.cluster.com ）にはより多くのリソースがあり
ます -それらはクライアントへのデータの複製、分割、提供を担当します。 3番目のマシン（
server3.cluster.com ）の構成はより弱く、その目的はmongodアービターのインスタンスの動作を保証することです。
構築されたクラスターには、3つのシャレードがあります。 このスキームでは、レプリカセットに基づいてシャードを構築するという推奨事項に従いましたが、いくつかの仮定がありました。 クラスターの各シャードレプリカセットには、3つの異なるサーバーで実行される独自のPRIMARY、SECONDARY、およびARBITERがあります。 また、データ複製を使用して構築された構成サーバーもあります。
ただし、サーバーは3つしかなく、そのうちの1つはデータ複製機能を実行しません（構成レプリカの場合のみ）。したがって、3つの断片はすべて2つのサーバーに実際に配置されます。
Mongiドキュメントの図では、Mongosはアプリケーションサーバー上に描かれています。 私はこのルールを破り、Mongos（2つあります）をデータサーバーに配置することにしました：server1.cluster.comとserver2.cluster.com。アプリケーションサーバー上のmongodbの追加の構成を取り除き、アプリケーションサーバーに関連する特定の制限のため。 アプリケーションサーバーは2つのMongoのいずれかに接続できるため、一方に問題が発生した場合、短いタイムアウト後にもう一方に再接続します。 次に、アプリケーションサーバーは、ラウンドロビンが構成されているDNS番目の背後に配置されます。 交互に2つのアドレスのいずれかを発行し、接続（クライアント要求）の基本的なバランスを提供します。 それをある種の「スマートな」DNSに置き換える計画があります（誰かがコメントで良い解決策を教えてくれるかもしれません。感謝します！）クライアントの位置情報に適切なサーバーを発行するため。
明確にするために、形成されたクラスターの一般的な図に、サーバーとそれらで実行されているアプリケーションの名前を示します。 コロンは、指定されたアプリケーションポートを示します。
初期設定
server1.cluster.comにアクセスし、公式リポジトリから最新のMongoDB Community Editionパッケージをインストールします。 アセンブリの時点で、クラスターはバージョン3.2.8です。 私の場合、Debian 8オペレーティングシステムはすべてのクラスターマシンにインストールされています。OSにインストールするための詳細な手順は、公式
ドキュメントで見つけることができます。
公開キーをシステムにインポートし、パッケージのリストを更新し、一連のユーティリティを使用してmongodbサーバーをインストールします。
server1.cluster.com:~
できた！ 実行されたアクションの結果として、マシンMongoDBですでに稼働しているサーバーを取得します。 今のところ、mongodサービスを無効にします（これに戻ります）。
server1.cluster.com:~
次に、クラスターのすべてのデータを保存するディレクトリを作成します。これをパス「/ root / mongodb」に配置します。 内部では、次のディレクトリ構造を形成します。
. ├── cfg ├── data │ ├── config │ ├── rs0 │ ├── rs1 │ └── rs2 ├── keys └── logs
dataサブディレクトリに、レプリカ（構成レプリカを含む）のデータを直接保存します。 cfgでは、必要なmongo {d / s}インスタンスを実行するための構成ファイルを作成します。 キーでは、クラスターメンバーのx.509認証用のキーと証明書をコピーします。 ログフォルダの目的は、誰もが理解していると思います。
同様に、インストールとディレクトリの手順を残りの2台のサーバーで繰り返す必要があります。
クラスターのコンポーネントの構成とリンクに進む前に、必要なすべてが機能することを確認してください。 「/ root / mongodb / data / rs0」でデータのディレクトリを指定して、ポート27000でmongodインスタンスを実行します。
mongod --port 27000 --dbpath /root/mongodb/data/rs0
同じサーバーで別のターミナルを開き、実行中のmongodに接続します。
mongo --port 27000
すべてがうまくいけば、シェルmongodbになり、いくつかのコマンドを実行できます。 デフォルトでは、mongはテストデータベースに切り替えます。コマンドを入力することでこれを確認できます。
> db.getName() test
次のコマンドで不要なデータベースを削除します。
> db.dropDatabase() { "ok" : 1 }
そして、新しいデータベースを初期化して、それに切り替えて実験します。
> use analytics switched to db analytics
次に、データを入力してください。 根拠にならないようにするために、特定の統計を収集するシステムの例を使用して、記事でこれ以降のすべての操作を検討することを提案します。
いくつかのデバイスを追加します。
> db.sensors.insert({'s':1001, 'n': 'Sensor1001', 'o': true, 'ip': '192.168.88.20', 'a': ISODate('2016-07-20T20:34:16.001Z'), 'e': 0}) WriteResult({ "nInserted" : 1 }) > db.sensors.insert({'s':1002, 'n': 'Sensor1002', 'o': false, 'ip': '192.168.88.30', 'a': ISODate('2016-07-19T13:40:22.483Z'), 'e': 0}) WriteResult({ "nInserted" : 1 })
ここに
sはセンサーのシリアル番号です。
nはその文字列識別子です。
o-現在のステータス（オンライン/オフライン）;
ip-センサーのIPアドレス。
aは最後のアクティビティの時間です。
eはエラーの兆候です。
そして今、フォームのいくつかの統計レコード：
> db.statistics.insert({'s':1001, 'ts': ISODate('2016-08-04T20:34:16.001Z'), 'param1': 123, 'param2': 23.45, 'param3': “OK”, 'param4': True, 'param5': '-1000', 'param6': [1,2,3,4,5]) WriteResult({ "nInserted" : 1 })
sはセンサーの番号です。
ts-タイムスタンプ。
param1..param6-いくつかの統計。
統計分析サービスのクライアントは、しばしば集約されたクエリを実行して、デバイスから収集された統計に関する代表的なデータを取得します。 ほとんどすべてのクエリでは、「センサーシリアル番号」（フィールドs）が関係しています。 ソートとグループ化がよく適用されるため、最適化（およびシャーディング）のために、統計コレクションにインデックスを追加します。
mongos> db.statistics.ensureIndex({"s":1})
必要なインデックスの選択と作成は別の議論のトピックですが、今のところはこれに限定します。
x.509証明書を使用した認証
問題を理解するために、少し進んで、異なるサーバーで実行されているmongodインスタンスを想像します。レプリカに結合し、mongosをそれらに接続し、形成されたクラスターにクライアントを安全に接続できるようにします。 もちろん、データ交換の参加者は接続時に認証される必要があり（信頼される）、データチャネルも保護されることが望ましいです。 この場合、MongoDBにはTSL / SSLのサポートといくつかの認証メカニズムがあります。 クラスター内のデータ交換の参加者間で信頼を確立するためのオプションの1つは、キーと証明書の使用です。 このオプションを使用するメカニズムの選択に関しては、Mongiドキュメントに推奨事項があります。
「キーファイルは最低限のセキュリティ形式であり、テスト環境または開発環境に最適です。 実稼働環境では、 x.509証明書の使用をお勧めします 。X.509は、公開鍵インフラストラクチャと特権管理のためのITU-T標準です。 この規格は、署名されたデジタル証明書を使用して、形式と公開キーの配布方法を定義します。 証明書は、公開キーをサブジェクト（証明書のユーザー）に関連付けます。 この接続の信頼性は、信頼できる認証局によって実行されるデジタル署名によって実現されます。
（x.509に加えて、MongoDBには非常に信頼性の高いエンタープライズレベルのメソッドもあり
ます -これらは
Kerberos認証と
LDAPプロキシ認証局認証です ）、これは私たちの場合ではなく、ここでx.509認証の設定について説明します。
x.509証明書を使用する認証メカニズムには、クラスターへのセキュアなTSL / SSL接続が必要です。これは、対応するmongod start引数
--sslMode 、または構成ファイルの
net.ssl.modeパラメーターによって有効になります。 この場合、サーバーに接続するクライアントの認証は、ログインとパスワードではなく、証明書の認証になります。
このメカニズムのコンテキストでは、生成された証明書は2つのタイプに分けられます：
クラスターメンバー証明書 -異なるマシン上のmongodインスタンスの内部認証を目的とした特定のサーバーにバインドし、
クライアント証明書 -クラスター外部クライアントの認証を目的とした別のユーザーにバインドします。
x.509条件を満たすために、単一のキー、いわゆる「
認証局 」
認証局（CA）が必要です。 それに基づいて、クライアント証明書とクラスターメンバー証明書の両方が発行されるため、まず、CAの秘密キーを作成します。 次のすべてのアクションを正しく実行し、秘密鍵を別のマシンに保存しますが、この記事では最初のサーバー（server1.cluster.com）ですべてのアクションを実行します。
server1.cluster.com:~/mongodb/keys
秘密のフレーズを導入する提案では、
「temporis $ filia $ veritas」などの信頼できる組み合わせを入力して確認します（もちろん、別の複雑なものがあります）。 このフレーズは覚えておく必要があります。新しい証明書に署名するために必要になります。
次に、CA証明書を作成します（コマンドを起動した直後に、指定したキー（「key」パラメーターで）からシークレットフレーズを入力するよう求められます）：
server1.cluster.com:~/mongodb/keys
daysパラメータに注意を
促します-それは証明書の期間に責任があります。 私が現在取り組んでいるプロジェクトに誰がどのくらい参加するかわかりません。不快な驚きをなくすために、36,500日間の人生の証明書を示します。これは100年に相当します（非常に楽観的ですね）。
フレーズを確認した後、証明書を所有する組織に関する情報を入力するよう求められます。 私たちの大きな組織が「SomeSysyems」と呼ばれ、モスクワにあると想像してください（入力された情報はコロンの後に続きます）。
Country Name (2 letter code) [AU]: RU State or Province Name (full name) [Some-State]: MoscowRegion Locality Name (eg, city) []: Moscow Organization Name (eg, company) [Internet Widgits Pty Ltd]: SomeSystems Organizational Unit Name (eg, section) []: Statistics Common Name (eg server FQDN or YOUR name) []: CaServer Email Address []: info@SomeSystems.com
いいね！ CAの準備が整い、これを使用して、クライアント証明書とクラスターメンバーの証明書に署名できます。 入力したデータの有効性はCA証明書自体の機能には影響しませんが、署名された証明書は入力された値に依存するようになります。これについては後で説明します。
クラスタメンバーの証明書を作成する手順（外部クライアントの証明書は個別に検討されます）は次のとおりです。
- 秘密鍵（* .key-ファイル）と「証明書要求」（csrファイル）を生成します。 CSR（証明書署名要求）は、証明書と公開キーを発行した組織に関するエンコードされた情報を含むテキストファイルです。
- 認証局の秘密鍵と公開証明書を使用して、現在のサーバーの証明書に署名します。
- 新しいキーとクラスターメンバーの証明書から、クラスターへの接続に使用するPEMファイルを作成します。
最初のサーバー（server1.cluster.com）の秘密キーと証明書要求を作成します。 CN（Common Name）を除き、すべてのフィールドにルート証明書の場合と同じままである場合、重要な詳細に注意を払います。 証明書ごとに一意にする必要があります。 この場合、特定のサーバーの完全修飾ドメイン名
-FQDN（完全修飾ドメイン名）が値として示されます。
server1.cluster.com:~/mongodb/keys
空のままにした余分なフィールド。 追加のパスワード（チャレンジパスワード[] :)を指定する場合、mongod構成では、パラメーター
net.ssl.PEMKeyPasswordおよび
net.ssl.clusterPasswordが担当するこの証明書のパスワードを指定する必要があります。 （これらのパラメータの詳細は、
こちらのドキュメントにあり
ます ）。
次に、CA証明書でCSRファイルに署名し、公開証明書（* .crtファイル）を取得します。
server1.cluster.com:~/mongodb/keys
次に、PEMファイルを作成する必要があります。
server1.cluster.com:~/mongodb/keys
mongodインスタンスを起動するときにPEMファイルを直接使用し、構成で指定します。
次に、操作を繰り返して残りのサーバーの証明書を作成する必要があります。 完全に理解するために、すべてのコマンドを引用します。
server1.cluster.com:~/mongodb/keys
（追加フィールドは入力されませんでした）
CA証明書でCSRファイルに署名して、2番目のサーバーのパブリック証明書（* .crtファイル）を取得します。
server1.cluster.com:~/mongodb/keys
次に、PEMファイルを作成する必要があります。
server1.cluster.com:~/mongodb/keys
3番目のサーバー証明書についても同様です。
server1.cluster.com:~/mongodb/keys
（追加フィールドは入力されませんでした）
3番目のサーバーの公開証明書（* .crtファイル）を取得するには、CA証明書でCSRファイルに署名します。
server1.cluster.com:~/mongodb/keys
PEMファイルを作成します。
server1.cluster.com:~/mongodb/keys
すべてのキーと証明書が最初のサーバーで作成され、必要に応じて対応するサーバーに移動されたことを繰り返します。 したがって、3つのサーバーのそれぞれには、パブリックCA証明書（mongodb-CA-cert.crt）とこのサーバーのPEMファイル（server <$ N> .pem）が必要です。
Mongodインスタンスの構成
正しく起動するには、いくつかのパラメーターをmongodインスタンスに渡す必要があります。 これを行うには、構成ファイルを使用するか、必要なすべての値を引数として端末コマンドに渡します。 ほぼすべての構成パラメーターは、対応するコマンドライン引数に反映されます。 私の意見では、別の構造化ファイルの方が読みやすく、補足しやすいため、構成ファイルのオプションはより正当化されます。この場合、プログラムのインスタンスの起動は、単一の引数-構成ファイルの場所を渡すだけになります：
mongod --config <path-to-config-file>
そのため、最初のサーバーで最初の断片レプリカ（rs0）のmongodインスタンスの構成ファイルを作成します。
# # /root/mongodb/cfg/mongod-rs0.conf # replication: replSetName: "rs0" # net: port: 27000 ssl: mode: requireSSL # PEMKeyFile: /root/mongodb/keys/server1.pem clusterFile: /root/mongodb/keys/server1.pem CAFile: /root/mongodb/keys/mongodb-CA-cert.crt weakCertificateValidation: false # allowInvalidCertificates: false # security: authorization: enabled # clusterAuthMode: x509 # - MONGODB-X509 storage: dbPath : /root/mongodb/data/rs0 # systemLog: destination: file # path: /root/mongodb/logs/mongod-rs0.log # - logAppend: true # -
2番目のシャードレプリカ（rs1）に同様のファイルを作成しますが、ポート、レプリカ名、データディレクトリの場所、およびログファイルを変更します。 # # /root/mongodb/cfg/mongod-rs1.conf # replication: replSetName: "rs1" net: port: 27001 ssl: mode: requireSSL PEMKeyFile: /root/mongodb/keys/server1.pem clusterFile: /root/mongodb/keys/server1.pem CAFile: /root/mongodb/keys/mongodb-CA-cert.crt weakCertificateValidation: false allowInvalidCertificates: false security: authorization: enabled clusterAuthMode: x509 storage: dbPath : /root/mongodb/data/rs1 systemLog: destination: file path: /root/mongodb/logs/mongod-rs1.log logAppend: true
そして、3番目のレプリカ（rs2）の例えで： # # /root/mongodb/cfg/mongod-rs2.conf # replication: replSetName: "rs2" net: port: 27002 ssl: mode: requireSSL PEMKeyFile: /root/mongodb/keys/server1.pem clusterFile: /root/mongodb/keys/server1.pem CAFile: /root/mongodb/keys/mongodb-CA-cert.crt weakCertificateValidation: false allowInvalidCertificates: false security: authorization: enabled clusterAuthMode: x509 storage: dbPath : /root/mongodb/data/rs2 systemLog: destination: file path: /root/mongodb/logs/mongod-rs2.log logAppend: true
3つのシャードレプリカを編成するインスタンスに加えて、クラスターには、レプリカ（rscfg）に基づいて構築される構成サーバーの操作を提供するmongodが存在します。構成サーバーの役割は1つのmongodによって（シャードと同様に）実行できることを説明する価値がありますが、信頼性とフォールトトレランスを確保するために、構成サーバーもレプリカセットに基づいて作成することをお勧めします。サービスレプリカ構成ファイルは、mongodインスタンスにその特別な目的を伝える「sharding.clusterRole」パラメーターの存在がデータレプリカと異なります。 # # /root/mongodb/cfg/mongod-rscfg.conf # sharding: clusterRole: configsvr # - replication: replSetName: "rscfg" # net: port: 27888 ssl: mode: requireSSL PEMKeyFile: /root/mongodb/keys/server1.pem clusterFile: /root/mongodb/keys/server1.pem CAFile: /root/mongodb/keys/mongodb-CA-cert.crt weakCertificateValidation: false allowInvalidCertificates: false security: authorization: enabled clusterAuthMode: x509 storage: dbPath : /root/mongodb/data/config systemLog: destination: file path: /root/mongodb/logs/mongod-rscfg.log logAppend: true
次に、作成したすべての構成ファイルを他のサーバーにコピーする必要があります。コピー後、対応するサーバーの証明書を指定する必要があるパラメーターnet.ssl.PEMKeyFileおよびnet.ssl.clusterFileの値を変更することを忘れないでください（server2.pem、server3.pem）。レプリカセットのセットアップ
最初のサーバーでは、ポート27000でmongodを実行します。「戦闘」構成ファイルを指定せずに、ポートとデータディレクトリのみを指定します。これは、起動されたmongodインスタンスがまだレプリカのメンバーであるとは見なさず、構成ファイルで指定した接続と認証の厳格な要件を課さないようにするために行われます。 mongod --port 27000 --dbpath /root/mongodb/data/rs0
次に、実行中のmongodに接続し、将来のレプリカのスーパーユーザーを追加する必要があります。これにより、将来、構成ファイルで指定された許可を有効にした後、初期化を含むレプリカを変更する権利が得られます。実践が示しているように、x.509承認を含めても、従来のユーザーをデータベースに追加することは禁止されていません（ログインとパスワードによって認証されます）。それにもかかわらず、私はこの機会に頼らず、クラスターレベルとレプリカ形成中の両方でx.509メカニズムを使用することにしました。明確にするために、現在作成しているユーザーは、このレプリカのレベルのユーザーであると言います。他のレプリカから、およびクラスターレベルでは、利用できません。新しいユーザーについては、「x.509認証」セクションで既に行ったものと同様の別の証明書を作成する必要があります。この証明書の違いは、クラスタメンバー（mongodインスタンスまたはサーバー）ではなく、アカウントに関連付けられていることです。つまり、クライアント証明書を作成します。この証明書は、最初のシャード（rs0）のセットのスーパーユーザー（ルートロール）レプリカに関連付けられます。MongoDBの組み込みロールは、公式ドキュメントのこのセクションにあります。CAサーバーにアクセスする必要があります。そして、別のキーと証明書署名要求を生成します。 server1.cluster.com:~/mongodb/keys
証明書に署名します（ここでも、CAキーからの秘密のフレーズが必要になります）。 server1.cluster.com:~/mongodb/keys
PEMファイルを作成します。 server1.cluster.com:~/mongodb/keys
パラメーターOrganization Unit Name（OU）に注意してください。つまり、クライアント証明書を生成するときは、クラスターメンバーの証明書を生成するときに指定したものとは異なる必要があります。そうでない場合、クラスターメンバーが証明書に持っているものと等しいOUを持つサブジェクト（以下で説明）を含むクラスターにユーザーを追加すると、mongaはエラーで拒否する場合があります。 { "ok" : 0, "errmsg" : "Cannot create an x.509 user with a subjectname that would be recognized as an internal cluster member.", "code" : 2 }
x.509メカニズムによる承認のためのユーザーはやや変わった方法で追加されます。名前とパスワードではなく、ユーザーに対応する証明書の識別子（サブジェクト）を指定する必要があります。次のコマンドを実行して、PEMファイルから件名を取得できます。 server1.cluster.com:~/mongodb/keys
出力では、「subject =」で始まる行の内容に関心があります（「subject =」自体とスペースなし）。mongodに接続し、ユーザーを追加します。 mongo --port 27000
> db.getSiblingDB("$external").runCommand({createUser: "CN=rsroot,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU", roles: [{role: "root", db: "admin"}] })
$ externalは、資格情報がMongoDBの外部に格納されているユーザーの作成に使用される仮想データベースの名前です。たとえば、この場合のように（認証には証明書ファイルが使用されます）。次に、適切な構成ファイルを使用して、mongaシェルを終了し、mongodを再起動します。同じことを2番目と3番目のサーバーで行う必要があります。したがって、最初のレプリカ（rs0）のすべてのMongodesを開始する必要があります。レプリカの作成されたスーパーユーザー（rsroot）の証明書を使用してmongodに接続し、証明書のサブジェクトをユーザー名として指定して認証を渡します。 server1.cluster.com:~/mongodb/keys
> db.getSiblingDB("$external").auth({ mechanism:"MONGODB-X509", user: "CN=rsroot,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU" })
レプリカを初期化します。 rs.initiate( { _id: "rs0", members: [ { _id: 0, host : "server1.cluster.com:27000" }, { _id: 1, host : "server2.cluster.com:27000" }, { _id: 2, host : "server3.cluster.com:27000", arbiterOnly: true }, ] } )
3番目のサーバーのarbiterOnlyパラメーターに注意してください。最初の段階で、「調停サーバー」を作成することに同意しました。mongodに再接続すると、シェルのプレフィックス「rs0」によって、同じ名前のレプリカに属していることがわかります。rs0：PRIMARY（現在のサーバーはSECONDARYを選択できます）。同様のパターンで、さらに2つのデータレプリカをリンクする必要があります。1.最初のサーバーで、設定なしでMongodesを実行します（ポートとデータディレクトリが変更されています）。 mongod --port 27001 --dbpath /root/mongodb/data/rs1
2.実行中のmongodに接続し、レプリカスーパーユーザー（rs1）を追加します。すべてのレプリカに同じ証明書を使用するため、サブジェクトは最初のレプリカと同じように使用されます。 mongo --port 27001
> db.getSiblingDB("$external").runCommand({createUser: "CN=rsroot,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU", roles: [{role: "root", db: "admin"}] })
3.構成ファイルを指定して、最初のサーバーでmongodを再起動します。2番目と3番目のサーバーでは、対応する構成を使用してMongodも上げます。 root@server1.cluster.com
4.証明書を使用してMongodに接続し、認証を渡し、rs1レプリカを初期化します。 root@server1.cluster.com
> db.getSiblingDB("$external").auth({ mechanism:"MONGODB-X509", user: "CN=rsroot,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU" }) > rs.initiate( { _id: "rs1", members: [ { _id: 0, host : "server1.cluster.com:27001" }, { _id: 1, host : "server2.cluster.com:27001" }, { _id: 2, host : "server3.cluster.com:27001", arbiterOnly: true }, ] } )
3番目のレプリカ（rs2）に対して手順を繰り返します。1.最初のサーバーで設定なしでMongodesを実行します（ポートとデータディレクトリの変更を忘れないでください）。 mongod --port 27002 --dbpath /root/mongodb/data/rs2
2. Mongodに接続し、レプリカスーパーユーザー（rs2）を追加します。 mongo --port 27002
> db.getSiblingDB("$external").runCommand({createUser: "CN=rsroot,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU", roles: [{role: "root", db: "admin"}] })
3.構成ファイルを使用して、最初のサーバーでMongodを再起動します。2番目と3番目のサーバーで、対応する構成を使用してMongodも上げます。 root@server1.cluster.com
4.証明書を使用してMongodに接続し、認証を渡し、rs2レプリカを初期化します。 root@server1.cluster.com
> db.getSiblingDB("$external").auth({ mechanism:"MONGODB-X509", user: "CN=rsroot,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU" }) > rs.initiate( { _id: "rs2", members: [ { _id: 0, host : "server1.cluster.com:27002" }, { _id: 1, host : "server2.cluster.com:27002" }, { _id: 2, host : "server3.cluster.com:27002", arbiterOnly: true }, ] } )
構成サーバー
構成サーバーの構成レプリカセットを強調表示することにしました。これには、いくつかの追加手順が必要な機能がいくつかあるためです。まず、レプリカを構成に追加するすべてのユーザーがMongosを使用してクラスターレベルで利用できるようになるため、個別の証明書に関連付けられた個別のユーザーを作成します。第二に、mongaでは、構成レプリカの一部としてアービトレーターを作成できません。これを行おうとすると、エラーメッセージが表示されます。 { "ok" : 0, "errmsg" : "Arbiters are not allowed in replica set configurations being used for config servers", "code" : 93 }
このため、構成レプリカには2つのSECONDARYインスタンス/ mongodsがあります。rscfgレプリカのスーパーユーザー用に別の証明書を作成してみましょう。これは、先ほど述べたように、クラスターレベルのルートにもなります。 server1.cluster.com:~/mongodb/keys
server1.cluster.com:~/mongodb/keys
server1.cluster.com:~/mongodb/keys
server1.cluster.com:~/mongodb/keys
1.最初のサーバーで設定なしでmongodを起動します。 server1.cluster.com:~/mongodb/keys
2. Mongodに接続し、レプリカスーパーユーザー（rscfg）を追加します。 server1.cluster.com:~/mongodb/keys
> db.getSiblingDB("$external").runCommand({createUser: "CN=root,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU", roles: [{role: "root", db: "admin"}] })
3.設定ファイルを使用して、最初のサーバーでmongodを再起動します。2番目と3番目のサーバーで、対応する構成ファイルを使用してMongodも上げます。 root@server1.cluster.com
4.証明書を使用してMongodに接続し、認証を行い、構成レプリカ（rscfg）を初期化します。 root@server1.cluster.com
> db.getSiblingDB("$external").auth({ mechanism:"MONGODB-X509", user: "CN=root,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU" }) > rs.initiate( { _id: "rscfg", members: [ { _id: 0, host : "server1.cluster.com:27888" }, { _id: 1, host : "server2.cluster.com:27888" }, { _id: 2, host : "server3.cluster.com:27888" } ] } )
構成サーバーベースのレプリカセットの準備ができました。これで、mongosを起動してクラスターに接続できます。mongosの構成と開始
Mongosの目標は、クラスターデータへのアクセスポイントを提供することです（さらに、クライアントはmongosを介してのみクラスターデータにアクセスできます）。 MongoDBドキュメントの図では、アプリケーションサーバー上で実行されているMongosが描かれています。私が表すクラスター構造では、server1.cluster.comとserver2.cluster.comで直接実行されている2つのmongosインスタンスがあります。まず、mongodについては、起動時にMongosに転送する構成ファイルを作成します。mongos設定とmongodの主な違いは、Mongosにはデータディレクトリがなく、プロキシデータのみが保存されるためです。Mongosは、構成サーバーの構成コレクションからクラスターの構成と状態に関する必要な情報をすべて取得します。Mongosは、sharding.configDBパラメーターを使用して構成サーバーに接続する方法について学習します。構成サーバーはセットのレプリカに基づいているため、レプリカ形式で指定します：レプリカ自体の名前、スラッシュ、ポートを含むホストのリストをコンマで区切って指定します。MongoをデフォルトポートのMongi-27017で起動します。 # # /root/mongodb/cfg/mongos.conf # sharding: configDB: "rscfg/server1.cluster.com:27888,server2.cluster.com:27888,server3.cluster.com:27888" net: port: 27017 ssl: mode: requireSSL PEMKeyFile: /root/mongodb/keys/server1.pem clusterFile: /root/mongodb/keys/server1.pem CAFile: /root/mongodb/keys/mongodb-CA-cert.crt weakCertificateValidation: false allowInvalidCertificates: false security: clusterAuthMode: x509 systemLog: destination: file path: /root/mongodb/logs/mongos.log logAppend: true
構成ファイルを両方のサーバーにコピーし（対応するPEM証明書を指定）、コマンドで実行します。 mongos --config /root/mongodb/cfg/mongos.conf
アクションの正しさを確認します-mongosに接続し、構成レプリカに追加したルートユーザー証明書で認証します（レプリカレプリカのユーザーはクラスターユーザーであることを思い出してください）。 mongo admin --ssl --sslCAFile /root/mongodb/keys/mongodb-CA-cert.crt --sslPEMKeyFile /root/mongodb/keys/rootuser.pem --host server1.cluster.com --port 27017
「mongos>」という碑文によって、誰に接続しているかがわかります。 mongos> db.getSiblingDB("$external").auth({ mechanism:"MONGODB-X509", user: "CN=root,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU" })
（出力に肯定的な「1」が表示されることが予想されます）一般に、mongaはルートから接続すると「気に入らない」ため、セキュリティ上の理由でこれを行うべきではないことを通知します。したがって、実際のクラスターで作業する場合は、組み込みロールuserAdminAnyDatabaseが付与されたユーザー（当然、個別の証明書を持つユーザー）を追加することもお勧めします。この役割には、管理タスクを実行するために必要なほぼすべての権限があります。ここでは、別のユーザーの証明書を作成する例を挙げる価値があると思います。このユーザーは分析データベースにのみアクセスでき、ユーザーに代わってサービスのすべてのアプリケーションがクラスターに接続されます。そのため、証明機関のあるディレクトリに移動し、新しいユーザーのキーと証明書署名要求を作成します。これをanalyticsuserと呼びます。 server1.cluster.com:~/mongodb/keys
証明書に署名します。 server1.cluster.com:~/mongodb/keys
PEMファイルを作成します。 server1.cluster.com:~/mongodb/keys
どのサブジェクトが証明書を持っているか見てみましょう： server1.cluster.com:~/mongodb/keys
管理者権限を持つユーザーの代わりにクラスター（Mongos）に接続し、新しいユーザーを追加します。 mongos> db.getSiblingDB("$external").runCommand({createUser: "CN=analyticsuser,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU", roles: [{role: "readWrite", db: "analytics"}] })
ユーザーanalyticsuserには、1つの分析データベースに対してのみ読み取りおよび書き込み権限を付与したことに注意してください。これにより、外部アプリケーションから分析データベース自体およびクラスター全体の設定に対して発生する可能性のある（無謀または悪意のある）アクションからクラスターが保護されます。シャーディング
この場合のシャーディングは、指定されたインデックスで高負荷の統計コレクションを共有します。これは、すぐに追加する複数のシャード間のシャードキーです。コレクションに対してシャーディングがアクティブ化されると、そのドキュメントのセット全体がChunksと呼ばれるn個の部分に分割されます。シャーディングが有効になっているときにコレクションが分割されるチャンクの数、および新しいチャンクが形成される頻度は、コレクション内のデータ量と、チャンクのサイズに影響するチャンクサイズパラメーターに依存し、デフォルトでは64 Mbです。クラスターで別のチャンクサイズを指定する場合は、これらのコレクションでシャーディングをアクティブにする前にこれを行う必要があります。新しいチャンクサイズは、新しく形成されたチャンクにのみ適用されます。チャンクのサイズを変更するには、スーパーユーザー証明書でMongosに接続し、認証を渡します。一般に、認証は、そのメカニズム（authenticationMechanism引数）、証明書の認証を担当するデータベース（authenticationDatabase）、および証明書を所有するユーザー（u）に直接指定することにより、入力と組み合わせることができます。スーパーユーザー（root）の場合、「connect + authentication」コマンドは次の形式を取ります。 mongo --ssl --sslCAFile /root/mongodb1/keys/mongodb-CA-cert.crt --sslPEMKeyFile /root/mongodb1/keys/rootuser.pem --host server1.cluster.com --port 27017 --authenticationMechanism "MONGODB-X509" --authenticationDatabase "$external" -u “CN=root,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU”
ログインに成功したら、構成コレクションを選択し、目的のパラメーターを変更します。 mongos> use config mongos> db.settings.save({_id: "chunksize", value: NumberLong(32)}) WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })
チャンクサイズを32 Mbに設定しました。次のコマンドを使用して、この設定の現在の値を確認できます。 mongos> db.settings.find({'_id':"chunksize" }) { "_id" : "chunksize", "value" : NumberLong(32) }
シャードを管理するには（最初にシャードを追加する必要があります）、組み込みロールclusterAdminを持つユーザーとして接続する必要があります。クラスター管理者の証明書を作成します。 server1.cluster.com:~/mongodb/keys
server1.cluster.com:~/mongodb/keys
server1.cluster.com:~/mongodb/keys
server1.cluster.com:~/mongodb/keys
私たちにとって珍しいことは何もありません。クラスターメンバーに示されたOUとは異なるOUを指定することを忘れないでください。次に、Mongosに再度接続し、rootとして認証し、新しいユーザー（クラスター管理者）を追加します。 mongos> db.getSiblingDB("$external").runCommand({ createUser: "CN=clusteradmin,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU", roles: [{role: "clusterAdmin", db: "admin"}] })
クラスター管理者の下でmongosに再接続します（認証は接続コマンドに含まれています）： mongo --ssl --sslCAFile /root/mongodb1/keys/mongodb-CA-cert.crt --sslPEMKeyFile /root/mongodb1/keys/clusterAdmin.pem --host server1.cluster.com --port 27017 --authenticationMechanism "MONGODB-X509" --authenticationDatabase "$external" -u “CN=clusteradmin,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU”
アービターインスタンスを除く、セットのレプリカで指定されているシャードを追加します。 mongos> sh.addShard("rs0/server1.cluster.com:27000,server2.cluster.com:27000") mongos> sh.addShard("rs1/server1.cluster.com:27001,server2.cluster.com:27001") mongos> sh.addShard("rs2/server1.cluster.com:27002,server2.cluster.com:27002")
シャードの追加ですべてがうまくいった場合、シャーディングコマンドで現在のステータスを確認できます。 mongos> sh.status() --- Sharding Status --- sharding version: { "_id" : 1, "minCompatibleVersion" : 5, "currentVersion" : 6, "clusterId" : ObjectId("5795284cd589624d4e36b7d4") } shards: { "_id" : "rs0", "host" : "rs0/server1.cluster.com:27100,server2.cluster.com:27200" } { "_id" : "rs1", "host" : "rs1/server1.cluster.com:27101,server2.cluster.com:27201" } { "_id" : "rs2", "host" : "rs2/server1.cluster.com:27102,server2.cluster.com:27202" } active mongoses: "3.2.8" : 1 balancer: Currently enabled: yes Currently running: no Failed balancer rounds in last 5 attempts: 0 Migration Results for the last 24 hours: No recent migrations databases:
シャードが表示され、バランサーのステータスが表示されます。バランサーはオンになっていますが、利用可能なシャード間で分配されるチャンクの移行のためのデータがまだないため、現在アイドル状態です。これは、空の「データベース」リストが示すものです。したがって、シャードクラスターを構築しましたが、デフォルトでは、すべてのデータベースのすべてのシャードでシャーディングが無効になっています。次の2つの段階に含まれています。手順1.目的のベースのシャーディングをオンにします。私たちの場合、これらは分析です：
mongos> sh.enableSharding("statistics")
結果を確認します。
mongos> sh.status() --- Sharding Status --- sharding version: { "_id" : 1, "minCompatibleVersion" : 5, "currentVersion" : 6, "clusterId" : ObjectId("5795284cd589624d4e36b7d4") } shards: { "_id" : "rs0", "host" : "rs0/server1.cluster.com:27000,server2.cluster.com:27000" } { "_id" : "rs1", "host" : "rs1/server1.cluster.com:27001,server2.cluster.com:27001" } { "_id" : "rs2", "host" : "rs2/server1.cluster.com:27002,server2.cluster.com:27002" } active mongoses: "3.2.8" : 1 balancer: Currently enabled: yes Currently running: no Failed balancer rounds in last 5 attempts: 0 Migration Results for the last 24 hours: No recent migrations databases: { "_id" : "analytics", "primary" : "rs2", "partitioned" : true }
分析データベースがデータベースのリストに表示されるはずです。また、「rs2」シャードがプライマリシャードとしてこのデータベースに割り当てられていることもわかります（PRIMARY Setレプリカと混同しないでください）。つまり、シャーディングが無効になっているすべてのコレクションドキュメントは、このプライマリシャード（rs2）に完全に保存されます。ステップ2.コレクションのシャーディングをオンにします。
前述のように、シャード可能なコレクションのドキュメントのコレクション全体をチャンクに分割するには、モングにキーインデックス（シャーディングキー）が必要です。彼の選択は非常に責任のあるタスクであり、実装の要件と常識に基づいて賢明にアプローチする必要があります。コレクションがチャンクに分割されるインデックスは、既存のインデックスから選択されるか、コレクションに意図的に追加されます。何らかの方法で、シャーディングが有効になっている時点で、キーに対応するインデックスがコレクションに存在する必要があります。シャーディングキーは、対応するインデックスに特別な制限を課しません。必要に応じて、例えば{“ s”：1、“ ts”：-1}のように複合することができます。必要なインデックスを決定したら、それを作成し、それを分析データベースの統計コレクションのシャーディングキーとして指定します。前述したように、統計コレクションの最も代表的なフィールドは、センサーの識別子-フィールドsです。コレクション内に対応するインデックスをまだ作成していない場合は、作成します。 mongos> use analytics mongos> db.statistics.ensureIndex({"s":1})
キーシャーディングインデックスを使用してコレクションシャーディングをオンにします。 mongos> sh.shardCollection("analytics.statistics", {"s":1})
これからは、クラスター内のシャーディングデータについて実際に話すことができます。コレクションのシャーディングを有効にした後、コレクションはチャンクに分割されます（量はデータのサイズとチャンク自体のサイズに依存します）。最初はプライマリシャードにあり、その後、バランシング（移行）プロセス中に他のシャードに分割されます。私の意見では、バランスをとるプロセスは非常にゆったりしています。私たちのケースでは、3Mレコードのコレクションが1週間以上にわたって3つのシャード間で配布されました。しばらくしてから、sh.status（）コマンドを再度実行して、変更点を確認しましょう。 mongos> sh.status() --- Sharding Status --- sharding version: { "_id" : 1, "minCompatibleVersion" : 5, "currentVersion" : 6, "clusterId" : ObjectId("5773899ee3456024f8ef4895") } shards: { "_id" : "rs0", "host" : "rs0/server1.cluster.com:27000,server2.cluster.com:27000" } { "_id" : "rs1", "host" : "rs1/server1.cluster.com:27001,server2.cluster.com:27001" } { "_id" : "rs2", "host" : "rs2/server1.cluster.com:27002,server2.cluster.com:27002" } active mongoses: "3.2.8" : 1 balancer: Currently enabled: yes Currently running: yes Balancer lock taken at Sun Jul 29 2016 10:18:32 GMT+0000 (UTC) by MongoDB:27017:1468508127:-1574651753:Balancer Collections with active migrations: statistic.statistic started at Sun Jul 29 2016 10:18:32 GMT+0000 (UTC) Failed balancer rounds in last 5 attempts: 0 Migration Results for the last 24 hours: 3 : Success 2 : Failed with error 'aborted', from rs2 to rs0 databases: { "_id" : "analytics", "primary" : "rs2", "partitioned" : true } analytics.statistics shard key: { "s" : 1 } unique: false balancing: true chunks: rs0 1 rs1 2 rs2 21 too many chunks to print, use verbose if you want to force print
以前にシャーディングを有効にした分析データベースに、現在のシャードキーが表示される統計コレクションが表示されました。また、出力では、シャードごとのチャンクの分布を見つけることができます。コレクションに少数のチャンクがある場合は、チャンクの簡単な概要も表示されます。また、バランサーのセクションでは、チャンクの正常な移行に関する情報、または前日のエラーに関する情報を確認できます。監督者
標準のMongoDBコミュニティパッケージをインストールすると、システムにmongodbサービスが表示され、サーバーの「ボックス化」バージョンを表します。このサービスは、MongoDBのインストール後にデフォルトで開始されます。サービスを開始すると、パス/etc/init.d/mongodに沿って配置された悪魔化スクリプトが提供されます。お気づきかもしれませんが、同じマシン上で複数のmongodインスタンスを実行し、server1.cluster.comおよびserver2.cluster.comデータサーバーに対して1つのmongosを実行する必要があります。一見、例として/etc/init.d/mongodスクリプトを使用した既製のソリューションがありますが、スーパーバイザーユーティリティを使用するオプションは私にとってより便利で透過的に見えました。スーパーバイザーは、mongo {d / s}のすべてのコマンドを同時に開始および停止する機能の形で、小さなプラスも提供します。 supervisorctl start all supervisorctl stop all
（ただし、このマシンのように、スーパーバイザーによって起動された他のアプリケーションがマシンにない場合）。スーパーバイザパッケージは、標準リポジトリからLinuxファミリのほとんどのオペレーティングシステムにインストールされます。私の場合（Debian 8）では、コマンドが関連します：
スーパーバイザを設定するには、起動した各アプリケーションの設定を個別の設定ファイルに作成するか、すべての設定を1つにまとめる必要があります。次に、rs0レプリカのmongod設定の例を示します。 # # /etc/supervisor/conf.d/mongod-rs0.conf # [program:mongod-rs0] command=mongod --config /root/mongodb/cfg/rs0.conf user=root stdout_logfile=/root/mongodb/logs/supervisor/mongod-rs0-stdout.log redirect_stderr=true autostart=true autorestart=true stopwaitsecs=60
角かっこで、開始または停止に使用するアプリケーションの識別子を定義します。コマンドパラメータは、実際にスーパーバイザが実行する必要があるコマンドを設定します。mongodは設定ファイルを受信します。次に、プロセスを起動するユーザーを指定します。パラメーターstdout_logfile-スーパーバイザーが書き込む出力ファイルへのパスを設定します。これは、何かがうまくいかず、スーパーバイザーがアプリケーションを開始しない理由を理解する必要がある場合に役立ちます。redirect_stderrは、上で指定したのと同じログファイルにエラーストリームをリダイレクトするようスーパーバイザーに指示します。次に、オプションautostartおよびautorestartを必ず含めてください不正なサーバーの再起動とプロセス自体のクラッシュの場合。また、アプリケーションが停止したときに指定された秒数だけスーパーバイザーが待機するstopwaitsecsパラメーターを変更すると便利です。デフォルトでは、アプリケーションが停止すると、スーパーバイザーはTERMシグナルを送信し、10秒間待機します。有効期限が過ぎてもアプリケーションが完了していない場合、アプリケーションはすでにKILLシグナルを送信していますが、これはアプリケーションによって無視できず、理論的にはデータ損失につながる可能性があります。したがって、アプリケーションの完了を待機するデフォルトの間隔を増やすことをお勧めします。生成された構成ファイルは、適切なスーパーバイザーディレクトリに配置する必要があります。LinuxOSのルールとしては、/etc/supervisor/conf.d/です。すべての準備ができたら、次のコマンドを使用してスーパーバイザー構成を更新する必要があります。
構成済みアプリケーションの状態の停止、開始、およびチェックは、次のコマンドによって実行されます。
スーパーバイザーの使用に切り替えた後は、mongosを実行するポート27017（サーバーの再起動後など）を使用する可能性のある標準mongodbサービスが開始されないようにすることが重要です。これを行うには、/ etc / init.d / mongodスクリプトを削除するだけです。お役立ち情報
大規模なコレクションのシャーディングを有効にする
移行時にデータベースの最もロードされたコレクションは合計で3Mレコードを超え、テスト中に、そのようなコレクション（sh.shardCollection（）コマンド）にシャーディングを含めることは問題なく実行されました。ただし、テストは1億件の同様のレコードを含む人為的に生成されたデータベースでも実行されました。そのようなボリュームでは、sh.shardCollection（）コマンドはしばらくすると「タイムアウト」エラーで終了します。この状況から抜け出す方法は、次の手順です。ステップ1.データベース全体をクラスターにインポートします。ステップ2.実動サーバー上または既にクラスター上で、別個の「大規模」コレクションのダンプを作成します。次に例を示します。 mongoexport --db analytics --collection statistics --out statistics.json
ステップ3.クラスター上の「大規模」コレクションを削除します。 > use analytics > db.statistics.drop()
ステップ4.空の「大」コレクションを作成し、それにインデックスを追加します。これにより、シャードが行われます。 > db.analytics.ensureIndex({"s":1})
ステップ5.シャーディングキーを使用してコレクションのシャーディングをオンにします。 > sh.shardCollection("analytics.statistics", {"s":1})
ステップ6.そして、コレクションデータをインポートします。 mongoimport --db analytics --collection statistics --file statistics.json
この手法はうまくいきましたが、json形式の大規模なコレクションのエクスポート/インポートは高速なプロセスではないことに注意してください。データベースのバックアップ
シャードクラスターのすべてのコンポーネントのバックアップコピーの作成は非常に複雑な手順であり、バランサーをオフ状態にして（移行中に強制的に停止することはできません）、後続のバックアップのために各シャードのSECONDARYノードをブロックする必要があります。完全なバックアップの実行の詳細については、公式ドキュメントをご覧ください。私たちは、必要なデータベースの通常のデータダンプを定期的に作成することで、バックアップの問題を解決しました。ここで、この手順の実装について説明します。MongoDBコミュニティパッケージの一部であるmongodumpユーティリティを使用して、分析データベースをバックアップします。MongoDBには、データバックアップを実行するための最小限の権限セットを持つ特別な組み込みバックアップロールがあります。この手順を実行するには、個々のユーザーを作成し、従来、最初にx.509証明書を生成します。証明書を生成するための手順全体を説明するのではなく、記事に繰り返し示されています。次の主題を取得する必要があるとのみ言います。 CN=backuper,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU
次に、クラスターに接続し、組み込みのバックアップロールを持つバックアップユーザーを作成します。 mongos> db.getSiblingDB("$external").runCommand({ createUser: "CN=backuper,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU", roles: [{role: "backup", db: "admin"}] })
ユーザーを作成したら、分析データベースのバックアップを試行できます。mongodumpユーティリティのコマンド引数は、認証を使用した接続に似ています。データベース名（--db）のみが追加で示され、ダンプ（-o）が保存されるディレクトリ、およびすべてのダンプファイルを圧縮することを示す--gzip引数が追加されます。 mongodump --ssl --sslCAFile “/root/mongodb/keys/mongodb-CA-cert.crt” --sslPEMKeyFile “/root/mongodb/keys/backuper.pem” -u "CN=backuper,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU" --host server1.cluster.com --port 27017 --authenticationMechanism "MONGODB-X509" --authenticationDatabase "$external" --db analytics --gzip -o "/path/to/backup/"
コードのビット...
記事の最後で、作成したクラスターへの接続を示すプログラムコードの例を共有します。クラスターで動作するサービスはC ++およびPythonで記述された多くの部分で構成されているため、例はこれらの素晴らしいプログラミング言語で作成されます。それでは、C ++の例から始めましょう。以下の接続例は、公式のMongoDBドライバーmongodb-cxx-driver-legacy-1.1.1に関連しています。 #include <mongo/client/dbclient.h> #include <mongo/client/options.h> ... mongo::DBClientConnection client(true); // try { // SSL mongo::client::Options options; options.setSSLMode(mongo::client::Options::SSLModes::kSSLRequired); options.setSSLCAFile("/path_to_certs/mongodb-CA-cert.crt"); options.setSSLPEMKeyFile("/path_to_certs/analyticsuser.PEM"); mongo::Status status = mongo::client::initialize(options); mongo::massertStatusOK(status); // , client.connect("www.server1.cluster.com:27017"); // mongos // : , , mongo::BSONObjBuilder auth_params; auth_params.append("db", "$external"); auth_params.append("user", "CN=username,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU"); auth_params.append("mechanism", "MONGODB-X509"); client.auth(auth_params.obj()); // } catch (const mongo::DBException &e) { std::cout << "DBException : " << e.toString() << std::endl; } ...
データベースホストに接続する前に、mongo :: client :: Options構造を使用して、SSL要求レベル（kSSLRequired）、パブリックCA証明書（mongodb-CA-cert.crt）、および添付PEMファイルを指定してクライアントを初期化する必要がありますクラスターユーザー（この場合、これは前に作成したanalyticsuserです）。次に、データベースに接続し、すべてが成功すれば認証に成功します。認証が通過するデータベースの名前に注意してください-「$ external」、ユーザー証明書からサブジェクトを渡す名前として、認証メカニズムを指定することを忘れないでください。また、パスワードを送信しないこともわかります。私たちの認証は外部です-証明書認証を通じて。Pythonで作成されたプロジェクトのWeb部分には、純粋なpymongoドライバーが含まれ、オブジェクトモデルはmongoengineフレームワークを使用して形成されます。始めるには、pymongoの例： import ssl db_hosts="server1.cluster.com:27017,server2.cluster.com:27017" db_port=None client = MongoClient(db_hosts, db_port, read_preference=ReadPreference.NEAREST, ssl=True, ssl_certfile="/path_to_certs/analyticsuser.PEM", ssl_cert_reqs=ssl.CERT_REQUIRED, ssl_ca_certs="/path_to_certs/mongodb-CA-cert.crt") db = client[db_name] db.authenticate(name=db_user, source="$external", mechanism="MONGODB-X509")
特別なことはありません-パブリックCA証明書とクライアントPEMファイルも転送します。ここでdb_hosts変数に注意する必要があります-これは実際には、Mongosが使用可能なアドレスとポートがコンマで区切られた接続文字列です。ポートパラメーター（db_port）、この場合は指定できません。わかりやすくするために指定しました。最初のアドレスが利用できない場合、この方法で接続されたpymongoドライバーは、自動的に2番目のアドレスへの再接続を試みます。練習では、最初の接続で両方のサーバーが使用可能な場合、アドレスが順番に選択されることを示しています。最初はserver1.cluster.com:27017への接続です。ただし、このpymogoの動作をテストすると、pytmogo.errors.AutoReconnect例外の生成が自動再接続の前にあることがわかりました。この状況を処理するために、たとえば統計ページを表示する機能やデータを読み取るAPIリクエストをラップできる小さなデコレーターが作成されました：functools import wrapsfrom pymongo.errors import AutoReconnectimport time def pymongo_reconnect(attempts=5): def decorator(f): @wraps(f) def decorated_function(*args, **kwargs): tries_reconnect = attempts if tries_reconnect <= 0: tries_reconnect = 1 while tries_reconnect: try: return f(*args, **kwargs) except AutoReconnect as ar: tries_reconnect -= 1 print("Caught AutoReconnect exception.") if tries_reconnect <= 0: raise ar time.sleep(0.1) print("Attempt to reconnect (%d more)...\n" % tries_reconnect) continue return decorated_function return decorator
デコレータは、関数の実行を何度も試行し（この場合は5回）、すべての試行を費やして例外が終了します。また、接続例のread_preferenceパラメーターについてもいくつか説明してください。 read_preferenceは、この接続で使用するデータ読み取りルールをドライバーに指示します（書き込みは常にPRIMARY（論理的）で行われます）。次の値を使用できます。PRIMARY-常にシャードレプリカのプライマリメンバーからデータを読み取ります。 PRIMARY_PREFERRED-シャードレプリカのプライマリメンバーから読み取りますが、セカンダリレプリカから読み取ることができない場合。SECONDARY-シャードのセカンダリメンバーからのみ読み取り。SECONDARY_PREFERRED-セカンダリシャードから可能な限り読み取りますが、プライマリシャードから不可能な場合（ドキュメントpymongoに述べたように）任意の利用可能から読み出し、及び-最寄りのドキュメントだけでなく、レプリカの最初の使用可能なメンバーが、最小ネットワーク遅延を有するものに使用されるMongiを詳細に描い自体、 -単にピング、第一級または第二のデータを提供かかわらず。したがって、このパラメーターは、一方で、読み取り要求の負荷からPRIMARYインスタンスをオフロードする機会を提供しますが、他方では、無関係で一貫性のないデータにつながる可能性があります。 SECONDARYインスタンスには、PRIMARYとの同期に何らかの理由で遅延があります（レプリカの構成とラグに依存します）。したがって、システムの前提と制限に基づいて、注意してこのオプションを選択してください。PRIMARYまたはSECONDARYの設定を満たすことができない場合、pymongoはOperationFailure例外をスローするため、これらのオプションを使用する際にはこの動作を考慮する必要があることに注意してください。mongoengineパッケージでは、すべてがより悲しくなりました。プロジェクトで最初に目にしたのは、mongoengineパッケージを介したデータベースへの接続ポイントです。 connect('default', host, port)
OK、私は考えました：「残りの接続パラメーターをpymongoと同じようにmongoengine.connectに転送し、これが決定されます。」しかし、mongoengine.connectで必要なパラメーターが見つからなかったため、私の願望は無駄になりました。これは、より広い引数リストmongoengine.register_connectionを持つ関数の単なる一般的なラッパーです。この機能のパラメーターの中には、MONGODB-X509許可メカニズムを接続に転送するために必要なものもありませんでした。フレームワークが必要なものを「理解」することを期待して、私はいくつかの無駄な試みをしましたが、ソースコードを掘り下げて、サポートが不足しており、pymongoがそれを理解しているmogoengineに必要なメカニズムを「転送」できないことを確信しました（実際に基づいています） mongoengine）。この欠点のためにgithubで同様のチケットがすでに持ち出されており、それが最後まで持ち込まれていなかったため、私は自分でフォークを作成し、必要なものをすべて追加することにしました。したがって、x.509認証による接続は次の形式を取りました。 import ssl from mongoengine import DEFAULT_CONNECTION_NAME, register_connection db_hosts="server1.cluster.com:27017,server2.cluster.com:27017" db_port=None ssl_config = { 'ssl': True, 'ssl_certfile': "/path_to_certs/analyticsuser.PEM", 'ssl_cert_reqs': ssl.CERT_REQUIRED, 'ssl_ca_certs': "/path_to_certs/mongodb-CA-cert.crt", } register_connection(alias=DEFAULT_CONNECTION_NAME, name="statistic", host=db_hosts, port=db_port, username="CN=username,OU=StatisticsClient,O=SomeSystems,L=Moscow,ST=MoscowRegion,C=RU", password=None, read_preference=ReadPreference.NEAREST, authentication_source="$external", authentication_mechanism="MONGODB-X509", **ssl_config)
残念ながら、これまでのところ、メインのMongoEngineリポジトリとマージすることはできませんでした。すべてのpython / pymongoの組み合わせでテストが失敗します。多くの開発者の最新のプールリクエストで、同じテストで同様の問題に気づいたので、フレームワークの「安定した」ブランチで考えられる誤動作の考えが忍び込んでいます。近い将来、状況が改善され、問題を把握できるようになり、x.509認証のサポートがメインのMongoEngineリポジトリに表示されることを願っています。認証メカニズムオプションの更新サポートがmongoengineの公式バージョンに追加されました。