Transcript 日志检查及排错 - CNadn 应用交付学习之路

GTM Essentials
Prepared and presented by:
LinJing
V1.0
www.myf5.net
2
Updates
Version
Date
Description
Author/Eidt
V1.0
2010/3/27,28
Original
Lin Jing
V1.1
2010/4/17
Correct
p40/41,about
syncronization
linjing
V1.2
201/06/22
P39.Add a case
about private
address of vs
LINJING
3
说明
• 该PPT适合对GTM/LTM已经有一定基础同学
• 如无GTM知识，建议首先阅读metoo的GTM安
装指南-V2.0—bible啊，下面连接是v1.0
• http://www.adntech.com/bbs/viewthread.ph
p?tid=375&highlight=GTM
• 请到www.adntech.com/bbs上查找v2.0版本
• 错别字请自行纠正
• 本文不是bible，F5软件日新月异，可能部分内容
需基于指定版本
• 问题请在帖子下指出并讨论，感谢
4
GTM关键点
 GTM中的对象关系
 Listener决策策略
 证书交换机制
 Add new GTM to sync group八步法
 iquery结构关系
 gtmd、big3d的选举
 Monitor及path metric collection
 私有地址server情形下的NAT处理
 Named.conf,zone,wideip.conf,persistence的同步
 ZoneRunner & BIND
 GTM配置十步法
 日志检查及排错
