目标
了解BIG-IP DNS系统智能解析的重要要素
4.1、智能解析
GSLB（global server load balancing）在程序中添加了智能解析的特点，直接返回给客户最好的解析结果。比如BIG-IP DNS 可以使用基于拓扑负载均衡（topology-based load balancing）的能力去检查用户的LDNS ip，从而给予他们最优解析结果。持久性（persistence）的特点让用户持续解析同一个ip地址。监控（monitor）可以检查监控健康状况、可用性和虚拟服务的性能等指标，监控还可以收集纳管LTM上vs的详细状态，从而计算出最优解。代理（probe）可以监控LDNS和部署了BIG-IP的数据中心的路径，度量值（metrics）收集完成之后，这些数值将分享到同步组中的所有BIG-IP DNS系统中，让每一个DNS系统都使用相同标准做计算。
在描述智能dns之前需要先了解一下网络拓扑中的组件及功能。
网络拓扑元素
- 数据中心（data centers）
- 链路（links）
- 服务器（servers）
数据中心是一个逻辑单位，你可以将多个dns放入同一个数据中心中，这样在收集数据的时候就会选择数据中心中的一个设备去检测，并同步到整个组内，在这个逻辑数据中心中，我们可以关联链路和服务器，链路就是通往运营商的物理线路或者是链接其他数据中心和本数据中心的线路，一个数据中心可以有多条线路，服务器是数据中心的成员，服务器是virtual servers的载体，可以是F5的设备，也可能是其他品牌的设备，还可以是一个独立的服务器，这些信息都需要手工配置。
逻辑网络元素
- 虚拟服务器（virtual servers）
- 池（pools）
- 宽ip（wide ip）
virtual servers就是一个ip:port的组合，代表server上的一个服务，这个ip地址就是智能dns的可选解析地址。他可能跑在F5的LTM上，也可能跑在非F5的设备上，还有可能是一个独立的服务器，比如IIS或者数据库服务。pool是virtual servers的集合，wide ip是FQDN，他可以关联了一个或者多个pool。
一般情况下，GSLB能力是为一个特定的FQDN提供ip。GTM只能提供A、AAAA或者CNAME的响应类型。BIG-IP dns 扩展能力可以提供CNAME、MX、SRV和NAPTR的响应类型，基于此，你可以给诸如手机网络做一些配置一提供更近，更快的服务响应。
4.2、Wide IP
Wide ip是做智能dns的要素，是配置智能dns的第一位的要素。Wide ip将匹配到的FQDN绑定到一个或者多个虚拟服务上，当一个LDNS将解析请求发送到一个Wide ip上时，wide ip将会检测哪个虚拟池有资格响应这个请求，并配合负载算法进行选择虚拟池。
Wide IP有两次负载规则的计算，第一次先选择最优的pool，第二次选择pool中最优的virtual server，然后将virtual server作为最优解回复给客户端。
Big-IP系统使用监控（monitor）和探测器（probe）去监测pool和virtual server的可用性和性能，以此数据作为选择标准。
监控（monitor）和探测器（probes）
监控将会直接或者间接的方式进行检测（间接可能是通过snmp进行检测），如果检测失败，dns就会放弃解析到这个地址。
探测器用于数据中心和客户端LDNS之间进行检测，默认是没有配置的，你需要进行配置。探测器的配置很灵活，可以去除特定LDNS的探测。
4.3、数据中心（data center）
逻辑关系
data center是server的集合，一个server只能关联一个data center。server是virtual server的集合。
配置data center的时候，name信息为必填，可选的是location、contact等。
实验
为智能解析创建一个data center
GUI
路径：DNS ›› GSLB : Data Centers : Data Center List
配置：
- Name：training_dc
- Description：seattle
- Contact：administrator
TMSH
用相同方式创建alternate_dc，位置london。
预期结果：
创建完成之后应该全都是蓝色方块，因为没有数据中心中还没有可用的server。
4.4、服务器（server）
server的设备种类
- BIG-IP DNS
- BIG-IP LTM
- Non-F5 server
4.4.1配置一个BIG-IP DNS系统作为服务器
BIG-IP DNS 系统有两个作用，一个是智能解析，另一个是个收集度量值。当你添加了一个BIG-IP作为一个服务器（server），并且关联了数据中心的时候，你就已经将其配置成探测器，它可以收集并同步度量值到其他BIG-IP DNS 系统中。
你需要配置如下参数：
- F5设备的名字，ip，关联的数据中心
- 首选探测器和备选探测器
- 数据同步方式
- 是否自动发现virtual server
- 是否自动发现link
如果这个server在一个nat服务器后边，你需要知道nat之后的地址和nat之前的地址，在上图中，Address位置填写的是nat之后的地址（公网地址），Translation填写的是nat之前的地址（内网地址）。
实验
添加一个Big-IP DNS 作为server
GUI
路径：DNS ›› GSLB : Servers : Server List ›› New Server…
配置：
- Name：seattle_dns_server
- Product：BIG-IP System
- Data Center：training_dc
- BIG-IP System Devices：Device Name：gtm.com Address：10.10.10.13
- Health Monitors：bigip
TMSH
预期效果
图形界面应该显示一个绿色圆圈，表示识别成功。注意这里的ip地址必须为self ip，不能使用Management ip，否则无法实现自动发现功能。
4.4.2配置一个BIG-IP LTM系统作为服务器
LTM是F5设备中的一个功能，但LTM不仅能作为F5的负载均衡设备，同样可以用作DNS场景中的server，如果将LTM接入到DNS系统中，我们可以使用额外的一些功能，比如可以让LTM提供virtual server的状态和数据中心到LDNS的度量值信息。
你需要配置如下参数：
- F5设备的名字，ip和关联的数据中心，如果LTM有故障转移功能，你需要添加所有的LTM到server中。v13版本支持添加8个LTM在同一个设备组。早期版本支持2台
- 一个探测器池和健康检查
- LTM和GTM数据同步方式
- 是否需要自动发现virtual servers
- 是否自动发现link
LTM和GTM之间有nat设备
如下图，中间有个防火墙做了nat配置，在添加server的时候DNS配置中的Address需要配置成nat后的202.168.1.31，而Translation需要使用nat之前的ip10.10.1.31。virtual server也同理。
virtual server的配置方式有两种，一种是自动发现，一种是手工配置，但是如果LTM和GTM之间有NAT，简言之，就是你的配置中使用了Translation，你就没法使用自动发现了。如果想使用自动发现，需要避免nat在这里干扰。
实验
添加一个Big-IP LTM 作为server
GUI
路径：DNS ›› GSLB : Servers : Server List ›› New Server…
配置：
- Name：london_ltm17_server
- Product：BIG-IP System
- Data Center：alternate_dc
- BIG-IP System Devices：Device Name：ltm.com Address：10.10.17.13
- Health Monitors：bigip
- Virtual Server Discovery：enabled
TMSH
预期效果
当建立完成后，你在DNS ›› GSLB : Servers : Server List界面看到的应该是蓝色方块图标，状态时unknow，Virtual Servers的数量应该为0个，虽然你的ltm上有两个可用的vs，但是他也发现不了，因为GTM和LTM之间还没有建立起iQuery的会话。
4.4.3建立iQuery会话
iQuery基础
当BIG-IP DNS 系统和其他系统，比如LTM的建立连接的时候，他们需要使用F5私有的协议，iQuery进行交互数据。使用的代理程序做big3d，他监听tcp 4353端口，并且使用ssl对交互的数据进行加密。在iQuery会话建立之前，BIG-IP DNS系统需要和每一个serve设备交换SSL证书，证书交换是由一个叫bigip_add的脚本执行完成的。如果证书错误或者不在有效期，则不能建立iQuery会话，默认自签名证书是3650天，如果手工更新证书，默认更新有效时间为365天，需要手工调整成3650天。
bigip_add脚本需要在每次有新BIG-IP系统加入到组织中的时候执行一下。脚本会将本地BIG-IP DNS 系统的SSL证书追加到对端/config/big3d/client.crt认证列表中，将对端SSL证书添加到本地的/config/gtm/server.crt认证列表中。
命令：
iQuery排错
你可以使用LINUX bash下的iqdump命令进行排错。
如果建立成功，iqdump会回显XML的信息，如下图。
big3d agent
big3d运行在所有的BIG-IP系统中，收集性能信息，持续监控BIG-IP系统，并提供智能解析的ip是否可用，同时他还监控LDNS到域名所在数据中心的路径，一旦收集足够的数据，他就会同步到所有的BIG-IP DNS系统中。
big3d收集的信息：
- 网络路径来回时间
- 路径丢包数量
- 路径上的跳数
- server的性能
- virtual server的可用性和性能
在使用big3d的时候，需要确保版本一样，你可以使用big3d_install进行交互式安装。
在使用big3d_install的时候，证书交换如下图所示：
- 本地BIG-IP DNS 系统的SSL证书拷贝到对端/config/big3d/client.crt认证列表中。
- 对端SSL证书将会添加到本地的/config/gtm/server.crt认证列表中。
命令：
实验
延长证书时长
GUI
路径：System ›› Certificate Management : Device Certificate Management : Device Certificate >> renew
配置：
- Common Name：gtm.com
- Lifetime：3650
建立iQuery会话
网页和tmsh都没法处理这一步，需要在LINUX bash上执行bigip_add
LINUX bash
注意： 在配置的过程中，有可能网络之间有防火墙或者nat，需要对这些设备进行配置，可以使用telnet来确定是否通畅，同时要注意，F5的接口默认是被限制的，需要放通tcp 4353端口，如果由于密钥失效导致无法建立，也可以清除/root/.ssh/known_hosts的相关条目。
iQuery排错
LINUX bash
预期结果
在执行bigip_add之后会输入密码，如果加入成功会出现done的回显，london_ltm17_server的状态会从unknown变成available，图标会从蓝色方块变成绿色圆圈，这表明iQuery会话建立完成，同时看到virtual servers显示为2，表明自动发现成功，如下图。
在使用iqdump的时候，会看到等数据，这表明已经成功传输数据。
如果建立不起来iQuery会话，可能是由于ssh会话建立不起来，我们可以使用rm /root/.ssh/know_hosts清除一下，再重试bigip_add，还有可能是4353端口没有开放，我们需要在Network ›› Self IPs的位置放开4353端口，并通过telnet检查是否开通成功，当然还有可能是证书失效，我们需要更新证书并重试bigip_add。
如果是自动发现不成功，可能由于你在配置DNS服务器作为server的时候，使用了Management ip进行会话的建立。
4.4.4配置一个非F5设备作为server
有的时候vs并不是通过F5负载均衡进行暴露的，而是一个真实的服务器或者其他品牌的负载均衡，但不论如何提供服务的，我们都可以将其添加到server中。
你需要配置如下参数：
- server名字，ip，位置
- 健康检查
- server上的virtual server
实验：
添加一个非F5的设备
GUI
路径：DNS ›› GSLB : Servers : Server List ›› New Server…
配置：
- Name：seattle_host1_server
- Product：Generic_Host
- Address List：172.16.20.3
- Data Center：training_dc
- Health Monitors：tcp
- Virtual Server Address：172.16.20.3
- Virtual Server Port：80
预期结果：
添加完成之后，需要等几分钟，server和virtual server图标会变成绿色圆圈，即为成功。
4.4.5定义链路（links）和路由转发器（routers）
links是连接数据中心和互联网的链路，BIG-IP DNS 跟踪链路的性能，链路性能直接影响后端池、数据中心， wide ip和分布式应用的可用性。big3d收集和分析链路的属性，这些数据用于智能dns选路的依据，如果带宽不一样，你还可以使用权重来定义多条链路的承载量。
如果数据中心只有一个链路，就不需要去配置他了，如果有多个链路，你需要配置，因为他可以被监控，监控数据将会影响解析结果。
链路监控
种类：
- bigip_link：这种监控获取一些数据，比如吞吐，而不仅仅是链路up/down状态，这种数据是从TMM的mcpd进行获得。
- gateway_icmp：使用ICMP协议进行监控，可以使用gateway_icmp去监控一个池子中的成员，从而监测可用性。
4.4.6wide ip pool
池子代表的是一个或者多个虚拟服务（virtual server）的集合，虚拟服务就是一个ip:port。只有预先被定义好的或者被自动发现的virtual server才能被调用。一个virtual server可以属于多个pool，一个pool可以被一个或多个wide ip调用。
wide ip pool参数
可用的类型（tpye）：
- A
- AAAA
- CNAME
- MX
- NAPTR
- SRV
三个层级的负载均衡：
- preferred（首选）
- alternate（备用）
- fallback（回退）
默认使用preferred，只有当preferred不能选择出一个有效的结果的时候，才会使用alternate的算法，比如，preferred使用RTT算法的时候，LDNS发送了一个请求，但是检测数据还没有收集完路径数据，则会使用alternate，alternate尽量静态算法，比如轮询、权重等。如果alternate也没能计算出一个有效结果时候，则会使用fallback算法，fallback算法是不会关心解析结果是否可用，他只是回复一个结果而已。相关算法会在后续详细介绍。
配置TTL：
默认30s，你可以手工修改ttl，他将会作为dns解析的ttl值。
Fallback Ip Address：
使用后备 ip 可防止将查询传递到本地 BIND。通常在没有开启BIND的时候使用后备ip地址。
Dynamic Ratio：
在使用动态负载的情况下，由于收集度量值需要一些时间，在这段时间内，解析的结果可能会是相同的ip地址，这造成了流量不均衡，为了避免这种情况，我们可以是用动态权重（dynamic ratio），当开启了这个能力，他会将部分流量分担到次优ip上。
可以使用dynamic ratio算法有：
- Round Trip Time
- Vs Score
- Completion Rate
- Hops
- Kilobytes/Second
- VS Capacity
- Quality of Service
- Least Connections
返回多个解析：
默认BIG-IP直接一个最优的结果，你可以使用Maximum Answers Returned回复最多500个最优解。
Verify Member Availability：
正常情况下，wide ip只解析monitor健康检测成功的ip，如果你有某些需求，不关心健康检测结果，你可以去掉Verify Member Availability的对勾选项，这样他会使用所有pool中的virtual server。
实验
创建一个wide ip pool
GUI
路径：DNS ›› GSLB : Pools : Pool List ›› New Pool…
配置：
- Name：train10_http1_pool
- Type：A
- Member List：列表中勾选
TMSH
预期结果
我们可以使用show gtm pool a train10_http1_pool detail命令进行查看，会发现他们的状态都是可用的（available），其中两个london的vs是通过bigip获得的健康检查结果，seattle的vs是通过tcp监控获得的健康检查结果。
4.4.7 配置 Wide IP
可用的类型（tpye）：
- A
- AAAA
- CNAME
- MX
- NAPTR
- SRV
一般情况，wide ip一般关联1-2个pool，pool的类型需要和wide ip的类型是一致的。
如图，www.f5.com是解析结果是一个A记录，使用轮询的负载均衡算法，关联了一个pool，这个pool包含三个virtual server，分别是216.34.94.32、192.65.100.106、207.17.117.20，当被请求时候，会通过二次负载的算法找到一个最优解，第一次是通过wide ip 找最优pool，第二次是从pool中找最优vs。
Wide ip参数：
Name：
Wide IP 的name是必须参数，这个就是你想要智能解析的dns域名，你可以使用通配符在wide ip name中，*代表多个字符，？代表单个字符，这可以帮你减少别名的数量。举个例子，www.f5.com是最精确的请求，智能匹配到www.f5.com这个域名，而ww?.f5.com可以匹配到www1.f5.com和wwa.f5.com，*.f5.com则可以匹配到以f5.com结尾的所有域名。
Alias：
别名，如果配置了别名，则在匹配到别名的时候使用关联的wide ip策略进行解析，如果其他的wide ip和别名同时可以处理一个请求，则会优先按照wide ip的策略进行处理。
Load Balancing Method：
wide ip一般会关联多个pool，这里的负载均衡策略是针对第一次wide ip进行pool选择时候配置的。
Persistence：
持久性功能，当开启，相同的源地址将会解析到同一个解析记录，这适用于有状态应用，可以配置TTL用于配置时间，同时可以针对ip地址范围进行持久性配置。
Last Resort Pool：
只有在所有pool都不能使用的情况下，才会启用Last Resort Pool，这个pool通常配置致歉服务器。
在使用Last Resort Pool的时候，你需要注意wide ip关联的pool不能使用Return to DNS作为fallback负载均衡的策略，否则不能生效。
实验
创建一个wide ip
GUI
路径：DNS ›› GSLB : Wide IPs : Wide IP List ›› New…
配置：
- Name：www.train10.com
- Type：A
- Pool List：train10_http1_pool
TMSH
测试
当使用dig +short @10.10.10.50 www.train10.com进行请求的时候，他会在pool其中使用配置的轮训方式进行交替响应，但是这个轮询结果也取决于你的cpu个数，因为每一次响应都是由一个cpu进行的处理，轮训算法也是基于当前cpu做的，所以假设F5有4个cpu，你访问的前四次可能都是一个结果。因为这四次被四个不同cpu处理。
在Statistics ›› Module Statistics : DNS : GSLB ›› Pools : train10_http1_pool : A中，可以看到每一个请求都是被preferred负载算法处理了，使用的是pool配置好的轮询算法。
配置完别名，比如*.abc.com，则使用dig +short @10.10.10.50 wwws.abc.com进行解析，会发现解析结果和www.train10.com的解析结果是一样的。但是w.asd.com是不能解析的，因为匹配不到wide ip或者别名。
4.4.8状态信息和统计信息
