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

標籤：

如果你已經完成了自己新的MongoDB應用程式的開發，並且現在正準備將它部署進產品中，那麼你和你的運營團隊需要討論一些關鍵的問題：

• 最佳部署實踐是什嗎？
• 為了確保應用程式滿足它所必須的服務層次我們需要監控哪些關鍵計量？
• 如何能夠確定添加分區的時機？
• 有哪些工具可以對資料庫進行備份和恢複？
• 怎樣才能安全地訪問所有新的即時大資料？

本文介紹了硬體選擇、擴充、HA和監控。在查看詳細資料之前，首先讓我們處理一個最常見的問題：

部署MongoDB和部署RDBMS有什麼不同？

你會發現MongoDB作為一個文檔資料庫，它和你已經熟悉的關係型資料庫分享了很多同樣的概念、操作、策略和過程。監控、索引、調整和備份等內容的流程和最佳實務可以應用到MongoDB。同時如果你想要開始自己的培訓，那麼可以從MongoDB大學中擷取到來自於開發人員和DBA的免費線上課程。

 

相關廠商內容

滴滴出行iOS用戶端架構演化之路！ 用戶端如何應對弱網路！ 函數式編程中的Swift與Swift中的函數式編程！ 你離成為一位合格的技術領導者還有多遠？ 國際範 最前沿 不容錯過的容器技術盛會  

相關贊助商

GMTC全球移動技術大會2016年6月24日-25日，北京，點擊瞭解詳情！

 

系統效能和容量規劃是兩個重要的主題，任何部署都需要處理這兩個問題，無論是RDBMS還是NoSQL資料庫都是如此。作為規劃的一部分我們應該對資料卷（volume）、系統負載、效能（輸送量及延遲時間）和容量利用建立基準。這些基準應該反映你對資料庫在產品環境中執行的工作負載的期望，它們應該隨著使用者數、應用程式功能、效能SLA或者其他因素的變化定期地調整。

基準將協助你理解系統哪些時候是按照設計啟動並執行，哪些時候可能會影響經驗品質或者其他決定性系統因素的問題開始浮現。

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

 清楚自己的工作集

在為部署MongoDB最佳化硬體預算的時候，RAM應該是或者接近於列表的第一位。

為了實現低延遲的資料庫操作MongoDB中廣泛使用了RAM。在MongoDB中，所有的資料都是通過記憶體對應檔讀取和操作的。從記憶體中讀取資料是使用納秒來度量的，而從磁碟中讀取資料則是使用毫秒度量的，所以從記憶體中讀取資料幾乎比從磁碟中讀取要快了十萬倍。

在正常操作期間最頻繁訪問的資料和索引的集合稱為工作集，在理想的情況下它們應該在RAM中。工作集可能是整個資料庫的一小部分，例如最近的事件所相關 App程式資料或者最常訪問的熱門產品。

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）提供了CloudMonitor和備份服務，協助使用者最佳化叢集、解決效能問題、減輕營運風險。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檔案）中擷取。

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