(轉)爲首次部署MongoDB作好準備：容量計劃和監控

若是你已經完成了本身新的MongoDB應用程序的開發，而且如今正準備將它部署進產品中，那麼你和你的運營團隊須要討論一些關鍵的問題：

• 最佳部署實踐是什麼？
• 爲了確保應用程序知足它所必須的服務層次咱們須要監控哪些關鍵指標？
• 如何可以肯定添加分片的時機？
• 有哪些工具能夠對數據庫進行備份和恢復？
• 怎樣才能安全地訪問全部新的實時大數據？

本文介紹了硬件選擇、擴展、HA和監控。在查看詳細信息以前，首先讓咱們處理一個最多見的問題：

部署MongoDB和部署RDBMS有什麼不一樣？

你會發現MongoDB做爲一個文檔數據庫，它和你已經熟悉的關係型數據庫分享了不少一樣的概念、操做、策略和過程。監控、索引、調整和備份等內容的流程和最佳實踐能夠應用到MongoDB。同時若是你想要開始本身的培訓，那麼能夠從MongoDB大學中獲取到來自於開發者和DBA的免費在線課程。

系統性能和容量規劃是兩個重要的主題，任何部署都須要處理這兩個問題，不管是RDBMS仍是NoSQL數據庫都是如此。做爲規劃的一部分咱們應該對數據卷（volume）、系統負載、性能（吞吐量及延遲時間）和容量利用創建基線。這些基線應該反映你對數據庫在產品環境中執行的工做負載的指望，它們應該隨着用戶數、應用程序功能、性能SLA或者其餘因素的變化按期地調整。

基線將幫助你理解系統哪些時候是按照設計運行的，哪些時候可能會影響用戶體驗質量或者其餘決定性系統因素的問題開始浮現。

下面將會討論關鍵的部署要素，包括硬件、擴展和HA，同時還會討論爲了維持最佳的系統性能你應該監控哪些內容。

清楚本身的工做集

在爲部署MongoDB優化硬件預算的時候，RAM應該是或者接近於列表的第一位。

爲了實現低延遲的數據庫操做MongoDB中普遍使用了RAM。在MongoDB中，全部的數據都是經過內存映射文件讀取和操做的。從內存中讀取數據是使用納秒來度量的，而從磁盤中讀取數據則是使用毫秒度量的，因此從內存中讀取數據幾乎比從磁盤中讀取要快了十萬倍。

在正常操做期間最頻繁訪問的數據和索引的集合稱爲工做集，在理想的狀況下它們應該在RAM中。工做集多是整個數據庫的一小部分，例如最近的事件所關聯的應用程序數據或者最常訪問的熱門產品。

MongoDB試圖訪問數據時發生的頁面錯誤並不會被加載到RAM中。若是有空閒內存，那麼操做系統將定位到磁盤上的頁面並將它們直接加載到內存中。可是若是沒有空閒內存，那麼操做系統必須將內存中的一個頁面寫入磁盤，而後將被請求的頁面讀取到內存中。這個流程比訪問已經存在於內存中的數據要慢。

有些操做可能會在不經意間從內存中清除大量的工做集，這樣會對性能產生嚴重影響。例如，對於一個瀏覽數據庫中全部文檔的查詢而言，若是數據庫比服務器上的RAM大，那麼將會致使文檔被讀入內存而工做集被寫出到磁盤。在項目的模式設計階段爲本身的查詢定義合適的索引將會極大地下降這種風險發生的可能性。MongoDB說明操做可以爲查詢計劃和索引的使用提供信息。

MongoDB服務狀態命令中包含了一個有用的輸出：工做集文檔，它提供了一個MongoDB實例工做集的估算大小。運營團隊能夠按照給定的時間跟蹤實例訪問的頁面數，包括工做集中最舊的文檔到最新的文檔之間的運行時間。經過跟蹤這些指標咱們可以發現何時工做集會接近如今的RAM限制從而積極地採起行動確保系統是可擴展的。

