【51CTO專稿】由51CTO傳媒舉辦的為期兩天的2013云計算架構師峰會已于10月26日圓滿落幕，會議內容涵蓋了云計算落地的重要環節，包括有：基礎架構、開發應用、安全、存儲以及云計算生態圈等方面。來自迅達云成(SpeedyCloud)的***技術官董偉在會上做了主題為《云平臺上的NoSQL集群的自動化擴展》的演講。為小伙伴們演示了在云主機上創建并初始化NoSQL集群的方法；以及如何通過監控系統發現主機故障，并且自動調用云端API進行故障設備替換的過程，***還展示了如何通過命令行的方式銷毀主機的整個過程。

但是因為時間倉促，沒有給小伙伴們留出太多時間進行問題解答和難點的詳細介紹，所以董偉在會后將大家比較關注的一些問題整合起來，并分析了在搭建的過程中碰到的一些難點問題及解決方案，以下是他整理出來的關于這部分的內容：

大家好，很榮幸作為主講嘉賓，在會上做了分享。不過由于時間倉促，未和大家做充分交流，所以會后我想通過該文章來解答一些大家關注的問題，并且介紹一些我們在搭建的過程中碰到的一些難點及解決方案。

在這之前，我先給大家介紹一下我們在構建過程中使用到的這款NoSQL數據庫MongoDB集群的架構以及它的一些特性。

我們要構建的集群是MongoDB的復制集（Replica Set， 可以參考官方文檔）， 集群的結構類似于下圖這樣(在會上我們演示時用了1個主，4個副的結構，但原理都一樣)。

在這個集群中有一個主(Primary)節點，用來接收寫入操作，剩下的都是副(Secondary)節點，他們會從主節點通過同步Oplog過來，并應用到本地數據來實現數據的同步，而且集群中各個節點之間都有心跳(Heartbeat)探測，以確保集群之間的互通性。

當該集群中的主節點不可用后，剩下的節點會自動通過選舉的方式產生一個新的主節點，這個過程是MongoDB集群的特性，過程如下圖所示：

我當時為大家演示了三個場景：

***個，MongoDB集群的初始化過程。我們先調用了SpeedyCloud云端的API完成了云主機的創建及啟動單個MongoDB實例，當分別確認完畢數據庫狀態之后，通過執行一段初始化代碼完成了整個集群的初始化。

第二個，MongoDB集群故障設備替換。為了模擬集群中設備故障，我們手工關閉了一臺主機，然后通過監控系統的偵測，自動發現故障設備，并且調用云主機創建過程，然后調用添加成員過程實現了集群中故障設備的自動替換。

第三個，銷毀整個集群。當整個集群的生命周期結束后，通過調用SpeedyCloud云端API，傳入云主機的ID號來實現云主機的自動銷毀過程。

在整個過程中涉及到了四個方面的技術應用：SpeedyCloud云端API的調用、Puppet配置管理系統的使用、MongoDB集群的維護以及Zabbix監控系統的使用。

我們通過在云主機中內置Puppet  Agent的方式，讓它和Puppet Master進行交互，實現了密碼修改以及一些配置文件的管理等；通過Zabbix Agent來實現了設備到監控系統的自動注冊，及監控數據的上報功能；同時又通過Zabbix Server的Trigger實現了對故障主機的發現，以及發現故障后的處理腳本調用。這套系統的整體結構圖如下所示：

下面開始我們的答疑部分，就大家會上以及會后問到的一些問題進行解答。#p#

答疑部分

問題1：假如我們構建的是一個通過HA-proxy實現的Web負載均衡系統，那么當某臺設備宕機之后，自動調用云端API生成了新的主機后，由于IP發生了變化，所以需要重新更改HA-proxy的配置，并手工添加該設備，請問可以讓IP不變嗎？

答： 因為在SpeedyCloud的整個運行系統中，設備在未銷毀前，它的IP是始終跟隨著它的，不會發生變化，所以新生成的設備只能啟用新的IP。這時候可能就需要通過一段腳本將新加入的IP寫入到HA的配置文件haproxy.cfg中，并放置到Puppet對應的目錄，然后通過Puppet Agent將該文件下發到Ha-proxy設備上，并且調用它的重啟命令完成新設備的添加。

