Windows google apache 开源 Android java Ubuntu linux shell Firefox 编程 centos Python wordpress 云计算 微软 nginx 程序员 mysql php

運維前線:一線運維專家的運維方法、技巧與實踐1.6 運維自動化系統的實現

挑戰自動化的極致場景(可視化),是運維人員對極致的追求。極致的自動化是運維事務全流程的自動化,運維事務全流程自動化是包含了一次應用完整交付所涉及的所有資源的自動化能力,比如說DNS資源、負載均衡資源、數據庫資源、服務器資源、配置資源等。下面將列舉幾個典型的運維自動化系統以供大家參考。

1.6.1 DNS管理系統

DNS是Web形態下的一個重要入口,用戶服務的訪問嚴格依賴於這個服務入口。現在一般被稱為GSLB(全局服務負載均衡調度),目前是CDN服務中的重要服務節點。實現的目標都是要解決運維從哪裏來,到哪裏去最快,當目標機房發生故障的時候,如何把服務調度走。

在移動APP大量應用的今天,DNS協議的缺點已經逐漸暴露出來了,DNS解析時間長,另外還經常會被劫持。因為有端的控制,現在逐漸開始走HTTPDNS的服務,通過HTTP服務的方式獲取域名對應的ip地址,此時由DNS平臺直接對外提供HTTP服務。在有端App的情況下,還可以借助端的數據挖掘技術,識別非權威DNS域名是否存在被劫持的情況。系統需要保持和業務的與時俱進。

這裏還需要註意一個問題,內部DNS能否統一管理?理論上是可以的,把單個機房當作單個的view,不過我不建議將兩個場景耦合在一起,盡管這樣能夠實現統一管理。

系統Demo如圖1-7所示。

 

圖1-7 DNS管理系統

1.6.2 CMDB管理系統

CMDB管理系統的建設這裏就不展開介紹了,感興趣的讀者可以關註微信公眾號“互聯網運維雜談”,並參閱《運維平臺之CMDB系統建設》一文。

系統Demo如圖1-8所示。

1.6.3 名字服務中心系統

“名字服務中心系統”的概念最初來自於Zookeeper,該系統結合實際情況,實現了名字服務中心。把程序接口之間的調用抽象成單個服務之間的調用,在服務中心實現調度的統一註冊、鑒權、ACL、容災容錯控制。將其看作線上服務最核心的系統,一點也不為過,並且它還是收益最大的系統,可直接替換掉DNS、LVS,降低線上系統對運維系統的依賴性。

系統Demo如圖1-9所示。

 

圖1-8 CMDB管理系統

 

圖1-9 名字服務中心系統

1.6.4 持續部署管理系統

持續部署是應用升級的核心系統,該系統每個月都承擔著大量的變更。在系統規劃之初,我們就給它設定了清晰的業務管理目標:持續交付的一部分,實現圖1-10中的4個維度管理目標;也設定了具體業務的運維目標:升級所有的包和配置,且讓業務運維徹底退出業務的變更流程。具體如圖1-10所示。

系統Demo如圖1-11所示。

持續部署系統是持續交付系統的核心(持續集成、持續測試、持續部署、持續反饋),它是產品發布到達生產環境的關鍵步驟。在這個平臺的建設上,運維人員應該將它作為突破的第一個點。在該平臺搭建完成之後,運維就可以從日常的部署事務中解放出來了。

 

圖1-10 持續部署管理系統示意圖

 

圖1-11 發布系統

1.6.5 運維調度管理系統

運維調度平臺又稱為調度編排系統,編排是一種場景化的運維能力封裝,是對復雜運維事務的封裝。我們在平時的運維過程中能夠看到很多復雜的運維場景,比如說容災切換、故障處理、服務遷移等。這些場景,很多時候都不是單一的動作就能夠完成的,往往需要借助多種運維能力組合,如圖1-12所示。

在圖1-12中,我們把Ops自動化調度下面的服務支撐層分解為三部分:工具平臺OpsStore,用來編寫日常的運維工具;外部服務,用於公共API對外提供封裝;Ops發布,用於提供代碼持續部署服務。

一個完整的自動化調度平臺應具備能夠對接一切服務的能力,例如通過配置管理來初始化內核、通過OpenStack來初始化資源、通過DNS來獲取全局調度服務、通過存儲來獲取存儲的服務,甚至還可以通過公有雲API來獲取外部公有雲的資源服務能力,如圖1-13所示。

 

圖1-13 自動化調度平臺示意圖

還有數據庫運維管理平臺、分布式Cache管理系統等也都有相應的實現,由於篇幅所限,這裏就不貼圖介紹了。

延伸阅读

    评论