企業(yè)域名管理系統(tǒng)的搭建&數(shù)據(jù)庫高可用改造

2016-08-31    分類: 網(wǎng)站建設

之前有負責過公司的內網(wǎng)域名系統(tǒng)的開發(fā)以及一部分的建設。在這里做個總結。
首先第一個問題:商用的域名管理平臺有DNSPOD,有阿里的域名管理平臺,還有一些小眾平臺,比如dns.la等。有些做運維的同學都不是特別明白,我們使用公網(wǎng)的DNS系統(tǒng)就可以啊,為啥你們公司還搞個內部的DNS服務,我們之前都不需要。
解答:使用公網(wǎng)DNS服務的時候,我們企業(yè)內部服務之間的調用是這樣的:
公司內部服務之間的調用量,小公司可能還好本身自己的量也不大,但是當公司做大之后內網(wǎng)的網(wǎng)絡傳輸量是非常大的,這個時候如果我的服務1 和服務2之間的通信域名解析要走公網(wǎng)出去繞一圈再回來,對性能要求高的肯定是沒法接受的,我2臺機器都純內網(wǎng)高速網(wǎng)絡卻讓我去公網(wǎng)繞一圈,本身這是一點,其次呢是:穩(wěn)定性,出公網(wǎng)就意味著公網(wǎng)出現(xiàn)網(wǎng)絡抖動等等都會影響服務的響應。技術可要更高的效率以及穩(wěn)定性。緩存這一塊也該考慮進去,對于迭代頻繁以及一些需要秒切服務的應用,公網(wǎng)DNS更是個大的瓶頸。
上述就是為什么要在自己公司內部自建DNS服務的原因。那接下來就是搭建。
搭建我們選BIND,網(wǎng)上教程很多,這個不做過多的講解。服務好了,在初始化鏡像里加入我們的nameserver地址,本地找不到再去公網(wǎng)上。如圖:
服務1和服務2直接走內網(wǎng)DNS服務請求,同時我們新增域名等等一系列的操作都可以立刻reload服務,刷新。內部DNS服務不存在的才去找公網(wǎng)DNS服務。
問題二:平臺搭建使用zone文件還是數(shù)據(jù)庫存儲解析數(shù)據(jù)?
解答:zone文件存儲是傳統(tǒng)的方式,解析都是配置文件里。優(yōu)勢,不會存在任何問題,本地讀取,缺點:很不方便使用。數(shù)據(jù)庫存儲是后來Bind服務支持的方式,更方便的增刪改查,bind服務讀取都直接從數(shù)據(jù)庫中讀取解析信息,缺點:bind服務和數(shù)據(jù)庫之間的連接出現(xiàn)抖動就會出現(xiàn)問題,其次,數(shù)據(jù)庫的高可用也是風險點。綜合一下,我司更愿意使用第一種方案,運維最在意的就是穩(wěn)定。使用不方便可以通過平臺開發(fā)實現(xiàn)。
接下來就是開發(fā)的工作了。本人使用django 實現(xiàn)快速的迭代。架構圖如下:
線上的DNS服務不能因為我們的平臺而導致服務穩(wěn)定性出現(xiàn)問題,所以平臺需要脫離線上服務,管理平臺和線上所有機器建立免秘鑰登錄,管理平臺和線上的所有DNS服務之間只是線上會推送文件zone文件給線上,然后執(zhí)行reload
問題:為什么要冷備不選負載均衡?
解答:因為zone文件是存在服務器上的文本,如果采用負載會導致兩邊機器同時更新,同時互相推送等的問題,主機器只需要把備也當做線上機器一樣推送zone文件就OK,當主掛了備起來,當然了,我們就是想實現(xiàn)負載均衡也肯定是可以的,不過,我們更關注的是高效和快速的開發(fā)使用。這個架構對我們來說不存在瓶頸。
平臺開發(fā)中的功能:1.解析增刪改查,備注,批量增刪改查,這些都是基本功能。其次就是操作記錄一定要記錄全,要支持一鍵回滾。按照企業(yè)需求開發(fā)就好。
問題:數(shù)據(jù)庫高可用改造?
解答:首先為什么域名解析會和數(shù)據(jù)庫都扯上關系了呢。感覺一點關系都沒有的東西怎么就有了交叉呢。
公司做大之后,運維需要考慮更多的東西,比如:異地容災,萬一北京的機房火災了,如何立馬把所有的服務切換到上海,對服務要求更高的要求2地機房負載,用戶理哪里近請求哪里的資源。這個時候我們的平臺就能發(fā)揮橫向擴展了,只要上海的DNS服務器和我們的平臺之間建立免秘鑰就OK,分分鐘搞定。
問題來了,在異地機房容災這一塊,數(shù)據(jù)庫也要實現(xiàn)容災。那就得北京和上海同時擁有相同的數(shù)據(jù)庫,假設北京數(shù)據(jù)庫出現(xiàn)問題(阿里RDS 腦裂或機房火災)如何立馬切換到上海呢?
給每個使用數(shù)據(jù)庫的用戶都是通過域名來訪問的。例如:dba.dba.com
我們需要實現(xiàn)當北京的數(shù)據(jù)不可用的時候:dba.dba.com    172.168.1.1 這條解析立馬切換成dba.dba.com    172.169.1.1的解析,172.169.1.1 這個IP是我們大內網(wǎng)上海的網(wǎng)段IP

看著好像是非常好,DBA的需求也實現(xiàn)了。當他們200+的域名需要全部切換到上海的時候,約定規(guī)范,幾秒只能全部修改了推送到上海機器,然后reload 生效。
那么問題又來了:平臺部署在北京機房,如果北京機房只是數(shù)據(jù)庫故障還好,平臺在就能切換。那如果北京機房不可用了呢。我們的平臺都能用了,還怎么給我切換了。我上海不能用了還要切換北京呢。這些都怎么給我解決呢。。。
一臉懵逼。。。。
解決方案:

架構是有些復雜了。把DNS平臺好克隆到上海一套,為了讓用戶無感操作,點擊上海域名的時候在nginx上做強跳轉到上海,認證可以通過在cookie里面設置值實現(xiàn)。
這樣是不是就可以北京全部down掉之后需上海不受影響了。

本文名稱:企業(yè)域名管理系統(tǒng)的搭建&數(shù)據(jù)庫高可用改造
網(wǎng)站鏈接:http://www.bm7419.com/news/46018.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站設計公司、云服務器定制網(wǎng)站、網(wǎng)站策劃品牌網(wǎng)站設計、網(wǎng)站設計

廣告

聲明:本網(wǎng)站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經(jīng)允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)

成都網(wǎng)站建設公司