問題2：MongoDB集群中的設備宕機之后，那么它上面的數據怎么辦？

答：因為我們采用的是MongoDB的復制集(Replica Set)模式，這種方式的優點是，在一個集群中，同一份數據會被存到多個節點上，因為設備都是通過內網相連，所以主節點上的數據會以最快的速度全部同步到所有集群中的節點上，所以，集群中任何一臺設備宕機之后，其實都不會影響系統整體的數據完整性。

問題3：當調用API時，調用的安全性及賬戶安全性如何來進行保證，因為我看到您調用時并沒有輸入用戶名密碼這樣的參數？

答：我們通過這幾個手段來保證調用安全性：

***，在調用時，不需要提供用戶名及密碼，而是通過提供API-Key來實現的身份識別，這個API是一串經過加密的64位字符串，以此來保證賬戶密碼的安全；這個API-Key可以通過登錄到系統中進行查看，如下圖所示：

第二，在提交時我們需要驗證系統時間，并且要求將系統時間和API-Key做SHA1加密，以此來保證URL的時間唯一性和***性；

第三，客戶在調用API時，可以基于HTTPS的方式來進行調用，這樣可以進一步來保證調用的安全性。

問題4：通過調用API創建出來的這些設備，你們是怎么計算費用的？

答：我們對于通過API創建出來的云主機采用按小時后付費的策略。客戶需要預先往自己的賬戶里充入一些金額，然后每個小時會統計客戶在這一個小時中主機的使用情況，根據主機配置及使用情況作做相應的扣費操作，如果發現客戶的剩余金額不夠扣除，我們會提前一個小時發郵件來提醒客戶進行充值。

問題5：我知道使用Puppet進行配置文件下發時，是要對客戶端做認證的，可是我看到您在新加了一臺設備之后，就自動從Puppet上面獲取到了配置文件，是如何實現的？

答：Puppet Master支持一種叫做自動授權(autosign)的功能，它需要在Puppet Master的配置文件中（通常這個文件為/etc/puppet/puppet.conf）增加三行配置：

[master]
autosign = true   #指明要支持自動認證功能
autosign = /etc/puppet/autosign.conf  #指明自動認證的規則保存在哪里

同時需要在/etc/puppet/目錄下創建一個叫autosign.conf的文件，用來保存自動認證的規則，添加 * 表示所有，或者添加域名，舉例：

doc.speedycloud.cn
*.speedycloud.cn

問題6：我看你在調用API創建云主機時，傳入了一個bootscrip參數，這個是做什么用的？

答：這是一段可執行的命令，寫在這個參數里面的命令會被寫入到/etc/rc.local文件中。這個文件的作用是用來在開機啟動時執行一些命令。所以你可以將一些你想在系統啟動時運行的命令寫入到這個腳本文件中，這樣當系統啟動時就會執行這些腳本來完成你想要做的一些事情了。#p#

難點及解決方案

難點1：初始化一臺MongoDB主機時，由于要從國外的官網下載大量的安裝文件，所以導致安裝時間會很久，這樣會影響演示時的效果以及加長演示時間，怎么辦？

解決方案：其實先開始是通過Puppet來實現MongoDB的安裝的，但是發現每次都需要好久， 因為要下載很多安裝包，這樣就不能夠保證演示時的時間。所以后來就想了一個辦法，因為在SpeedyCloud的云平臺上，支持自定義模板功能，也就是說，可以以一臺安裝好的云主機作為系統鏡像，這樣新建一臺設備時，將該鏡像的名字作為參數傳進去， 就可以以此鏡像為模板來生成云主機了，我們將一臺已經安裝好了MongoDB的設備作為模板，這樣演示的時候就大大縮短了創建一個MongoDB節點的時間。

