這是以前規劃設計的IT基礎架構運維規劃方案,總結本身一段時間的運維經驗
相關敏感信息已經去除
學無止境啊php
從2016年10月XX的運維工做到如今已經有兩年多了,期間進行了不少調整,部署了不少業務系統,從一開始的混亂無序,到如今算是小有成效了。如今咱們須要進一步完善現有運維工做,規劃完整的架構,方便往後進行調整,保證可以科學而又高效的完成運維工做,提升客戶滿意度。前端
總體架自下而上分爲兩個部分,基礎環境和上層業務應用。
基礎環境主要是提供的基礎虛擬機化環境和存儲支持,同時包括各類網絡基礎環境。
上層應用由客戶業務、運維支撐和第三方業務系統構成,主要是基於虛擬機的應用軟件和解決方案。
廣電的基礎環境主要構建是基於kvm虛擬化解決方案的超融合nutanix環境和基於vmware的vsphere虛擬化解決方案環境組成,二者爲不一樣的異構的虛擬化,中間底層網絡所有連通,相互共享網絡資源和存儲資源,爲總體的架構提供一個虛擬化層從而支撐上層其餘業務系統。值得說明的是,目前咱們沒法兩種不一樣的虛擬化環境進行統一管理和調度,雖然他們均可以提供完整的虛擬機生命週期管理。java
Nutanix的虛擬化環境組網以下所示:
mysql
這是一個穩定的組網架構,從2017年3月部署後,基本沒有變動過,運行可靠,可用性高,性能強悍,主要的上層業務都是運行在其中,而且推薦這樣作,由於它是咱們惟一經過商業途徑獲取的商業化解決方案。
對於該環境,並沒有太多須要調整和規劃,可是是基於kvm,運維簡單,可是一旦故障,須要聯繫原廠技術支持解決。
如下爲建議和須要規避的問題:
一、計算網絡存儲融合,沒法直接經過第三方存儲來擴容,只能另購一樣的機器來進行橫向擴展
二、不建議將nutanix的存儲能力提供給其餘平臺或系統
三、若要將其餘虛擬化平臺虛擬機遷移到nutanix,須要原廠軟件和技術支持,風險較高,不建議直接遷移,如有須要,能夠考慮重搭建虛擬機
四、kvm對linux系統天生支持較好,windows系統會有bug,如藍屏io驅動錯誤等,推薦nutanix部署linux操做系統的虛擬機
五、kvm沒法模擬非x86架構的操做系統,定製化的虛擬機,如路由器,交換機,防火牆等操做系統,不能在nutanix上運行
六、Nutanix 上沒法導出虛擬機,虛擬機備份容災極度依賴快照功能,重要業務虛擬機須要開啓數據保護
七、Nutanix 上能夠直接對處於運行狀態的虛擬機進行刪除動做,極度危險,一旦刪除,不經過技術支持沒法恢復,須要增強操做管理linux
vsphere的虛擬化化境採用客戶老舊的x86服務器實現服務器虛擬化和使用兼容服務器搭建的開源存儲功能構建的。最先使用vps-here 5.5,在2017年7月完成升級到 vsphere6.5,採用註冊機破解許可。
總體組網架構比較複雜,可靠性很低,提供的虛擬機的能力極度依賴共享存儲,性能不高,很是容易故障。基本上只有一些測試業務在上面運行,整理利用率較低。
vsphere的組網架構以下:
nginx
架構簡單說明:
一、所謂前端交換機提供vps-here管理和虛擬機業務網絡
二、所謂後端交換機提供存儲網絡管理和存儲
三、兩臺存儲都是以NFS 協議的 NAS方式提供存儲能力,目前兩臺存儲分別是使用不一樣的開源解決方案,二者沒法關聯
四、爲了提高後端存儲網絡帶寬,後端網絡上特意使用了鏈路聚合技術
使用vsphere的虛擬化環境,有着如下優點:
一、全虛擬化,能夠模擬任何x86和通常的硬件,成熟穩定
二、商業化組件不少,知足全套解決方案所須要的各類特性,可擴展性好
三、運維管理功能健全web
雖然vsphere有着不少優勢,可是在咱們目前的環境中,主要由於物理服務器的不穩定和性能低下,形成不少問題:
一、故障率高
二、輕微調整則會影響總體穩定
三、特別是存儲,由於搭建存儲的物理服務器故障,致使總體平臺已經出現了屢次異常
四、無有效的存儲備份手段,也沒法對虛擬機進行容災管理
根據以上理由,對於vsphere的虛擬化環境使用有着以下建議:
一、儘量的使用全新的物理服務器代替老舊的服務器
二、儘量的使用商業存儲服務器,推薦使用存儲備份一體機
三、若無條件更換商業存儲, 可使用兩臺開源freenas實現存儲備份
四、在完成vsphere環境硬件調整以前,最好不要將生產業務虛擬機放在上運行sql
目前咱們的上層業務應用,主要是基於虛擬機的提供服務器資源,而後由服務器搭建的各類業務系統。主要根據各個功能劃分,分爲客戶業務、運維支撐和第三方業務系統。
客戶的業務虛擬機包括上線交付的業務系統和相關關聯的其餘虛擬機,如OA系統,性能監控,專線監控等。
運維支撐,是我方運維人員搭建的各類運維工具軟件等,支持各項運維管理工做。
第三方業務系統,指客戶要求其餘業務部署,非本公司產品,須要利用現有虛擬化環境的,如XX通,動環監控服務器。
相關建議:
一、客戶業務須要保持穩定,這也是運維工做的重點
二、第三方業務非客戶提出,不要干預
三、運維支撐的應用,是重中之重,須要運維人員重點關注
關於運維支持應用,會在後面重點闡明數據庫
有不少虛擬機是處於測試目的的而使用的,有一些虛擬機是處於異常或者中止使用狀態的,這些虛擬機的使用會消耗資源,因此對這些虛擬機須要進行清理。關於虛擬機的統計,見附件《虛擬機統計20190121》,這裏只是提出須要清理的虛擬機。
須要清理刪除的虛擬機以下表所示:windows
(略)
爲了方便和明確運維工做內容,須要明確運維工做內容,指導運維人員工做。
關於XX運維工做的內容,以下所示:
詳細運維工做見文件《XX運維工做梳理》
關於運維人員,技能要求不光須要懂網絡,同時須要熟悉虛擬機存儲操做系統和監控,技能要求較高。
對於運維工做內容有者以下要求:
一、每一個工做內容都須要有對應的文檔,包括操做,記錄等等
二、對於平常解決的故障內容須要記錄
三、重大操做須要通知客戶
運維工做極度依賴制度,和運維人員的職業操守。
在上層業務應用重,運維支撐是運維技術人員重點須要關注的,對於運維工具的理解和使用,能夠極大的提高效率,同時能夠及時響應故障,解決問題。
首先,在功能上,將XX的各個上層應用區分爲基礎環境、生產環境、測試環境三個類別。
基礎環境:構建運維架構中實現基礎功能的虛擬機與應用,包括爲提供時間同步的NTP服務器,提供yum加速安裝的yum倉庫服務,收集日誌的日誌服務器等。
生產環境:提供給客戶業務的虛擬機上層應用,包括專線監控平臺,zabbix監控等。
測試環境:運維人員進行測試使用的虛擬機,主要目的是測試各類開源工具運用等,一旦測試結果爲有用,能夠轉化爲運維工做管理的重要工具。
在總體運維支撐架構中,最核心底層的主要是由運維管理平臺opsmange支持,它實現CMDB資產配置管理,自動化運維等,方便運維人員對總體進行快速調整,快速部署。
jumperserver堡壘機,主要實現運維工做的總體入口,運維人員經過堡壘機可以進行登錄各個虛擬機,作到集中登錄和審計。
opsmangege運維管理平臺是徹底的開源軟件,簡單易用,比較與其餘商業軟件,更加適合XX運維工做。
登錄地址:
管理員帳號:
密碼:
主要功能模塊以下圖所示:
詳細的操做見公司wiki:
對於咱們而言,目前側重的資產管理和自動化運維
資產管理
任務管理
批量腳本運行模塊
說明:
一、該平臺能夠批量對linux主機進行配置管理,沒法對windows主機進行批量管理
二、不少功能能夠挖掘使用
三、開源版本目前沒有完善的操做手冊
地址:
管理員:
密碼:
該日誌平臺只作收集交換機等網絡設備日誌,不能收集系統日誌,
如如有更好的商業日誌收集軟件,則能夠選擇替代
目前,全部的專線業務,包括XX各個網絡的華爲系列的交換機,都配置了radius認證,全部登錄帳號都會被集中受權和管理。
地址:
帳號:
密碼:
設備記錄
認證記錄
目前radius 認證服務器採用破解版部署,穩定性通常,須要注意,全部的網絡設備交換機配置3A認證時,優先採用本地認證,其次纔是radius認證,即便沒有radius認證服務器,全部的網絡設備也能夠正常登錄使用,推薦往後採用專業的商業radius服務器解決方案,來知足等級保護要求。
graylog 是一個用來將系統日誌syslog保存到MongoDB中的工具。 包括一個用Java編寫的服務器,可接收來自TCP和UDP的syslog信息,Web接口使用Ruby編寫,基於 Rails 框架,可用來查看日誌信息。
Wiki 地址:
地址:
管理員:
密碼:
日誌收集效果
能夠簡單使用,可是高級功能和可視化,告警等功能須要研究一段時間
Racktables 是一個用來管理機房資產的開源工具,能夠用來管理成百上千臺的服務器及更多的 IP 和 MAC 地址。適用於機房和數據中心的服務器管理。
公司wiki地址:
地址:
管理員:
密碼:
主要功能截圖以下:
此套開源軟件,使用最爲簡單,同時操做手冊也最爲詳盡。
堡壘機做爲運維人員登錄入口,提供集中登錄和集中日誌審計功能。
地址:
管理帳號:
密碼:
推薦運維人員主要經過堡壘機對單個運維主機進行登錄管理。
生產環境,就是對面對客戶的重要業務,由研發主導交付,運維人員須要持續關注,保證環境穩定。
目前XX業務系統,包括已經交付使用的資源管理門戶(OA),傳輸網性能監控平臺,和處於試用階段的文檔管理平臺和流程管理平臺,前二者運行在nutanix平臺之中,後二者運行在vsphere平臺之中。
關於XX業務系統,公司wiki上有詳細的操做指南。每一個業務系統都是部署在windows操做系統之上,web服務器使用tomcat +jdk,數據庫使用mysql,開發語言使用php和java,運維人員須要對這些方面有所瞭解。
日常運維時須要關注狀態,接受故障處理反饋。
日常故障主要集中在幾點:
一、tomcat服務啓動失敗
二、mysql服務啓動失敗
三、虛擬機存儲空間不夠
四、網絡問題致使客戶不能訪問業務
五、windows操做系統異常須要排查
四臺業務服務器,都採用數據庫備份的計劃任務,保證數據級別備份;
備份的數據庫集中保存在共享NFS文件目錄中;
依靠nutanix數據保護功能進行虛擬機級別的備份容災
依靠nutanix的副本機制,實現主機存儲級別的備份容災。
針對重要業務的虛擬機和數據的備份容災,大體以下圖所示:
說明:
一、除了傳輸網性能監控平臺採用第三方數據庫備份以外,其餘的業務虛擬機數據庫備份採用mydump 腳本形式,採用計劃任務形式,自動執行
二、除了傳輸網性能監控平臺將數據庫導出備份到虛擬機本地磁盤以外,其餘業務虛擬機都是講數據庫導出備份到NFS共享目錄服務器。
三、在nutanix平臺上,開啓數據保護,對重要業務虛擬機進行每個月一次的定時快照備份
四、在nutanix平臺上,開啓副本機制,平臺上的全部的虛擬機都會都會三副本的機制保存在三個節點上,實現存儲級別的容災
Vsphere 平臺上沒有使用任何虛擬機保護機制
針對vsphere的平臺,實現容災備份建議以下:
一、使用存儲的複製技術,實現容災備份
二、部署vpshere data protection 組件實現虛擬機級別的備份容災
三、若有條件,更換商業版本的備份存儲一體機,實現總體存儲級別的備份容災。
目前XXxxx主要是做爲接入xxx使用,知足客戶和運維人員遠程接入光XX內網環境進行辦公和調試需求。xxx服務器採用開源的SSL xxx的OPENxxx解決方案,使用二層隧道模式接入XX內網環境。登錄上採用域名解析實現多xxx服務器分配保證可靠性,規劃大體下所示:
說明:
一、XX一共擁有四臺xxx服務器,vpshere上兩臺,nutanix平臺上兩臺,互爲冷備關係
二、主域名xxx.xxx.xxx,備域名xxx.xxx.xxx,使用阿里雲的域名解析服務
三、使用域名+端口號區分主用xxx和備用xxx環境,如客戶使用xxx.xxx.xxx:xxx登錄主用xxx服務器,而使用xxx.xxx.xxx:xxxx登錄備用xxx服務器。
四、阿里雲DNS服務,會跟根據用戶的實際網絡運營商環境,將域名解析爲XX不一樣的公網地址,如用戶使用電信網絡登錄xxx,DNS解析爲xxx.xxx.xxx.xx,若是用戶使用聯通的網絡登錄xxx,DNS解析爲xxx.xxx.xxx.xxx
五、公網地址xx.xx.xx.xx是由XX集團平臺公司cdn網絡提供,由於核心網絡對接關係,處於聯通運營商網絡的用戶,沒法正常訪問,此時須要訪問備用公網地址,因此此時須要阿里雲DNS系統來進行智能區分
六、每一個平臺上的xxx服務器使用冷備,一旦主要xxx服務器不能及時恢復,能夠切換到冷備服務器上,保證用戶的使用。
對於運維人員來講,除了須要關注xxx服務器的狀態,帳號登錄狀況,還須要檢測域名狀況,一旦域名解析故障,失效,會致使xxx服務器的訪問異常。
由於XX內網環境的特殊性,因此沒法直接部署內網域名服務器,重要業務沒法使用域名直接訪問,因此採用阿里雲域名解析+NGINX域名轉發+keepalived高可用實現。
一、在阿里雲DNS解析上作好了域名解析綁定,如xxx.xxx.xxx.xx,所有解析到xxx.xxx.xx.xx
二、兩臺nginx使用keepalived使用相似vrrp協議的方式實現高可用,對外提供vip
三、兩臺nginx實現雙機熱備的高可用,配置同樣,實現域名轉發到指定內網服務器。
域名轉發已是實際上客戶訪問業務的重要手段,它可以解決XX內網無域名解析服務器的問題,同時能夠作到保證用戶使用域名方式業務
運維人員須要重點關注,按照如下幾點進行運維
一、保證阿里雲DNS解析服務可以正常
二、保證nginx服務以及域名轉發配置正常
三、保證keepalived服務器進程正常,不能處於腦裂狀態
四、保證防火牆策略正常,vlan101網段能夠訪問vlan102網段,保證nginx網絡上轉發正常。
目前XX環境下,有不少跳板機,除了做爲內網接入跳板提供給客戶和運維人員使用以外,還做爲一條屏障,阻隔外部網絡病毒影響和***行爲,主要是依靠360安全衛士進行。
運維人員,須要關注360安全服務器,保證可以穩定正常。
運維工做中,有不少狀況,是須要進行設置告警的,在出現問題以後,可以及時知曉並進行處理。
運維人員須要及時配置相應系統的告警配置,包括nutanix平臺,vsphere平臺和基礎環境。