[20180427]SCAN_IP DNS 反向解析2.txt

lfree發表於2018-04-28
[20180427]SCAN_IP DNS 反向解析2.txt

--//從Oracle 11gR2開始,引入SCAN(Single Client Access Name) IP的概念,相當於在客戶端和資料庫之間增加一層虛擬的網路服務層
--//,即是SCAN IP和SCAP IP Listener。在客戶端的tnsnames.ora配置檔案中,只需要配置SCAN IP的配置資訊即可,客戶端透過SCAN
--//IP、SCAN IP Listener來訪問資料庫。同之前各版本的RAC相比,使用SCAN IP的好處就是,當後臺RAC資料庫新增、刪除節點時,客
--//戶端配置資訊無需修改。

--//當然這樣配置DNS變成了實施RAC的重要步驟,在具體的實踐的過程中,我遇到過一例問題,如果dns出現問題,會導致整個應用無法登入
--//或者登入很慢的情況,我以前遇到的問題就是IP反向解析的問題.透過測試說明問題.

1.環境:
SYS@dbcn1> @ &r/ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

2.測試1:
--//再client登入執行:
$ host 192.168.100.78
Host 78.100.168.192.in-addr.arpa. not found: 3(NXDOMAIN)

$ host gxqyydg4
Host gxqyydg4 not found: 3(NXDOMAIN)

--//可以發現client ip以及主機名無法解析.這並不重要,只要能解析scan name就ok了.

$ rlsql   system/xxxx@dm01-scan:1521/dbcn::dbcn1
SYSTEM@dm01-scan:1521/dbcn::dbcn1> select INSTANCE_NUMBER, INSTANCE_NAME from v$instance ;
INSTANCE_NUMBER INSTANCE_NAME
--------------- ----------------
              1 dbcn1


--//在服務端執行如下:
#  tcpdump -l  -i bondeth0   dst port 53  -nn -vv | tee -a /tmp/xx2.txt
....等....


