1. 程式人生 > >對機房伺服器的整理記錄和總結

對機房伺服器的整理記錄和總結

雙11過後,當前需要對本公司的所有伺服器進行清點整理,便跟著運維一起學習了很多關於這方面的東西,同時自己也做了一些記錄。

我們當前的機房的整體架構圖:



 

所有裝置,硬體防火牆,核心交換機,接入交換機以及vpn交換機,都採用2個裝置,不會存在單點問題,後續會通過zabbix對所有裝置進行硬體級故障監控; 所有刀鋒伺服器通過接入交換機和核心交換機組成內網,使用192.168.1.*網段,內網之間不走硬體防火牆; 如果使用vpn登入,則請求通過“硬體防火牆-核心交換機-接入交換機-vpn交換機”,並虛擬出一個172 IP網段來處理;

虛擬化裝置均安裝ESXi,使用vcenter來對其進行部署: 



 

當前的網路拓撲結構:



 

需要購買外網IP以及域名,並通過DNSPod服務進行配置,從設定的頁面來看,其實DNSPod相當於一個外網BIND服務,解析域名至外網IP上。當然所有伺服器並不是都存在外網ip地址(外網ip地址有限),但是需要暴露給 DNSPod 以及 加速樂 服務的相關伺服器節點,需要提供外網IP。 DNS服務中每個網域名稱都有自己的一些檔案,稱為區域檔案,是由多條記錄組成,每條記錄稱為Resource Record,在設定DNS名稱解析、反向解析以及其他管理目的時,需要使用不同的資源記錄,型別主要有: SOA:Start Of Authority,放在zone file一開始的地方,每個檔案只能有一個SOA,一定是檔案中的第一條記錄,描述該zone負責的name server,例如:
$TTL 3H
@       IN SOA  @ rname.invalid. (
                                2015092461      ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
 
  • NS:Named Server,用來指定另外一個DNS來進行解析;
  • A:Address,將DNS域名對應到IPV4的32位地址;
  • CNAME:Canonical NAME,可以為同一部主機設定多個別名,設定的多個別名都會連線到同一個伺服器,常被用於使用第三方服務,例如使用CDN加速器將圖片進行託管等操作;
  • MX:Mail eXcharger,設定區域中擔任郵件伺服器的主機,所有要送往那部伺服器的mail都要講過mai excharger轉送。
其中部署的BIND服務,就是用於內網域名 -> 內網IP使用的,只有修改了/etc/resolv.conf 的內網伺服器才能正常使用, /etc/resolv.conf 配置檔案是DNS客戶機配置檔案,用於設定DNS伺服器的IP地址及DNS域名,還包含了主機的域名搜尋順序,該檔案是由域名解析器(resolver,一個根據主機名解析IP地址的庫)使用的配置檔案,格式很簡單:
nameserver    //定義DNS伺服器的IP地址
domain       //定義本地域名
search        //定義域名的搜尋列表
sortlist        //對返回的域名進行排序
  其中最主要的是nameserver關鍵字,如果沒有指定nameserver就找不到DNS伺服器,nameserver表示解析域名時使用該地址指定的主機為域名伺服器,按照檔案中出現的順序來查詢的,且只有當第一個nameserver沒有反應時才會去查詢後續的nameserver,例如:
nameserver 192.168.1.xx
nameserver 192.168.1.xx
nameserver 208.67.220.xxx
nameserver 114.114.114.xxx
  DNS服務由BIND軟體提供,啟動後服務名為named,管理工具為rndc,debug工具為dig,主要配置檔案為/etc/named.conf。

虛擬機器資源規劃分配

針對每種不同的應用,也需要將其分配不同的資源,之前來說我們沒有一個確定的規劃,導致資源浪費非常嚴重,因此自己稍微總結了一下來作為參考(後續再測試調整):

針對測試環境,我們可以將環境獨立出來進行部署,例如zookeeper,metaq,redis,以便在資源有限的情況下,最大性地發揮其效能優勢。 對資源的劃分,可以拆分成表格:
應用型別 資源估算 說明
nginx 8,4,獨佔網路 worker_process進行請求分發的程序數取決於cpu核數,佔用網路頻寬,最好單臺實體機中存在一臺nginx?
tomcat 4,4 單JVM佔用記憶體2G
redis 4,8 redis單執行緒模型,及時啟用持久化也只會消耗2個核心,佔用記憶體
zookeeper 4,4,網路連線數,磁碟 對磁碟的依賴非常嚴重,對zk資料狀態的變更,都會以事務日誌的形式寫入磁碟,此外zk還會定時將記憶體資料庫中的所有資料和所有客戶端的會話資訊記錄進行快照
metaq 4,8,磁碟 Message寫入速度低容量大的硬碟,對磁碟要求高,資料暫時存在頁快取(需要用到記憶體)中,到達某個閾值時,flush到磁碟,減少磁碟IO次數
solr 8,8 對於搜尋來說,非常消耗CPU,solr JVM堆大小為4G
測試環境-nginx 4,4 單nginx可以隨意分發至對應的測試服務中
測試環境-tomcat 4,16 單臺測試環境往往部署多個tomcat,比較消耗記憶體
測試環境-redis 2,4 雙核估計就夠用了,單核用於服務,另外的負責系統排程+RDB檔案生成
測試環境-zookeeper 2,4
測試環境-solr 4,4 測試solr仍然需要提供一定的cpu核數以及記憶體
測試環境-metaq 2,4 測試zookeeper配置低一點也應該無所謂
灰度環境-tomcat 4,16 灰度環境也需要部署多個tomcat,消耗記憶體較多
windows壓測機 8,16 壓測機比較消耗效能,CPU核數一定要跟上
windows監控服務 4,8/16 監測JVM需要使用visualvm,並將所有服務
linux監控服務 4,8 將所有監控服務進行統一部署,例如zabbix,ganglia,redis-stat,node-zk等服務,必要時可以關閉一些監控服務

降低基礎服務配置可幫助我們能夠在效能測試中查找出瓶頸點,因此測試環境的基礎服務效能可以降低,必要時再將配置提升上去。