关于dns的详细解析请看下面网址:
http://yuelei.blog.51cto.com/202879/106228
下面是dns srv比较好理解的解答:
DNS SRV 资源记录
SRV 记录是一个域名系统 (DNS) 资源记录,用于标识承载特定服务的计算机。
DNS SRV资源记录用于给出在某域中实现某种服务和协议的服务器地址列表。假设我们需要得到example.com域中支持TCP协议的SIP服务器,这时就可以对_sip._tcp.example.com域进行DNS SRV查询,假设DNS SRV返回如下记录:
Priority Weight Port Target
IN SRV 0 1 5060 icscf1.example.com
IN SRV 0 2 5060 icscf2.example.com
这样就可以得到example.com域中支持TCP方式的两个SIP服务器。下面对SRV记录中的几个域解释一下:
l priority, 给出处理的顺序,按照priority从小到大的顺序对记录搜索,搜索到匹配的记录后,就停止搜索priority值更大的记录,对于拥有相同priority的记录将通过weight再次选择;
l weight, 对于拥有相同priority的多条记录,weight给出了选择某条记录的几率,值越大,被选中的概率就越大,合理的取值范围为0-65535;
l port, 目标机器提供对应服务的端口;
l target, 目标机器的域名;
下面再用一个例子来介绍一下怎样通过weight来选择拥有相同priority的多条记录,假设有四条记录A,B,C,D,其weight分别为120,70,95,0,其过程如下:
1. 将weight为0的记录排在最前面,其他记录顺序任意,那么现在的顺序可以是DABC;
2. 每一个记录取一个加权值,该值等于前面所有记录(包括自己)的weight总和,那么D为0,A为120,B为190,C为285;
3. 再计算出所有weight的总和,120+70+95+0=285,并随机出一个在0到285之间(包括0和285)的随机数;
4. 将随机值按照DABC的顺序和各加权值比较,当出现随机值小于等于加权值时停止比较,该加权值所对应的记录就为本次选中的记录;
通过上述方法可以选出一条可用的记录,如果还需要再选出一条,可以将选出的记录从列表中删去,然后再按步骤2到步骤4进行一次即可。
例子:
要验证域控制器的 SRV 定位器资源记录,可以使用 Nslookup 命令:
Nslookup 是一个命令行工具,它显示的信息可以用来诊断域名系统 (DNS) 的基础结构。
要使用 Nslookup 来验证 SRV 记录,请按照下列步骤操作:
1. 在 DNS 上,单击“开始”,然后单击“运行”。
2. 在“打开”框中,键入 cmd。
3. 键入 nslookup,然后按 Enter。
4. 键入 set type=all,然后按 Enter。
5. 键入 _xmpp-server._tcp.ioio.name,其中 ioio.name 为域名,然后按 Enter。
Nslookup 将返回显示为以下格式的一个或多个 SRV 服务位置记录:
负载均衡技术能够平衡服务器集群中所有的服务器和请求应用之间的通信负载,根据实时响应时间进行判断,将任务交由负载最轻的服务器来处理,以实现真正的智能通信管理和最佳的服务器群性能,从而使网站始终保持运行和保证其可访问性。
为了充分利用现有服务器软件的种种优势,负载均衡最好是在服务器软件之外来完成。而最早使用的负载均衡技术是通过DNS服务中的随机名字解析来实现的。这就是通常所说的DNS负载均衡技术。
DNS负载均衡技术的实现原理是在DNS服务器中为同一个主机名配置多个IP地址,在应答DNS查询时,DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果,将客户端的访问引导到不同的机器上去,使得不同的客户端访问不同的服务器,从而达到负载均衡的目的。
直到现在,很多网站仍然使用DNS负载均衡来保证网站的运行和可访问性。从其实现和效果来看,主要有以下优缺点:
主要优点
这种技术的主要缺点如下:
第一,技术实现比较灵活、方便,简单易行,成本低,适用于大多数TCP/IP应用。不需要网络专家来对之进行设定,或在出现问题时对之进行维护。
第二,对于Web应用来说,不需要对代码作任何的修改。事实上,Web应用本身并不会意识到负载均衡配置,即使在它面前。
第三,Web服务器可以位于互联网的任意位置上。
主要缺点
DNS负载均衡技术在具有以上优点的时候,其缺点也非常明显,主要表现在:
第一,不能够按照Web服务器的处理能力分配负载。DNS负载均衡采用的是简单的轮循负载算法,不能区分服务器之间的差异,不能反映服务器的当前运行状态。所以DNS服务器将Http请求平均地分配到后台的Web服务器上,而不考虑每个Web服务器当前的负载情况。如果后台的Web服务器的配置和处理能力不同,最慢的 Web服务器将成为系统的瓶颈,处理能力强的服务器不能充分发挥作用。不能做到为性能较好的服务器多分配请求,甚至会出现客户请求集中在某一台服务器上的情况。
第二,不支持高可靠性,DNS负载均衡技术没有考虑容错。如果后台的某台Web服务器出现故障,DNS服务器仍然会把DNS 请求分配到这台故障服务器上,导致不能响应客户端。
第三,可能会造成额外的网络问题。为了使本DNS服务器和其他DNS服务器及时交互,保证DNS数据及时更新,使地址能随机分配,一般都要将DNS的刷新时间设置的较小,但太小将会使DNS流量大增造成额外的网络问题。
第四,一旦某个服务器出现故障,即使及时修改了DNS设置,还是要等待足够的时间(刷新时间)才能发挥作用,在此期间,保存了故障服务器地址的客户计算机将不能正常访问服务器。
总结
从上面的总结我们可以看出,总体来说,DNS负载均衡技术方案不应该算是真正意义上的负载均衡,不能够稳定、可靠、高效地满足企业对Web服务器的需求,也不能满足网络用户对网站访问的及时响应和可用性,所以现在很多Web站点方案中,已经很少采用这种方案了。