MongoDB管理服務和mongostat可以幫助用戶監控內存的使用狀況，下面咱們將會對此進行詳細地討論。

存儲和磁盤I/O

MongoDB不須要共享存儲（例如存儲區域網絡）。MongoDB可以使用本地附加的存儲和固態硬盤（SSD）。

MongoDB中的大部分磁盤訪問模式並無順序屬性，這樣作的結果即是客戶能夠經過使用SSD得到巨大的性能收益。咱們已經觀察到使用SATA SSD和PCI得到的良好結果和強大的性能。商業SATA旋轉驅動器能夠媲美成本更高的旋轉驅動器，這得益於MongoDB的非順序訪問模式：應該更有效地使用預算將其用於更多的RAM或者SSD上，而不是更多地用於昂貴的旋轉驅動器上。

在數據文件受益於SSD的同時，MongoDB的日記文件因爲其自身的高順序的寫屬性成爲了快速常規磁盤的一個很好的候選。

大多數MongoDB部署應該使用RAID-10。RAID-5和RAID-6沒有提供足夠的性能。RAID-0提供了很好的寫性能，可是讀性能有限，容錯能力也不足。部署的MongoDB能夠經過副本集（下面將會討論）提供很強的數據可用性，同時用戶應該考慮使用RAID和其餘因素知足想要的SLA可用性。

雖然咱們應該設計MongoDB系統讓它的工做集適合於內存，可是磁盤I/O依然是一個關鍵的性能考慮。MongoDB會按期地將寫操做刷新到磁盤並提交到日記，因此在寫負載較重的時候基礎的磁盤子系統可能會變得不堪重負。iostat命令能夠用於顯示高磁盤利用率和過多的寫隊列。

CPU選擇——速度仍是內核？

MongoDB的性能一般不會綁定到CPU上。由於MongoDB不多會遇須要利用大量內核的工做負載，比起時鐘速度較慢的多核服務器最好的選擇是有更快的時鐘速度。

不管是什麼系統，測量CPU的利用率都是很是重要的。若是觀察到CPU的利用率很高可是並無出現磁盤飽和或者頁面錯誤這樣的其餘問題，那麼系統中可能會存在不尋常的問題。例如，一個存在無限循環的MapReduce工做或者一個沒有創建良好索引就對工做集中的大量文檔進行排序和過濾的查詢均可能會致使CPU利用率的飆升，可是它們卻不會引起磁盤系統問題或者頁面錯誤。用於監控CPU利用率的工具將在下面介紹。

擴展數據庫——什麼時候擴展和如何擴展？

MongoDB經過一種稱爲Sharding的技術提供了水平擴展能力。Sharding可以在多個物理分區（稱爲片）之間分發數據。Sharding可讓MongoDB的部署解決單個服務器的硬件限制而不須要增長應用程序的複雜性，解決的硬件限制包括RAM和磁盤I/O的瓶頸。

MongoDB自動分片和應用程序的透明度

在系統資源變得有限以前實現分片是很是容易的，所以容量規劃和主動監控在須要成功地擴展應用程序時是很是重要的元素。

在下面的場景中用戶應該考慮部署一個分片的MongoDB集羣：

• RAM限制：系統活動工做集的大小很快就會超過系統RAM的最大容量。
• 磁盤 I/O限制：系統有大量的寫活動，可是操做系統寫數據的速度不夠快，沒法知足需求；同時/或者I/O帶寬限制了數據寫入磁盤的速度。
• 存儲限制： 數據集接近或者超過了系統中的單個節點的存儲容量。

Sharding的目標之一就是在多臺服務器之間一致地分發數據。若是服務器資源的利用率並非近似地相等，那麼可能會存在引起調度錯誤的潛在問題。例如，選擇一個糟糕的分片鍵可能會致使不平衡的數據分發。在這種狀況下，即使不是全部的可是大部分查詢也會被導向到正在管理數據的那個單獨的MongoDB。