#  grep " 78.100.168.192.in-addr.arpa" /tmp/xx2.txt
...
13:46:58.231168 IP (tos 0x0, ttl  64, id 10721, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.27561 > 192.168.dns1.com.53: [bad udp cksum 5522!]  9882+ PTR? 78.100.168.192.in-addr.arpa. (45)
13:50:21.600292 IP (tos 0x0, ttl  64, id 17482, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.51607 > 192.168.dns2.com.53: [bad udp cksum 41de!]  3259+ PTR? 78.100.168.192.in-addr.arpa. (45)
13:53:50.367461 IP (tos 0x0, ttl  64, id 29642, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.12386 > 192.168.dns2.com.53: [bad udp cksum e5bc!]  51020+ PTR? 78.100.168.192.in-addr.arpa. (45)
13:57:10.908366 IP (tos 0x0, ttl  64, id 33575, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.46524 > 192.168.dns2.com.53: [bad udp cksum 6e4a!]  46185+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:00:41.171634 IP (tos 0x0, ttl  64, id 47230, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.13441 > 192.168.dns2.com.53: [bad udp cksum 96ea!]  38268+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:04:03.672077 IP (tos 0x0, ttl  64, id 53122, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.45322 > 192.168.dns1.com.53: [bad udp cksum b43b!]  51161+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:07:28.770941 IP (tos 0x0, ttl  64, id 61613, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.48435 > 192.168.dns1.com.53: [bad udp cksum e22c!]  51842+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:10:52.191144 IP (tos 0x0, ttl  64, id 2889, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.12000 > 192.168.dns1.com.53: [bad udp cksum fe3a!]  19130+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:14:18.685992 IP (tos 0x0, ttl  64, id 12776, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.41413 > 192.168.dns2.com.53: [bad udp cksum 52c5!]  19836+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:17:43.471740 IP (tos 0x0, ttl  64, id 20954, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.60719 > 192.168.dns1.com.53: [bad udp cksum b40!]  34653+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:21:04.333640 IP (tos 0x0, ttl  64, id 25208, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.60793 > 192.168.dns1.com.53: [bad udp cksum 1910!]  46853+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:24:31.149256 IP (tos 0x0, ttl  64, id 35415, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.29278 > 192.168.dns2.com.53: [bad udp cksum 147c!]  50721+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:27:53.503998 IP (tos 0x0, ttl  64, id 41162, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.16994 > 192.168.dns1.com.53: [bad udp cksum c5c7!]  43632+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:31:26.386776 IP (tos 0x0, ttl  64, id 57437, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.63623 > 192.168.dns1.com.53: [bad udp cksum acf0!]  52067+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:35:02.562995 IP (tos 0x0, ttl  64, id 11469, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.40847 > 192.168.dns1.com.53: [bad udp cksum 8e73!]  41338+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:38:29.945939 IP (tos 0x0, ttl  64, id 22244, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.64566 > 192.168.dns2.com.53: [bad udp cksum 918e!]  10700+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:41:41.622086 IP (tos 0x0, ttl  64, id 17312, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.48216 > 192.168.dns1.com.53: [bad udp cksum 5ba3!]  21732+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:45:17.195075 IP (tos 0x0, ttl  64, id 36277, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.39889 > 192.168.dns2.com.53: [bad udp cksum 83fa!]  7743+ PTR? 78.100.168.192.in-addr.arpa. (45)
14:48:52.259520 IP (tos 0x0, ttl  64, id 54734, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.40490 > 192.168.dns2.com.53: [bad udp cksum 21b1!]  25928+ PTR? 78.100.168.192.in-addr.arpa. (45)

--//可以發現間隔大約不到2XX秒,就存在1個IP反向解析.
--//注:生產系統存在2個DNS服務.

create table t ( a timestamp);
insert into t values ('2018/04/28 13:46:58.231168');
insert into t values ('2018/04/28 13:50:21.600292');
insert into t values ('2018/04/28 13:53:50.367461');
insert into t values ('2018/04/28 13:57:10.908366');
insert into t values ('2018/04/28 14:00:41.171634');
insert into t values ('2018/04/28 14:04:03.672077');
insert into t values ('2018/04/28 14:07:28.770941');
insert into t values ('2018/04/28 14:10:52.191144');
insert into t values ('2018/04/28 14:14:18.685992');
insert into t values ('2018/04/28 14:17:43.471740');
insert into t values ('2018/04/28 14:21:04.333640');
insert into t values ('2018/04/28 14:24:31.149256');
insert into t values ('2018/04/28 14:27:53.503998');
insert into t values ('2018/04/28 14:31:26.386776');
insert into t values ('2018/04/28 14:35:02.562995');
insert into t values ('2018/04/28 14:38:29.945939');
insert into t values ('2018/04/28 14:41:41.622086');
insert into t values ('2018/04/28 14:45:17.195075');
insert into t values ('2018/04/28 14:48:52.259520');
commit;

column interval format 00000.999999

WITH x
     AS (SELECT a - n_a interval
           FROM (  SELECT a, LAG (a) OVER (ORDER BY a) n_a
                     FROM t
                 ORDER BY a)
          WHERE n_a IS NOT NULL)
SELECT   EXTRACT (DAY FROM interval) * 86400
       + EXTRACT (HOUR FROM interval) * 3600
       + EXTRACT (MINUTE FROM interval) * 60
       + EXTRACT (SECOND FROM interval)
          interval
  FROM x;

  INTERVAL
----------
203.369124
208.767169
200.540905
210.263268
202.500443
205.098864
203.420203
206.494848
204.785748
200.8619
206.815616
202.354742
212.882778
216.176219
207.382944
191.676147
215.572989
215.064445
18 rows selected.

3.測試2:
--//我還測試scan ip,vip,真實IP的登入.
--//結果都是一樣,都是間隔大約不到2XX秒,就存在1個IP反向解析.
 
4.如果client ip能反向解析呢?
--//修改DNS伺服器,加入192.168.100.78的反向解析.
# cat /var/named/100.168.192.db
$TTL    86400
100.168.192.in-addr.arpa.       IN      SOA     xxxx.com. root 1 3H 15M 1W 1D

          IN NS    ns.xxxx.com.
..
78        IN PTR    gxqyydg4.com

# service named restart
Stopping named: .                                          [  OK  ]
Starting named:                                            [  OK  ]

$ rlsql   system/welcome1@dm01-scan:1521/dbcn::dbcn1
SYSTEM@dm01-scan:1521/dbcn::dbcn1> select INSTANCE_NUMBER, INSTANCE_NAME from v$instance ;
INSTANCE_NUMBER INSTANCE_NAME
--------------- ----------------
              1 dbcn1

SYSTEM@dm01-scan:1521/dbcn::dbcn1> select sysdate from dual ;
SYSDATE
-------------------
2018-04-28 15:41:00
...

SYSTEM@dm01-scan:1521/dbcn::dbcn1> select sysdate from dual ;
SYSDATE
-------------------
2018-04-28 15:50:23

#  grep " 78.100.168.192.in-addr.arpa" /tmp/xx2.txt | grep ^15:4
15:43:46.436878 IP (tos 0x0, ttl  64, id 6575, offset 0, flags [DF], proto: UDP (17), length: 73) 192.168.xxxxxx.com.23866 > 192.168.dns1.com.53: [bad udp cksum 118d!]  51788+ PTR? 78.100.168.192.in-addr.arpa. (45)

--//可以發現只要反向解析正常,僅僅解析1次反向IP解析,以後就不再請求.而且會快取一段時間,以後登入也不會出現反向請求.

總結:
#  grep -v 'in-addr.arpa.' /tmp/xx2.txt |wc
   1331   27999  210832
#  grep  'in-addr.arpa.' /tmp/xx2.txt |wc
  82971 2324151 17353436

--//大部分都是反向解析.
--//如果4400個客戶端登入.假設220秒存在1次反向ip解析. 4400/220 = 20個/秒,平均每秒要從伺服器發出20個請求,如果業務高峰每秒
--//200個連線請求,也就是每秒200次解析.這樣業務要求並不大,大部分dns伺服器都能撐得住,但是一旦出現問題,整個應用就出現停滯,
--//建議還是建立多個DNS,避免單點故障.

--//至於是否加入client 反向IP解析,可以減少DNS的請求,效益並不大,但是要注意DNS伺服器網路頻寬以及效能,建議還是考慮建立多臺
--//dns伺服器.

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/267265/viewspace-2153532/,如需轉載,請註明出處,否則將追究法律責任。

相關文章