5
GTM中的对象关系
•
•
•
•
•
•
Virtual server
Server
Datacenter
Pool
Wideip
Link
6
GTM中的对象关系
• vs：GTM中的最小object，逻辑组织在server和pool中，
其IP即为GTM最终提供解析的结果
• Server：用来代表一个server实体，类似于LTM中的node，
有bigip server，non-bigip server 两类，隶属于
datacenter中，同一server不应同时存在于两个
datacenter中。
• Datacenter：组织server的容器，表述一个具体的数据中
心
• Link:表述datacenter中的链路，与DC关联
• Pool:用来组织vs，是wideip的配置要素，同一vs可以同
时属于多个pool
• Wideip：对外呈现的智能域名，其下包含pool
7
Listener决策策略
• Listener可以是selfip，floating-selfip或独立地址
• 当listener为独立地址时，在node模式下永远都不
会把请求交给BIND （GTM中的named进程）
• 当listener为selfip或floatingip时，请求由TMM交给
gtmd，如果无match域名，则交给BIND （GTM中
的named进程）
• 当listener为空或独立地址时，如果DNS解析包的
目的地址是selfip，那么GTM上的TMM直接把该请
求转给BIND（GTM中的named进程）
8
Listener决策策略
• 如果listener地址是self ip，意味着listener配置不
能在HA间同步，此时的listener配置存在于
bigip_local.conf中，且unit id=0
# cat bigip_local.conf
virtual address 10.4.10.253 {
floating disable
unit 0
}
virtual vs_10_4_10_253_53_gtm {
destination 10.4.10.253:domain
ip protocol udp
translate address disable
translate service disable
profile dns udp
}
[root@gtm2:Active] config #
9
Listener决策策略
• 如果listener地址是floating ip或独立IP，意味着该
listener配置可以在HA pair间同步
•
BIG-IP Self IP Address:
self 10.4.10.253 {
netmask 255.255.0.0
vlan External
allow default
}
•
The GTM listener Virtual Address:
virtual address 10.4.10.190 {
}
•
The GTM listener Virtual Server:
virtual vs_10_4_10_190_53_gtm {
destination 10.4.10.190:domain
ip protocol udp
translate address disable
translate service disable
profile dns udp
}
10
Listener决策策略 Best Practics
• 单机环境，配置为self ip
• 双机环境（GTM module），但只有一个机器上存在
gtm模块，那么使用该机器的selfip
• 双机环境，两机均有GTM,但只希望active unit提
供解析，使用floating ip 或独立 ip
• 双机环境，两机均有GTM，但希望GTM module同
时提供解析，使用各自的self ip
11
证书交换机制 F5的证书
• 每一台F5设备都拥有其自己的device certificate，
存放于/config/httpd/conf/ssl.crt/server.crt，当使用
https管理F5时候浏览器获得的证书即为该证书
• GUI界面system—device certificates下的device
certificate界面可以显示该证书
• 默认情况下该证书的有效期是一年！
• 在LTM/GTM上，/config/big3d/client.crt 中存放的
是与其他机器使用SSL通信时要出示的client证书
• 在GTM上，/config/gtm/server.crt存放的是GTM与
其他机器使用SSL通信时要出示的server证书
12
证书交换机制 F5的证书- Cont.
•
•
•
•
缺省情况下，以上三个位置的证书完全相同
cat /dev/null > /config/gtm/server.crt
cat /dev/null > /config/big3d/client.crt
上面两个命令可以将两个证书内容恢复为缺省内
容（=http的证书）
• /config/gtm/server.crt = GUI上 Global Traffic—
servers—trusted server certificates
• /config/big3d/client.crt = GUI上 system—device
certificates –trusted device certificates
13
证书交换机制
• 为什么要交换证书？
---为了F5的设备间通信 iquery！
• 有三个命令可以交换F5间的证
书:bigip_add,big3d_install,gtm_add
• 以上三个命令应在GTM上执行
• bigip_add 只用来同步证书
• big3d_install 推送big3d程序给对方+同步证书
• gtm_add 拉对方配置到本机+同步证书+将自己
加入gtm同步组
14
证书交换机制 ： bigip_add
• 在GTM上运行，使用SSH协议和scp命令
• 检查wideip.conf中所有类型为bigip的server
• 将自己的device certificate推送到其他bigip上的
/config/big3d/client.crt中
• 将所有其他bigip的device certificate拉到自己的
/config/gtm/server.crt中
• 可以重复执行，但是多次运行会导致
client.crt,server.crt中包含重复证书。未必是问题，
但会很乱。
• 可以在命令后指定对方F5设备地址，此时将只和
该设备交换证书
15
证书交换机制 ： big3d_install
• 在GTM上运行，使用SSH协议和scp命令
• 如果环境中各个F5设备的软件版本不一样，那么
必须保证big3d程序的版本一致，因此该命令可以
同步big3d程序
• 检查wideip.conf所有bigip类型的server，向其推送
自己系统上的big3d程序
• 执行和bigip_add一样的证书拷贝过程
• 如果目标的big3d版本相同或更高，则会跳过
• 可以在命令后指定对方F5设备地址
16
证书交换机制 ： gtm_add
• 在一台没有配置的GTM上执行
• 执行前应确保在远端GTM上已将该new GTM作为
bigip server加入到datacenter中
• 清除本地wideip.conf及zone配置，拷贝远端GTM
上的配置（wideip，named，zone）到本地
• 将自己加入到sync group中，因此这台new gtm的
初始配置只要配好网络即可，但需注意listener是
否在同步范围内
• 同步证书
17
证书交换机制 ： gtm_add 做了什么？
• 备份/config/gtm/server.crt ->server.backup
• 将远端GTM的device certificate拷到自己的
client.crt的顶部中
• 将自己的device certificate拷贝到远端GTM的
/config/gtm/server.crt及/config/big3d/client.crt中
• 与远端GTM建立iquery
• 拷贝远端的/config/gtm/server.crt整个文件覆盖本
地的/config/gtm/server.crt
• 使用sync_zone,syncer同步named wideip zone
完了吗？
18
证书交换机制 ： gtm_add 做了什么？Cont.
• New GTM 的device证书还没有传给那些LTM设备!
• 事实是：做完gtm_add后，ltm设备上的
/config/big3d/client.crt中也会出现new GTM的证
书。 怎么做到的？Gtm_add脚本貌似没有处理这
个过程！
19
证书交换机制:最终的证书结构
• GTM上的/config/gtm/server.crt中有所有其他
GTM或lc/ltm的device证书及自己的device证书
• GTM上的/config/big3d/client.crt中有自己及其他
GTM的device证书
• LTM上的/config/big3d/client.crt中有自己及所有其
他GTM的device证书
• LTM上的/config/gtm/server.crt中只有自己的
device证书
• ！！交换证书，其实只是为了保证有对应的CA!!
20
添加新GTM到同步组中八步法
•
•
•
•
•
Define VLANs
Define Self IPs
Create default route
Define NTP servers
Create new GTM server object on donor
(existing) GTM
• Configure sync group on donor (existing) GTM
• Run gtm_add on CLI of new GTM
• Define the GTM listener on new GTM
21
Certificates related SOL Tips
•
•
•
•
•
•
openssl s_client -tls1 -showcerts -connect <IP address of remote BIGIP>:4353 -cert /config/httpd/conf/ssl.crt/server.crt -verify
/config/gtm/server.crt -key /config/httpd/conf/ssl.key/server.key
在GTM上手工模拟与其他bigip设备进行SSL通信过程
SOL9114 - Creating an SSL device certificate and key pair using OpenSSL
SOL6353 - Updating an SSL certificate on a BIG-IP GTM or Link Controller
system
SOL8187 - Troubleshooting BIG-IP LTM and GTM device certificates
SOL7754 - Renewing self-signed device certificates
SOL4146 - Creating a self-signed certificate that expires in a different value
than the default value of 10 years
22
iquery结构关系
•
•
•
•
正确交换完证书是iquery mesh结构建立的前提
Iquery F5私有协议，使用TCP:4353,V9.2以上版本使用SSL加密通信
实际传输的是gzip压缩的XML block data
Iquery负责bigip间monitor、heartbeat、path metric collection result、
persistence的交换或同步，是各种configurations
（wideip.conf,named.conf,zone）同步的触发者
• Big3d在所有self ip，内部接口包括mgmt 上监听tcp:4353 （udp4353
是3dns时代选项）
• Iquery是gtmd与big3d之间的通信，所以iquery mesh是gtm与gtm，gtm
与ltm（lc）之间的mesh。非gtm之间无需iquery通信（该ppt不讨论WA等
其他设备中的iquery）
23
iquery结构关系
•
•
•
•
•
•
[root@gtm2:Active] config # netstat -na | grep :4353
tcp
0
0 10.30.0.1:4353
0.0.0.0:*
tcp
0
0 127.1.1.1:4353
0.0.0.0:*
tcp
0
0 172.24.18.11:4353
0.0.0.0:*
tcp
0
0 127.2.0.2:4353
0.0.0.0:*
tcp
0
0 127.10.0.0:4353
0.0.0.0:*
LISTEN
LISTEN
LISTEN
LISTEN
LISTEN
24
iquery结构关系
GTM1
GTM2
25
iquery结构关系
•
•
•
•
•
•
[root@gtm2:Active] config # lsof -i -P |grep 4353 | grep -i est
big3d 12744 root 8u IPv4 3850569
TCP 10.30.0.1:4353->10.30.0.1:42933 (ESTABLISHED)
gtmd
12771 root 8u IPv6 3850565
TCP 10.30.0.1:42933->10.30.0.1:4353 (ESTABLISHED)
gtmd
12771 root 9u IPv6 3850799
TCP 10.30.0.1:42950->38.1.1.10:4353 (ESTABLISHED)
gtmd
12771 root 10u IPv6 7490416
TCP 10.30.0.1:49989->38.1.1.11:4353 (ESTABLISHED)
gtmd
12771 root 11u IPv6 3850801
TCP 10.30.0.1:42952->10.30.0.2:4353 (ESTABLISHED)
•
•
•
Red：gtm自己上gtmd和big3d之间的iquery连接
Blue：该gtm与另一dc中的gtm及ltm的iquery连接
Green：该gtm与本dc中的ltm的iquery连接
•
•
[root@ltm2:Active] config # lsof -i -P |grep 4353 | grep -i est
big3d 26130 root 8u IPv4 25628301
TCP 10.30.0.2:4353->10.30.0.1:42952 (ESTABLISHED)
•
结合上一张slide，能看出什么问题吗？
26
iquery结构关系
• Iqdump能证明iquery mesh是否建立好吗？
• 不能。Iqdump执行时，会独立的创建一个连接，它
并不能证明现有的mesh是否正常。
• Iqdump所显示的是对端设备上big3d的广播内容
•
•
•
•
•
•
•
[root@gtm2:Active] config # lsof -i -P |grep 4353 | grep -i est
big3d 12744 root 8u IPv4 3850569
TCP 10.30.0.1:4353->10.30.0.1:42933 (ESTABLISHED)
gtmd
12771 root 8u IPv6 3850565
TCP 10.30.0.1:42933->10.30.0.1:4353 (ESTABLISHED)
gtmd
12771 root 9u IPv6 3850799
TCP 10.30.0.1:42950->38.1.1.10:4353 (ESTABLISHED)
gtmd
12771 root 10u IPv6 7490416
TCP 10.30.0.1:49989->38.1.1.11:4353 (ESTABLISHED)
gtmd
12771 root 11u IPv6 3850801
TCP 10.30.0.1:42952->10.30.0.2:4353 (ESTABLISHED)
iqdump 31986 root 3u IPv6 11179495
TCP 10.30.0.1:57617->10.30.0.2:4353 (ESTABLISHED)
• Iqdump可以证明iquery是否可以建立，可以监听
big3d当前广播的内容
27
gtmd、big3d的选举；Monitor及path
metric
• Monitor是为了监控和探测server
• Monitor获取server及其上VS的可用性以及性能参
数
• Monitor是对内的一种探测，不同于patch metric的
采集，path metric是一种对外探测
• Monitor按照monitor的类型不同，分为bigip型和
host-base型两种探测
• Monitor的实际执行者是big3d进程，但big3d自己
不会主动执行探测，它受gtmd的指使
• Big3d在所有已建立的iquery连接上广播monitor结
果
28
gtmd、big3d的选举
• 众多的big3d和gtmd进程，三个和尚没水吃，谁该
为谁负责，谁该承担实际probe的责任？
• 两个层次的选举：
1，选举gtmd作为负责人
2，选举big3d负责具体的probe工作
以monitor为目的的选举和以patch metric collection
的选举是不同的
选举出的gtmd负责发送probe to指令，而big3d负责
具体的probe工作
29
gtmd、big3d的选举（monitor）-gtmd
的选举
• 被monitor对象所在DC中有无gtmd？
• 》如果有
本DC中是否只有一个gtmd？如果是那么它成为
唯一的负责者；如果多个gtmd，按照算法，依据每
monitor instance为单位分配，每个gtmd都将成为
一部分被monitor 对象的负责者
• 》如果没有扩展到整个sync group执行上述选举过
程。
• gtmd负责发送probe to 指令给big3d.
• 接下来该为每个monitor instance选择一个big3d
agent执行实际的探测工作
30
gtmd、big3d的选举（monitor）-big3d
的选举
• 选举出的每个gtmd都要拥有自己的big3d agent
• Big3d选举分两类，一类是bigip-based类型的monitor，一
类是host-based类型的monitor
• Bigip-based类型，由于该bigip设备上拥有自己的big3d进
程，因此该big3d接受某个gtmd发来的probe to指令，并通
过广播方式发送给所有gtmd
• Host-based类型，首先检查在被探测对象的同DC中是否存
在big3d，如果存在则按照算法选择当前workload最小的一
个big3d；如果不存在则在整个sync group*选择workload最
小的big3d
• 一个monitor instance由哪个big3d执行，不是一成不变的，
根据其workload，是不固定的。但对Non-bigip类型server
可以指定 Statistics Collection Server
31
Monitor及path metric collection
• GTM上的monitor承担着对内服务器的可用性及性
能数据的采集工作
• monitor和patch metric collection是独立的两回事
• 可以在GTM上的以下层面配置monitor：
• Virtual server
• Server
• Pool member
• Pool
• Link
32
Monitor及path metric collection
• 对于这些monitor存在以下逻辑关系：
• server和virtual server 如同LTM上的Node 和pool
member关系
• pool和pool member 如同LTM上的pool和pool
member 关系
• pool 和 server 间是与关系
• 配置重叠的monitor没有任何好处，应仔细处理
monitor间的关系
33
配置monitor的最佳实践
• 不要在virtual server层面定义monitor
• 在server层面定义连通性的monitor方法，例如
gateway_icmp，当然如果是bigip server，一定使
用bigip monitor
• 在pool层面定义针对content或应用的monitor，如
果pool member是来自bigip-based或host-based
的混合，那么可以只在host-based的pool member
上指定对应的monitor，而pool 层面不定义monitor
• 小心部分monitor是关联具体端口的，你的vs或
pool member端口会和这个monitor冲突吗？
34
Monitor及path metric collection
•
•
•
•
•
•
•
•
Patch metric 是dc到ldns之间的metric data，为基于path的LB算法决策提供支
持
仅在使用了path LB算法的前提下才会启动
某台gtm在接到某个新ldns的请求后，接到请求的gtmd即为该ldns的初次负责
人，它将调度每个DC中的big3d都对该ldns发起探测,big3d探测的结果以广播
形式发送给每gtmd，因此ldns.gz文件是无需同步的
首轮探测结束后，将使用算法重新选举一个gtmd接管成为该ldns的负责人
如果DC中有vs被用在了使用path算法的pool中，那么该DC种的big3d才会发
起对ldns的探测，否则不会发起
如果DC有多条LINK，只有与具体VS（同上vs定义）宿主相同网段的那条link才
会被探测
如果一个dc没有big3d，但是它的vs却又被用在了使用path算法的pool内的话，
怎么办？---将无法完成探测，应避免。
GTM利用算法对经常发起解析的ldns保持较高频率对探测，而对使用较少的
ldns减少探测，并有算法保证防止因对new ldns的探测而占用过多带宽（dns
flood攻击）
35
path metric collection
LDNS
GTM1
DC1
GTM2
DC2
GTMD
GTMD
BIG3D
BIG3D
36
私有地址server情形下的NAT处理
• GTM在添加server时提供了translation的配置，意
在解决NAT问题
37
私有地址server情形下的NAT处理
• GUI界面的address表示public 地址，translation表
示private地址！为何如此设计？就是这么设计的。
• 在增加一个host-based类型server时，直接正确填
写正确地址即可
• 在增加一个bigip-based类型server时，需先正确填
写server的相关ip（公私地址都应填），然后手工在
该server下增加具体的vs（公私地址都填），此时自
动发现功能将自动失效
38
私有地址server情形下的NAT处理
• Big3d何时使用public地址，何时使用private地址
来通讯呢？
• 但一个big3d所在的server在GTM是以translation
方式配置时，在同一个DC中通信时使用private
（translation）地址，在DC间使用public（address）
地址，但如果不是以translation方式配置，则只能
用public地址
39
私有VS地址—一个CASE
• 环境是LTM combo GTM
• 用户首先将box理解为GTM加入server（with 地址
转换），然后将box理解为LTM加入server（without
地址转换），这样做的目的是为了能从LTM部分自
动发现VS（这里不考虑这样将导致GTM解析出私
有地址问题）
• 实际效果：能自动发现VS，但是有一部分vs是红的，
即使这些VS在LTM部分都是绿色的
40
Named.conf,zone,wideip.conf,persisten
ce的同步
• 在gtm间的iquery中相互通信这heartbeat信息，包含了named，wideip，
persistence的timestamp，每10秒发送一次
•
•
•
•
[root@gtm1:Active] config # iqdump 38.1.1.12 lab2_team2 | grep -i "_timestamp"
<wideip_timestamp>1269224525</wideip_timestamp>
<named_timestamp>1268986383</named_timestamp>
<persist_timestamp>1269224606</persist_timestamp>------------Earlier versions of GTM (pre
9.3.0 and 9.4.2)使用，现已废弃！
• 如果wideip或者named文件有更新那么该时间戳将会发生变化，接到
变化通知的gtm将会启动相关同步程序进行配置文件的同步
• Wideip_timestamp表示当前wideip.conf文件的最新修改时间，如果该
时间变新，将触发named.conf等文件同步
• Named_timestamp表示named.conf文件的最新修改时间，如果时间变
心，将触发named.conf以及zone文件的同步
• Persistence的同步较为复杂
• 因此首先第一步配置NTP服务器是GTM中非常关键的一步
41
Wideip_timestamp变化后
• 如果发现比自己的wideip.conf时间新，那么gtmd
将使用syncer脚本从对方拉取相关文件，包含
/config/gtm下的诸多重要文件.用gtmparse –l分析
文件并load
• 如何查看一个wideip.conf文件的最新时间
•
•
•
[root@gtm2:Active] config # more gtm/wideip.conf
# (gtm2.training.com 38.1.1.12) dumped 03/26/2010 23:17:24 PDT - GTM
Version 9.3.1.37.0.0
（如果起初system-general properties—gtm—general下的syncronization没有
打钩或同步组名不一样，那么在gtm_add过后再手工再改这个配置的话需要全
部手工改完才会彼此开始同步，所以请注意此时必须小心考虑谁的配置是最新
的，最新配置的GTM应该最后去打这个钩，因为widedip.conf是靠比较时间
的！！小心！！）
• 但是上面的这个配置gtm_add时候是可以同步的
42
Named_timestamp变化后
• Gtmd如果发现时间戳比本地新，那么将通过mcpd
发送一个start_sync_zones的消息给zrd
• Zrd将促发sync_zones拉取差异化数据(zones)
• Sync_zones调度rsync拉取配置文件（使用独立的
iquery通道）
• Sync_zones在同步时会临时备份文件到一个
flielist里，然后使用named-checkconf命令检查，
如果有错误则恢复备份的文件
• 正确更新完毕后，zrd通过mcpd发送
end_sync_zones信息给gtmd告知其同步已完成
43
ZoneRunner & BIND
• Zonerunner，图形化的BIND配置工具，表现为zrd
进程
• 为bind和mcpd通信提供桥梁，gtmd修改wideip将
通过mcpd—zrd告知BIND进程进行对应的修改
• 使用动态更新机制控制bind中的zone更新！
allow-update {
localhost;
};
44
ZoneRunner & BIND
• 由于使用动态更新方式控制zone，所以不要轻易
尝试手工编辑zone文件
• Wideip,zonerunner界面的配置修改，并不会立即
同步到对应的zone文件中
• 这些变化临时存在于/var/named/config/namedb
下对应zone的jnl文件中
• BIND 的named.conf文件存放于
/var/named/config目录下，zonerunner界面也可
以编辑
• BIND默认不提供递归功能
45
ZoneRunner & BIND
• See SOL7176: F5 Networks support for
ZoneRunner, BIND, and the named daemon
46
GTM配置十步法
1. Define VLANs
2. Define Self IPs
3. Create default route
4. Define NTP servers
5. Define GTM listeners
6. Create data centers
7. Create Server objects
8. big3d_install or bigip_add for BIG-IP servers
9. Create GTM pool Objects
10.Create WideIPs
47
日志检查及排错
• Gtm日志保存在/var/log/gtm中
• 当需深入排错时，可以打开gtmd的一些高级日志
GTM.QueryLogging = enable //default disable
GTM.DebugProbeLogging=enable //default disable
Log.GTM.Level = debug //default notice
Log.Big3d.Level = debug //defualt notic
48
日志检查及排错
•
•
•
•
•
•
•
[root@b1500-930-1b:Active] config # tail -f /var/log/gtm |grep 172.24.9.15
Jul 22 13:55:20 b1500-930-1b gtmd[1036]: 011ae039:7: Check probing of IP:Port 172.24.9.15:80 in DC dc3
Jul 22 13:55:20 b1500-930-1b gtmd[1036]: 011ae03a:7: Will not probe 172.24.9.15:80 in DC dc3 because will be done by other GTM
(gtm2dc2.training.com:172.24.9.12)
Jul 22 13:55:31 b1500-930-1b gtmd[1036]: 011ae03d:5: Probe from 172.24.9.13: buffer = <monitor> <name>tcp</name>
<addr>::ffff:172.24.9.15</addr> <port>80</port> <trans_addr>::ffff:172.24.9.15</trans_addr> <trans_port>80</trans_port>
<monitor_state>6</monitor_state> <node_type>4</node_type> <monitor_type>2</monitor_type> <why>state: timeout</why>
</monitor>
Jul 22 13:55:31 b1500-930-1b gtmd[1036]: 011ae0f2:1: Monitor instance tcp 172.24.9.15:80 UP --> DOWN from 172.24.9.13 (state:
timeout)
Jul 22 13:55:31 b1500-930-1b gtmd[1036]: 011a6006:1: SNMP_TRAP: VS 172.24.9.15:80 (Server dc3_ext- host_training_server) state
change green --> red (VS dc3_ext- host_training_server: Monitor tcp from 172.24.9.13 : state: timeout)
Jul 22 13:55:31 b1500-930-1b gtmd[1036]: 011a5004:1: SNMP_TRAP: Server dc3_ext- host_training_server (ip=172.24.9.15) state
change green --> red (Server dc3_ext- host_training_server: No enabled VS available)
[root@b1500-930-1b:Active] ucs # tail -f /var/log/gtm |grep Wide
Jul 22 13:55:31 b1500-930-1b gtmd[1036]: 011a3004:1: SNMP_TRAP: Wide IP ww1.acme.com state change green --> red (Wide IP
ww1.acme.com: No enabled pools available)
49
日志检查及排错
•
•
•
[root@b1500-925-1a:Active] ucs # tail -f /var/log/gtm |grep 172.24.9.15
Jul 22 13:55:26 b1500-925-1a gtmd[987]: 011ae039:7: Check probing of IP:Port 172.24.9.15:80 in DC dc3
Jul 22 13:55:26 b1500-925-1a gtmd[987]: 011ae03b:7: Will probe 172.24.9.15:80 in DC dc3
•
Jul 22 13:55:26 b1500-925-1a gtmd[987]: 011ae03d:5: Probe to 172.24.9.13: buffer = <monitor> <name>tcp</name>
<addr>::ffff:172.24.9.15</addr> <port>80</port> <trans_addr>::ffff:172.24.9.15</trans_addr>
<trans_port>80</trans_port> <timeout>120</timeout> <probe_interval>1</probe_interval>
<probe_timeout>5</probe_timeout> <probe_num_probes>1</probe_num_probes>
<probe_num_successes>1</probe_num_successes> <reverse>0</reverse> <transparent>0</transparent>
<node_type>4</node_type> <monitor_type>2</monitor_type> <mon_param>
<pkey>SEND=</pkey>
<ptype>1</ptype>
<pvalue><![CDATA[]]></pvalue> </mon_param> <mon_param>
<pkey>RECV_I=</pkey>
<ptype>3</ptype>
<pvalue><![CDATA[]]></pvalue> </mon_param> </monitor>
Jul 22 13:55:31 b1500-925-1a gtmd[987]: 011ae03d:5: Probe from 172.24.9.13: buffer = <monitor> <name>tcp</name>
<addr>::ffff:172.24.9.15</addr> <port>80</port> <trans_addr>::ffff:172.24.9.15</trans_addr>
<trans_port>80</trans_port> <monitor_state>6</monitor_state> <node_type>4</node_type>
<monitor_type>2</monitor_type> <why>state: timeout</why> </monitor>
Jul 22 13:55:31 b1500-925-1a gtmd[987]: 011ae0f2:1: Monitor instance tcp 172.24.9.15:80 UP --> DOWN from 172.24.9.13
(state: timeout)
Jul 22 13:55:31 b1500-925-1a gtmd[987]: 011a6006:1: SNMP_TRAP: VS 172.24.9.15:80 (Server dc3_exthost_training_server) state change green --> red (VS dc3_ext- host_training_server: Monitor tcp from 172.24.9.13 : state:
timeout)
Jul 22 13:55:31 b1500-925-1a gtmd[987]: 011a5004:1: SNMP_TRAP: Server dc3_ext- host_training_server (ip=172.24.9.15)
state change green --> red (Server dc3_ext- host_training_server: No enabled VS available)
•
•
•
•
50
日志检查及排错
• Mar 17 05:55:48 gtm3 gtmd[1260]:
011ae03c:7: getconfig_put: Could not find my
own box, will not continue with auto
discovery.
把LTM加入到GTM，iquery都建立了，却没有vs被
发现，如果有此日志说明gtm自己没有被加入到
server中
51
日志检查及排错
• Iqdump peer_ipaddress sync_group_name
• 不跟sync_group_name只能看到基本的心跳和
server统计信息，无法看到vs信息
• Dig或nslookup得到类似AUTHORITY: 2的flag，意
味着结果是由BIND给出。
52
日志检查及排错
• 某个object由哪个big3d负责探测是可能不断变化
的，这在某种情形下或许会导致server状态的
flapping
• 在1500平台上，Big3d，gtmd竞争20%的CPU资源，
因此大量的path探测可能会导致性能问题，可以关
闭GTM上的big3d对path的探测功能，在加gtm到
server的时候有iquery option，关闭path探测即可
53
日志检查及排错
• SOL8187: Troubleshooting BIG-IP LTM and
GTM device certificates
• SOL8195: Overview of the BIG-IP GTM
big3d_install, bigip_add, and gtm_add utilities
• SOL4039: Overview of iQuery communication
between BIG-IP and 3-DNS version 4.x and
BIG-IP LTM and GTM version 9.x
• SOL5965: The BIG-IP GTM is unable to monitor
BIG-IP version 4.x
54
日志检查及排错
• wideip层面选择GA，GA所要选择的pool变红，但
是该pool里的某个算法可以实现解析出一个IP地
址，测试GTM依然会选择该POOL。
• 例如pool里的算法是fall back ip/return to dns.
• 因此如果要在WIDEIP层面做GA，应该不容许
pool层面总是可以得到结果 的情况出现。
• Pool中算法选择none是控制算法跳过或跳跃到下
一个可用pool的好方法。
55
Topology
• https://support.f5.com/kb/enus/solutions/public/9000/600/sol9620.html
• https://support.f5.com/kb/enus/solutions/public/10000/700/sol10721.html
56
Topology都miss的情况下
• 如果wideip层面的top算法都failed，则行为如下（V9.3.1
wideip下有2个pool）：
• 1.选择第一个可用的pool
• 2.按照被选择的pool里所设定的算法来作为pool间的算法，
例如pool中是的第一算法是RR，则在POOL间轮询。
• 3。如果被选择pool的第一算法failed，则使用第二算法，因
此类推。
• 4。如果被选择pool的算法所决定的最终算法是return to
dns 则意味着这个pool不可用，此时return to到wideip上，
而不是真正的BIND，即又会回到wideip层面选取下一个可
用pool并按照该pool设定的算法执行，如果这个pool的算
法最终又是return to dns，就会真正的return to BIND.
57
与排错相关的更多资源
•
•
•
•
GTM配置关键点及排错总结.pptx
这篇文档在给channel 的资料U盘上有
超超的GTM 2 days training - v2.pptx
http://www.adntech.com/bbs/viewthread.php?tid
=1476&highlight=GTM
• GTM部署模型方案讨论
• http://www.adntech.com/bbs/viewthread.php?tid
=982&extra=page%3D1
58
关于开GTM CASE
• NSE虽然通过wideip.conf可以大体复现一个网络结构，但是这往往不
全面，提供全面清晰的GTM 网络结构图往往非常有助于解决问题
• L3的服务，记得一定先自我仔细排查并搜集有效的信息及证据，准确
描述问题现象及时间是关键
• 提供gtmd的debug及gtmd的probe debug日志信息往往更有效
• Askf5,devcentral,adntech.com拥有很多优秀的资源，常规问题或许别
人已经见过
• 出现问题前做过什么，往往会有惊奇发现
• 相互理解更能快速解决问题