Docs Menu
Docs Home
/
MongoDBマニュアル
/
自己管理型配置
/
管理

自己管理型配置の操作チェックリスト

項目一覧

  • ファイル システム
  • 複製
  • シャーディング
  • ジャーナリング: WiredTiger ストレージ エンジン
  • ハードウェア
  • クラウド ハードウェアへの配置
  • オペレーティング システムの構成
  • バックアップ
  • モニタリング
  • ロード バランシング
  • セキュリティ

以下のチェックリストは、 開発チェックリストのリストとともに、本番環境の MongoDB 配置で問題を回避するための推奨事項を示すものです。

ファイル システム

複製

  • 非表示となっていないレプリカセット ノードすべてが、RAM、CPU、ディスク、ネットワーク設定などで同じようにプロビジョニングされていることを確認します。

  • ユースケースに合わせて oplog サイズを設定します。

    • レプリケーション oplog window は、完全な再同期の必要性を回避できるよう、通常のメンテナンスとダウンタイムのウィンドウをカバーする必要があります。

    • レプリケーション oplog windowは、最後のバックアップからレプリカセット ノードを復元するのに必要な時間をカバーする必要があります。

      注意

      レプリケーション oplog windowは、データのコピー中に oplog レコードがプルされるため、最初の同期によってレプリカセット ノードを復元するために必要な時間をカバーする必要はありません。ただし、復元されるノードは、データのコピー中にこれらの oplog レコードを一時的に保存するための十分なディスク領域をローカルデータベース内に保持していることが必要です。

  • レプリカセットに、ジャーナリングを実行している少なくとも3つのデータ保持投票ノードが含まれていることを確認し、w: majority 書込み保証 (write concern) を使用して、可用性と耐障害性を確保してください。

  • レプリカセット ノードを構成するときは、IP アドレスではなくホスト名を使用します。

  • すべての mongod インスタンス間の完全な双方向ネットワーク接続を確保します。

  • 各ホストが自己解決できることを確認します。

  • レプリカセットに奇数の投票ノードが含まれていることを確認します。

  • mongod インスタンスに 0 または 1 票があることを確認します。

  • 高可用性を実現するには、レプリカセットを少なくとも 3 つのデータセンターに展開します。

シャーディング

  • 大規模なクラスターで最適なパフォーマンスを得るには、コンフィギュレーションサーバーを専用のハードウェアに配置します。ハードウェアに、データファイル全体をメモリに保持するのに十分な RAM があり、専用のストレージがあることを確認します。

  • 実稼働構成ガイドラインに従って、mongos ルーターを展開します。

  • NTP を使用して、シャーディングされたクラスターのすべてのコンポーネントのクロックを同期します。

  • mongod 、 mongos 、およびコンフィギュレーションサーバー間の完全な双方向ネットワーク接続を確保します。

  • CNAME を使用してクラスターにコンフィギュレーションサーバーを識別させると、ダウンタイムなしでコンフィギュレーションサーバーの名前や番号を変更できます。

ジャーナリング: WiredTiger ストレージ エンジン

  • インスタンスがすべてジャーナリングを使用しているようにします。

  • 書き込み集中型のワークロードでは、ジャーナルを独自の低レイテンシ ディスクに配置します。データベースの状態を構成するファイルは別のボリュームに配置されるため、これはスナップショット形式のバックアップに影響することに注意してください。

ハードウェア

  • 最適なパフォーマンスを得るには、RAID10 と SSD ドライブを使用します。

  • SAN と仮想化:

    • 各mongodにdbPathの IOPS がプロビジョニングされていること、または独自の物理ドライブまたは LUN があることを確認します。

    • 仮想環境で実行する場合は、メモリ バルーニングなどの動的メモリ機能を使用するのを避けます。

    • SAN は単一障害点になる可能性があるため、すべてのレプリカセット ノードを同じ SAN に配置することは避けます。

クラウド ハードウェアへの配置

  • Windows Azure: TCP キープアライブ（ tcp_keepalive_time ）を 100 ～ 120 に調整します。Azure ロード バランサーの TCP アイドル タイムアウトは、MongoDB の接続プーリング動作には遅すぎます。詳細については、「 Azure 製品ノート」を参照してください。

  • Windows Azure などの高レイテンシ ストレージを備えたシステムでは、MongoDB バージョン 2.6.4 以降を使用します。これらのバージョンには、そうしたシステムのパフォーマンス向上が含まれています。

オペレーティング システムの構成

