之前有負責過公司的內(nèi)網(wǎng)域名系統(tǒng)的開發(fā)以及一部分的建設。在這里做個總結。
首先第一個問題：商用的域名管理平臺有DNSPOD，有阿里的域名管理平臺，還有一些小眾平臺，比如dns.la等。有些做運維的同學都不是特別明白，我們使用公網(wǎng)的DNS系統(tǒng)就可以啊，為啥你們公司還搞個內(nèi)部的DNS服務，我們之前都不需要。
解答：使用公網(wǎng)DNS服務的時候，我們企業(yè)內(nèi)部服務之間的調(diào)用是這樣的：
公司內(nèi)部服務之間的調(diào)用量，小公司可能還好本身自己的量也不大,但是當公司做大之后內(nèi)網(wǎng)的網(wǎng)絡傳輸量是非常大的,這個時候如果我的服務1 和服務2之間的通信域名解析要走公網(wǎng)出去繞一圈再回來，對性能要求高的肯定是沒法接受的，我2臺機器都純內(nèi)網(wǎng)高速網(wǎng)絡卻讓我去公網(wǎng)繞一圈，本身這是一點，其次呢是：穩(wěn)定性，出公網(wǎng)就意味著公網(wǎng)出現(xiàn)網(wǎng)絡抖動等等都會影響服務的響應。技術可要更高的效率以及穩(wěn)定性。緩存這一塊也該考慮進去，對于迭代頻繁以及一些需要秒切服務的應用，公網(wǎng)DNS更是個大的瓶頸。
上述就是為什么要在自己公司內(nèi)部自建DNS服務的原因。那接下來就是搭建。
搭建我們選BIND,網(wǎng)上教程很多，這個不做過多的講解。服務好了，在初始化鏡像里加入我們的nameserver地址，本地找不到再去公網(wǎng)上。如圖：
服務1和服務2直接走內(nèi)網(wǎng)DNS服務請求，同時我們新增域名等等一系列的操作都可以立刻reload服務，刷新。內(nèi)部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是我們大內(nèi)網(wǎng)上海的網(wǎng)段IP

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

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

分享文章：企業(yè)域名管理系統(tǒng)的搭建&數(shù)據(jù)庫高可用改造
文章鏈接：http://chinadenli.net/news18/46018.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供微信公眾號、云服務器、品牌網(wǎng)站制作、商城網(wǎng)站、做網(wǎng)站、建站公司

廣告

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