另外，MongoDB可能會試圖從新分發文檔從而在服務器之間實現更加理想的平衡。雖然從新分發最終會實現一種更加使人滿意的文檔分發，可是有大量與從新平衡數據相關的工做，這些工做自己就有可能會產生影響致使沒法實現預期性能的SLA。

經過運行db.currentOp()命令，你將可以瞭解集羣如今正在執行哪些工做，包括跨分片的文檔再平衡。

爲了確保數據可以在集羣中的全部分片間均勻地分發，選擇一個優秀的分片鍵是很是重要的。MongoDB文檔中包含了一個關於如何選擇優秀分片鍵的教程。

MongoDB複製集的高可用性

MongoDB使用本地複製維護複製集之間的多個數據副本。複製集能夠經過發現錯誤（服務器、網絡、OS或者數據庫）和自動化故障修復避免停機時間。推薦的作法是：全部的MongoDB部署都應該配置複製。

（單擊放大圖片）

使用MongoDB複製集自恢復

對主節點數據庫的修改操做會經過名爲oplog的日誌被複制到其餘二級節點上。oplog包含了一個排序的冪等操做的集合，該集合中的操做會在二級節點上重放。oplog的大小是可配置的，默認是可用磁盤空間的5%。

正以下面的圖表所闡述的，能夠經過定位副本爲服務器、機架、數據中心故障和網絡分區提供容錯性。

（單擊放大圖片）

複製延遲是做爲正常運行的一部分來監控的。它表示的是將主節點上的一個寫操做複製到二級節點上所花費的時間。必定的延遲是正常的，可是若是複製延遲增加，則可能會引起問題。複製延遲產生的典型緣由包括網絡延遲、鏈接問題和磁盤延遲（例如二級節點的吞吐量劣於主節點）。

複製狀態和複製延遲能夠經過replSetGetStatus命令從新恢復。

日誌概述

做爲全部部署的一部分，應該監控應用程序和數據庫的日誌以便發現錯誤並查看其餘的系統信息。將應用程序和數據庫的日誌關聯起來是很是重要的，由於這樣才能決定應用程序中的活動最終是否須要對系統中的其餘問題負責。例如，用戶寫入峯值可能會增長寫入MongoDB的容量，這反過來可能會壓垮下面的存儲系統。若是沒有應用程序和數據庫日誌的關聯，那麼可能要花費更多的時間纔可以肯定寫入容量的增加是應用程序的問題而不是運行在MongoDB中的某些進程的問題。

MongoDB 監控工具

MongoDB包含了各類監控工具，讓你可以積極地管理系統的運行和性能。

MongoDB管理服務 (MMS)

MongoDB管理服務（MMS）提供了雲監控和備份服務，幫助用戶優化集羣、解決性能問題、減輕運維風險。MMS備份服務將在之後的文章中討論。

MMS監控支持圖表、自定義儀表盤和自定義警告。MMS僅須要最低限度的安裝和配置。用戶在全部的MongoDB實例上安裝一個本地代理，該代理會跟蹤與數據庫使用狀況相關的數百個關鍵的健康指標，包括：

• 操做數（Op Counters）—每秒鐘執行的操做的數量
• 內存（Memory）—MongoDB正在使用的數據量
• 鎖百分比（Lock Percent）—寫鎖消耗時間的百分比
• 後臺刷新（Background Flush）—將數據刷新到磁盤消耗的平均時間
• 鏈接（Connections）—MongoDB當前打開的鏈接的數量
• 隊列（Queues）—等待運行的操做的數量
• 頁面錯誤（Page Faults）—磁盤的頁面錯誤數
• 複製（Replication）—主節點操做日誌的長度以及複製延時
• 日誌（Journal）—寫入日誌的數據量

（單擊放大圖片）