難點2：MongoDB集群在搭建時需要通過域名或者主機名進行互相訪問(可以參照這個文檔)， 演示的例子中我們采用了主機名的方式，也就是說通過在/etc/hosts文件中來指定主機名。但有一個問題：因為每臺的/etc/hosts文件中都會包含一行對自己的定義，類似這樣：127.0.01   i-gblrwptp ，而在其他的機器上對這臺主機的定義又可能變成了類似這樣：10.70.0.52    i-gblrwptp 也就是說同一個hostname在不同的主機上可能所映射的IP不一樣，所以不能用Puppet進行整體文件的替換，這個難題怎么解決？

解決方案：這個問題的解決方案主要還是通過Puppet進行的，當然也涉及到一些中間過程，主要有以下幾個步驟：

***步，在調用完創建設備的API之后，通過調用查看設備詳細信息的API接口，在Puppet Master上將新創建出來的設備的IP和主機名的對應關系寫入到一個hosts的文件中。內容及路徑如下所示：

第二步，通過Puppet將該配置文件下發到所有新創建的主機的該位置/etc/puppet/config/hosts。Puppet中的配置如下所示，我們可以看到，如果該文件更新了之后，會觸發一個稱為auto_register.py的腳本。

第三步，向所有新創建主機的/etc/puppet/config/目錄下， 下發一個腳本auto_register.py，從上圖中我們可以看出該腳本的Puppet定義。該腳本是用來將上一步下發的host文件，加入到系統的/etc/hosts文件中。該腳本的內容如下：

難點3：如何來配置Zabbix的Auto registration（自動注冊）功能，讓設備可以將自己的信息自動注冊到Zabbix Server里面去？

解決方案：實現這個功能，需要同時在Zabbix Server端和 Zabbix Client端進行設置，步驟如下：

***步，首先要在新建的主機中安裝好Zabbix Agent，這個可以在難點答疑1的里面創建虛擬機模板的時候就安裝好，只不過后來我們要通過PuppetServer下發Zabbix Agent的配置。

第二步，修改Zabbix Agent的配置文件/usr/local/etc/zabbix_agentd.conf，如下圖所示，關鍵點是配置ServerActive（Zabbix Server的IP）和 Hostname（本機主機名，該名字會顯示在Zabbix Server中）

第三步，配置Zabbix Server的自動注冊功能，通過如下圖所示的路徑進入Action定義區，然后點擊"Create action"進入配置界面，相應的配置如下所示，需要修改的地方會圈出，完成這幾個步驟之后，那么重啟Zabbix Agent之后，就會將客戶端注冊到監控系統里面了： 

難點4：Zabbix客戶端的配置文件中需要配置自己的主機名，而每臺設備的主機名是不一樣的，這個配置通過Puppet是怎么做到的？

解決方案：這里用到了puppet的facter功能，以及Puppet的內容定義模板功能。其實所謂的Facter，就是運行在客戶端里面的一個ruby命令，通過該命令可以獲得所有關于這臺主機的信息，然后當Puppet客戶端向服務端請求資源的時候，會將這些可以通過Facter命令取到的信息都告訴Puppet Server,因此Server端就可以使用這些信息來生成一些文件內容。下面的***張圖為在客戶端執行facter命令的效果。第二張圖為Puppet Server端對Zabbix agent的配置文件定義，可以看到要使用一個ruby文件。第三張圖為該ruby文件的內容，可以看到里面使用到了一個hostname的變量，這個就是通過facter取到的值。

難點5：當Zabbix Agent的配置文件被更新之后需要重啟才可以生效，如何讓客戶端在正確的時機來進行重啟？

解決方案：這部分我們先開始也遇到了難題，發現調用pkill zabbix之后，馬上啟動zabbix_agentd是起不來的，后來才知道，調用了pkill之后，會在ps -ef | grep zabbix里面看到很多僵尸進程，所以只能在這些僵尸進程被回收之后，才可以啟動，為此，我們用了一個簡單的辦法，就是在調用pkill zabbix之后，讓該命令等待15秒（sleep 15）來釋放資源，然后再啟動zabbix_agentd 就可以了，當然這個15秒是一個經驗值，大家在使用時可以根據實際情況來進行調整。在Puppet Server上關于這部分的配置如下：