Linux

  • MongoDB 8.0 以降を実行している場合は、Transparent Hugepages をオンにします。

  • MongoDB 7.0 以前を実行している場合は、Transparent Hugepages をオフにします。

  • データベースファイルを保存しているデバイスの readahead 設定を調整します。

    • WiredTiger storage engine の場合、ストレージ メディアの種類（回転ディスク、SSD など）に関係なく、readahead を 8 から 32 の間で設定します。ただし、テストで readahead 値が高いほど測定可能で、再現性のある、信頼性の高いベネフィットが示されます。

      MongoDB の商用サポートでは、代替の readahead 構成に関するアドバイスとガイダンスが提供されます。

  • RHEL / CentOS で tuned を使用する場合は、tuned プロファイルをカスタマイズする必要があります。RHEL / CentOS に同梱されている tuned プロファイルの多くは、デフォルト設定ではパフォーマンスに悪影響を与える可能性があります。選択した tuned プロファイルを次のようにカスタマイズします。

  • SSD には cfq またはdeadline ディスク スケジューラーを使用します。

  • ゲスト VM 内の仮想化ドライブには cfq ディスク スケジューラーを使用します。

  • NUMA を無効にするか、vm.zone_reclaim_mode を 0 に設定して、ノード インターリーブで mongod インスタンスを実行します。詳細については、「MongoDB と NUMA ハードウェア」を参照してください。

  • の値は、ユースケースに合わせてハードウェアで調整しulimit 。 複数のmongodまたはmongosインスタンスが同じユーザーで実行されている場合は、それに応じてulimit値を調整します。 詳細については、「 自己管理型配置の UNIX ulimit設定」を参照してください。

  • dbPath マウント点には noatime を使用します。

  • 配置に必要な十分なファイルハンドル（fs.file-max）、カーネル pid 制限（kernel.pid_max）、プロセスあたりの最大スレッド数 (kernel.threads-max)、プロセスあたりのメモリマップ領域の最大数 （vm.max_map_count）を設定します。大規模なシステムの場合、次の値が適切な開始点となります。

    • fs.file-max 98000 の値、

    • kernel.pid_max 64000 の値、

    • kernel.threads-max 64000 の値、および

    • vm.max_map_count 131060 の値

  • システムにスワップ領域が設定されていることを確認します。適切なサイズ設定の詳細については、オペレーティング システムのドキュメントを参照してください。

  • システムのデフォルトの TCP キープアライブが正しく設定されていることを確認します。通常、値を 120 に設定すると、レプリカセットとシャーディングされたクラスターのパフォーマンスが向上します。詳細については、「よくある質問」の「TCP keepalive 時間が MongoDB の配置に及ぼす影響」を参照してください。

Windows

  • NTFS の「最終アクセス時刻」更新を無効にすることを検討します。 これは、Unix 系システムで atime を無効にするのと同様です。

  • デフォルトの Allocation unit sizeである4096バイトを使用して NTFS ディスクをフォーマットします。

バックアップ

  • バックアップと復元のプロセスの定期的なテストを予定して、時間の見積もりを入手し、その機能性を検証します。

モニタリング

  • MongoDB Cloud Manager または Ops Manager、MongoDB Enterprise Advanced で利用可能なオンプレミス ソリューション、または別のモニタリング システムを使用して、主要なデータベース メトリクスをモニタリングし、それらのアラートを設定します。以下のメトリクスのアラートを含めます。

    • レプリケーションラグ

    • レプリケーション oplog window

    • 主張

    • queues

    • ページ フォールト

  • サーバーのハードウェア統計をモニタリングします。特に、ディスク使用量、CPU、使用可能なディスク容量に注意します。

    ディスク容量のモニタリングがない場合、または予防措置として以下を行います。

    • ディスクがいっぱいになった場合に使用可能なスペースを確保するために、storage.dbPath ドライブにダミーの 4 GB ファイルを作成します。

    • 他のモニタリング　ツールが利用できない場合、cron+df の組み合わせにより、ディスク容量が最高水準点に達したときにアラートを出せます。

ロード バランシング

  • 既存の接続に十分なタイムアウトを設定して、「スティッキー セッション」または「クライアントのアフィニティ」を有効にするようにロード バランサーを設定します。

  • MongoDB クラスターまたはレプリカセット コンポーネント間にロード バランサーを配置するのを避けます。

セキュリティ

MongoDB インストールを保護するためのセキュリティ対策のリストについては、「MongoDB セキュリティ チェックリスト」を参照してください。

戻る

プロダクション ノート

次へ

パフォーマンス