這些指標會被安全地報告給MMS服務，告訴它它們是在哪裏處理、聚合、通知的，並在瀏覽器中可視化顯示。用戶可以容易地根據各類性能指標瞭解他們集羣的健康情況。

硬件監控

Munin node是一個開源軟件程序，它能夠監控硬件並報告磁盤和RAM的使用狀況這樣的指標。MMS可以收集Munin node產生的這些數據，並在MMS儀表盤中將這些數據和其餘數據一塊兒展示給用戶。由於每個應用程序和部署都是惟一的，因此用戶應該爲磁盤利用率的峯值、網絡活動的主要變化和平均查詢長度/響應時間的增加建立警報。

數據庫分析工具

MongoDB提供了一個性能分析工具，該工具可以記錄數據庫操做相關的細粒度信息。分析工具能夠記錄全部事件的信息，也可以只記錄那些持續時間超出了配置閾值的事件的信息。分析數據存儲在一個固定集合中，用戶可以很容易地從中搜索相關的事件——查詢這個集合可能比嘗試着去解析日誌文件更加容易。

其餘的監控工具

有各類各樣的監控工具讓你可以從其餘的方面深刻理解MongoDB系統。

• mongotop 是隨MongoDB提供的一個工具，它可以跟蹤並報告一個MongoDB集羣當前的讀、寫活動。
• mongostat 是隨MongoDB提供的另外一個工具，它爲全部的操做提供了一個全面概覽，包括更新、插入的計數，頁面錯誤、索引的丟失狀況以及不少其餘的關係到系統健康的重要指標。
• Iostat、vmstat、netstat和sar這樣的Linux工具也能爲深刻探索MongoDB系統提供有價值的信息。
• 對於Windows環境上的用戶而言，性能監控器（Performance Monitor，一個Microsoft管理控制檯單元）是一個很是有用的工具，能夠用來測量各類指標。

若是想要獲取更多與監控工具和監控內容相關的信息，能夠查看MongoDB文檔中的監控數據庫系統頁面。

配置MongoDB

用戶應該將配置選項存儲到MongoDB的配置文件中。sysadmins可以經過這種方式在整個集羣之間實現一致性的配置。配置文件支持MongoDB命令行所支持的全部選項。安裝和升級應該經過流行的工具（例如Chef和Puppet）自動完成，同時MongoDB社區還提供並維護了這些工具的示例腳本。

一個基礎的MongoDB配置文件相似於下面的內容：

• fork = true
• bind_ip = 127.0.0.1
• port = 27017
• quiet = true
• dbpath = /srv/mongodb
• logpath = /var/log/mongodb/mongod.log
• logappend = true
• journal = true

你可以經過文檔瞭解到與MongoDB配置選項相關的更多內容。在MongoDB文檔產品說明頁面上還維護着針對操做系統、文件系統、存儲設備和其餘系統相關主題特定配置的最新建議。

結論

在本文中咱們介紹了哪些用於部署關係型數據庫的概念、操做和流程能夠被直接地應用到MongoDB上，同時還介紹了硬件選擇和部署及監控的最佳實踐。另外，有關於全部這些主題的詳細討論能夠從MongoDB操做指南（一個.pdf文件）中獲取。

關於做者

Mat Keep (@matkeep) 是MongoDB產品營銷團隊的一員，負責爲MongoDB的產品和服務構建願景、定位和內容，同時也負責對市場趨勢和客戶需求進行分析。在就任於MongoDB以前，Mat是Oracle公司的產品管理總監，負責MySQL數據庫在Web、電信行業、雲和大數據方面的應用。在這以後他還在技術供應商和麪向最終用戶的公司中從事過一系列的工做，包括銷售、商業開發與分析、程序員。

查看英文原文：Preparing for Your First MongoDB Deployment: Capacity Planning and Monitoring

查看中文原文：爲首次部署MongoDB作好準備：容量計劃和監控