DNS實戰--2
構建企業級DNS
服務壓測，服務的功能測試，這些在生產中都要考慮到php
一、硬件選型
dns對網卡和cpu消耗大
下面配置能夠達到單臺服務器每秒3萬請求，0延時
CPU：12c以上配置
內存：16GB
網絡：千兆html
二、初始化系統
關閉selinux，iptables，調整ulimit限制node
三、構建高性能，高可用dns
採用lvs-dr模式負載均衡，多idc，多套dns集羣，經過master-slave技術保證dns配置的一致性
（1）、高可用
物理層：
首先確保兩臺lvs不在統一機櫃、同一物理交換機接入；
其次確保將全部dns服務器也作到不在同一機櫃、同一物理交換機接入。
同時，在不一樣的idc構建多套dns集羣，爲客戶端提供可切換的配置。mysql
服務層：
堅定摒棄lvs上端口檢測這種方式，採用自定義腳本檢測，爲dns的健康檢測單獨設置一個域名，就爲了lvs檢測dns是否存活而設計。linux
腳本示例，這個腳本是部署在lvs上，作健康檢測的git
#!/bin/sh
timeout=5
Q="baidu.com"
host="/usr/bin/host"
if test -z "$1" ;then
echo "You need to supply a DNS Server to check. Quitting"
exit;
fi
SERVER=$1
ERC=`$host -s -w $timeout $Q $SERVER > /dev/null 2>&1;echo $?`
if [ $ERC -eq 0 ];then
exit 0
else exit 1
fi
客戶端層：
多idc之間的流量切換是經過客戶端的健康檢測cron實現的，腳本每分鐘運行一次，分別檢測每一個dns集羣虛地址的可用性。github
（2）、高性能
經過lvs能夠對每一個集羣作橫向擴容，是否須要擴容的一句是對現有系統的壓測結果，以及實時的監控數據。
亦或者能夠在靠近應用層處，加上一層cache-only集羣，但前提是你的線上環境中，沒人任何系統依賴於dns負載均衡sql
四、壓測thinkphp
[root@linux-node1 tools]# wget http://ftp.isc.org/isc/bind9/9.7.3/bind-9.7.3.tar.gz --2017-05-19 15:38:02-- http://ftp.isc.org/isc/bind9/9.7.3/bind-9.7.3.tar.gz Resolving ftp.isc.org... 149.20.1.49 Connecting to ftp.isc.org|149.20.1.49|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 7653584 (7.3M) [application/x-gzip] Saving to: 「bind-9.7.3.tar.gz」 100%[======================================================================>] 7,653,584 1.13M/s in 7.9s 2017-05-19 15:38:12 (950 KB/s) - 「bind-9.7.3.tar.gz」 saved [7653584/7653584] [root@linux-node1 tools]# tar xfz bind-9.7.3.tar.gz [root@linux-node1 tools]# cd bind-9.7.3/contrib/queryperf/
配置和編譯數據庫
[root@linux-node1 queryperf]# ./configure checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for library containing res_mkquery... no checking for library containing __res_mkquery... -lresolv checking for socket in -lsocket... no checking for inet_ntoa in -lnsl... yes checking for gethostbyname2... yes checking for getaddrinfo... yes checking for getnameinfo... yes checking for socklen_t... yes checking for sa_len... no configure: creating ./config.status config.status: creating Makefile config.status: creating config.h [root@linux-node1 queryperf]# make gcc -DHAVE_CONFIG_H -c queryperf.c gcc -DHAVE_CONFIG_H queryperf.o -lnsl -lresolv -lm -o queryperf [root@linux-node1 queryperf]#
[root@linux-node1 queryperf]# ls config.h config.log configure input Makefile.in queryperf queryperf.o utils config.h.in config.status configure.in Makefile missing queryperf.c README [root@linux-node1 queryperf]# cp queryperf /usr/bin/ [root@linux-node1 queryperf]#
[root@linux-node1 queryperf]# cat test.txt www.baidu.com A www.qq.com A www.sina.com A www.dangdang.com A [root@linux-node1 queryperf]# queryperf -d test.txt -s 10.0.1.161 DNS Query Performance Testing Tool Version: $Id: queryperf.c,v 1.12 2007-09-05 07:36:04 marka Exp $ [Status] Processing input data [Status] Sending queries (beginning with 10.0.1.161) [Status] Testing complete Statistics: Parse input file: once Ended due to: reaching end of file Queries sent: 4 queries Queries completed: 4 queries Queries lost: 0 queries Queries delayed(?): 0 queries RTT max: 0.172311 sec RTT min: 0.000703 sec RTT average: 0.075561 sec RTT std deviation: 0.063613 sec RTT out of range: 0 queries Percentage completed: 100.00% Percentage lost: 0.00% Started at: Fri May 19 15:43:39 2017 Finished at: Fri May 19 15:43:39 2017 Ran for: 0.172392 seconds Queries per second: 23.202933 qps [root@linux-node1 queryperf]#
監控結合zabbix實現
系統基礎性能：
使用zabbix自帶模板便可。cpu、內存、主機存活、磁盤空間、主機運行時間、系統load
LOOPBACK地址綁定狀態監控：
該架構中，dnsserver在集羣中充當realserver的角色，在dr中，須要綁定loopback的地址方能通訊，所以當loopback地址沒有綁定上時，lvs健康檢測經過，可是當請求到達dnsserver時，請求被拒絕，dns集羣會出現異常。
DNS數據與MASTER一致性監控：
一是經過寫zabbix自定義discovery，掃出dns配置中全部zone，而後分別對比slave和master每一個zone的serial值，當slave與master的值持續5分鐘不一致時報警
二是寫腳本，每15分鐘掃一遍master上全部域名解析結果，與每一個slave的結果作對比，當出現結果不一致時，報警
DNS響應時間監控：
遠端一組主機跑在fullnat下（提供高可用），經過dig命令監測dnsserver的響應時間。
其中Query time就是查詢的時間
[root@linux-node1 ~]# dig @127.0.0.1 www.baidu.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @127.0.0.1 www.baidu.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 31992 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.baidu.com. IN A ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri May 19 17:10:27 2017 ;; MSG SIZE rcvd: 31 [root@linux-node1 ~]#
DNS每秒請求數監控：
[root@linux-node1 ~]# grep stats /etc/named.conf Statistics-file "/var/named/chroot/var/log/named_stats"; memstatistics-file "log/mem_stats"; [root@linux-node1 ~]#
[root@linux-node1 ~]# rndc stats WARNING: key file (/etc/rndc.key) exists, but using default configuration file (/etc/rndc.conf)
[root@linux-node1 ~]# cat /var/named/chroot/var/log/named_stats
+++ Statistics Dump +++ (1495185099)
++ Incoming Requests ++
393 QUERY
++ Incoming Queries ++
23 A
362 SOA
3 MX
3 AAAA
++ Outgoing Queries ++
[View: GROUP1]
11 A
3 NS
1 MX
1 AAAA
[View: GROUP2]
[View: _bind]
++ Name Server Statistics ++
393 IPv4 requests received
362 requests with EDNS(0) received
393 responses sent
362 responses with EDNS(0) sent
24 queries resulted in successful answer
6 queries resulted in authoritative answer
385 queries resulted in non authoritative answer
362 queries resulted in referral answer
5 queries resulted in nxrrset
14 queries caused recursion
++ Zone Maintenance Statistics ++
++ Resolver Statistics ++
[Common]
[View: GROUP1]
16 IPv4 queries sent
16 IPv4 responses received
14 queries with RTT 10-100ms
2 queries with RTT 100-500ms
[View: GROUP2]
[View: _bind]
++ Cache DB RRsets ++
[View: GROUP1 (Cache: GROUP1)]
4 A
1 NS
6 CNAME
1 MX
1 RRSIG
[View: GROUP2 (Cache: GROUP2)]
[View: _bind (Cache: _bind)]
++ Socket I/O Statistics ++
18 UDP/IPv4 sockets opened
3 TCP/IPv4 sockets opened
16 UDP/IPv4 sockets closed
2 TCP/IPv4 sockets closed
16 UDP/IPv4 connections established
3 TCP/IPv4 connections accepted
++ Per Zone Query Statistics ++
[viewlnh.com (view: GROUP1)]
1 queries resulted in successful answer
3 queries resulted in authoritative answer
2 queries resulted in nxrrset
[viewlnh.com (view: GROUP2)]
1 queries resulted in successful answer
3 queries resulted in authoritative answer
2 queries resulted in nxrrset
[version.bind (view: _bind)]
[hostname.bind (view: _bind)]
[authors.bind (view: _bind)]
[id.server (view: _bind)]
--- Statistics Dump --- (1495185099)
[root@linux-node1 ~]#
#!/bin/bash
#rndc stats
STATS='/var/named/chroot/var/log/named_stats'
if [ $# -ne 1 ];then
echo "$0 [querys]"
exit 2
else
which=$1
fi
if [ -f "${STATS}" ];then
echo > ${STATS}
rndc stats >dev/null 2>&1
else
echo "${STATS} not found "
exit 2
fi
case ${which} in
querys)
RESULT=` awk '{if ($2=="QUERY") {print $1}}' ${STATS}`
;;
*)
echo "$0 [querys]"
exit 2
;;
esac
echo ${RESULT}
DNS可用性監控：
遠端一組主機跑在fullnat下（提供高可用），經過host命令監測dnsserver的可用性，腳本與lvs健康檢測腳本相似
六、自動化
saltstack安裝、部署
經過定製saltstack配置，實現自動、批量安裝、部署dns
配置管理自動化
業界最多的是bind-dlz，dlz是指將全部的配置都存在mysql表中，對bind作特殊配置，使得每次bind
接受的請求都去mysql中查詢數據以後返回給用戶
bind-dlz的優缺點
優點：將數據所有存在數據庫，符合運維開發的理念。
劣勢：每次解析都要select數據庫，性能低下；增長了系統的耦合性，還須要保證mysql的高可用
爲何要作成頁面能夠管理的呢
七、安全
時刻關注dns相關的抖動、補丁；
選用稍大些的廠商做爲域名服務商，咱們是萬網；
對服務器的登陸日誌作監控分析；
八、平常運維規範
dns做爲基礎服務，在作好高可用，高性能，好擴容的基礎上，任什麼時候刻都不能掉以輕心
確保全部監控均處於生效狀態；
全部新機器，均在saltstack上完成初始化和安裝、部署操做，不能單獨操做；
全部針對dns架構調整的操做，均需在流量低谷時操做；
對集羣擴容操做時，務必對新加入節點作壓測，同時重啓服務器並檢測重啓後各項指標是否正常；
關注dns相關新聞，時刻根據
九、DNS發展趨勢
（1）DNSMASQ
DNSmasq是一個小巧且方便地用於配置DNS和DHCP的工具，適用於小型網絡，它提供了DNS功能和可選擇的DHCP功能。
它服務那先只在本地使用的域名，這些域名是不會在全球的DNS服務器中出現的。
DHCP服務器和DNS服務器結合，而且容許DHCP分配的地址能在DNS中正常解析，而這些DHCP分配的地址和相關命令能夠配置到每臺主機中，
也能夠配置到一臺核心設備中（好比路由器），DNSmasq支持靜態和動態兩種DHCP配置方式。
有一些公司在每臺服務器上都起着dnsmasq，充當本地dns緩存服務，來提升dns解析性能同時減輕dnsserver的壓力。
（2）HTTPDNS
但凡使用域名來給用戶提供服務的互聯網企業，都或多或少沒法避免在有中國特點的互聯網環境中遭遇到各類域名被緩存、用戶跨網訪問緩慢等問題。
首先是域名緩存，不一樣運營商、不一樣節點的緩存時間設置的差異較大。這樣在流量切換時，就會產生新、舊應用數據不一致的現象。
其次就是域名解析過了太多層的nat，這就致使dns獲取客戶端地址時很難準肯定位，從而智能dns的準確度大打折扣。
最近幾年httpdns出現了，用戶明確的知道我在訪問某廠的服務時，應該去找哪一個ip要對應的域名，實現這個的前提是你能夠左右用戶的訪問習慣，目前應用最合適的場景是app。
參照以下連接http://www.dnsdizhi.com/post-240.html
HttpDNS的原理很是簡單，主要有兩步：
A、客戶端直接訪問HttpDNS接口，獲取業務在域名配置管理系統上配置的訪問延遲最優的IP。
（基於容災考慮，仍是保留次選使用運營商LocalDNS解析域名的方式）
B、客戶端向獲取到的IP後就向直接往此IP發送業務協議請求。以Http請求爲例，經過在header中指定host字段，向HttpDNS返回的IP發送標準的Http請求便可。
（2）HttpDNS優點：
從原理上來說，HttpDNS只是將域名解析的協議由DNS協議換成了Http協議，並不複雜。可是這一微小的轉換，卻帶來了無數的收益：
A、根治域名解析異常：因爲繞過了運營商的LocalDNS，用戶解析域名的請求經過Http協議直接透傳到了騰訊的HttpDNS服務器IP上，用戶在客戶端的域名解析請求將不會遭受到域名解析異常的困擾。
B、調度精準：HttpDNS能直接獲取到用戶IP，經過結合騰訊自有專利技術生成的IP地址庫以及測速系統，能夠保證將用戶引導的訪問最快的IDC節點上。
C、實現成本低廉：接入HttpDNS的業務僅須要對客戶端接入層作少許改造，無需用戶手機進行root或越獄；並且因爲Http協議請求構造很是簡單，兼容各版本的移動操做系統更不成問題；
另外HttpDNS的後端配置徹底複用現有權威DNS配置，管理成本也很是低。總而言之，就是以最小的改形成本，解決了業務遭受域名解析異常的問題，並知足業務精確流量調度的需求。
D、擴展性強：HttpDNS提供可靠的域名解析服務，業務可將自有調度邏輯與HttpDNS返回結果結合，實現更精細化的流量調度。好比指定版本的客戶端鏈接請求的IP地址，指定網絡類型的用戶鏈接指定的IP地址等。
固然各位可能會問：用戶將首選的域名解析方式切換到了HttpDNS，那麼HttpDNS的高可用又是如何保證的呢？另外不一樣運營商的用戶訪問到同一個HttpDNS的服務IP，用戶的訪問延遲如何保證？
爲了保證高可用及提高用戶體驗，HttpDNS經過接入了騰訊公網交換平臺的BGP Anycast網絡，與全國多個主流運營商創建了BGP互聯，保證了這些運營商的用戶可以快速地訪問到HttpDNS服務；另外HttpDNS在多個數據中心進行了部署，任意一個節點發生故障時均能無縫切換到備份節點，保證用戶解析正常。
- 1. DNS實戰--2
- 2. Azure DNS 實戰
- 3. DNS實戰--1
- 4. DNS實戰
- 5. dnsmasq配置dns實戰
- 6. DHCP與DNS綜合實戰
- 7. 第二章實驗2 dns
- 8. mutillidae實戰（2）
- 9. Python實戰（2）
- 10. SpringBoot實戰（2）
- 更多相關文章...
- • Mybatis實現映射器的2種方式 - MyBatis教程
- • Thymeleaf擴展2(Say Hello) - Thymeleaf 教程
- • Docker容器實戰(一) - 封神Server端技術
- • Docker容器實戰(八) - 漫談 Kubernetes 的本質
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. DNS實戰--2
- 2. Azure DNS 實戰
- 3. DNS實戰--1
- 4. DNS實戰
- 5. dnsmasq配置dns實戰
- 6. DHCP與DNS綜合實戰
- 7. 第二章實驗2 dns
- 8. mutillidae實戰（2）
- 9. Python實戰（2）
- 10. SpringBoot實戰（2）