之前单独做了一个健康检查的页面。配置是如下location ~* HEALTH_CHECK {alias /home/app/HEALTH_CHECK ;try_files /lbck =410;} location ~* /HEALTH_CHECK/ {alias /home/app/HEALTH_CHECK ; access_log off; } location ~* /HEALTH_CHECK/ {root /home/app/ ;access_log off;} 后来尝试了最简单的配置方式可以正常工作。location /HEALTH_CHECK/ {alias /home/app/HEALTH_CHECK/ ;access_log off;} 咨询了一下开发同学。主要是alias实现上方式的问题。不过总的来说，用这些东西还是多做好测试。
公司使用的svn都是1.7版本的，然后在debian testing源里的版本还是1.6的，这个就造成了平时在linux下完全不能用svn。晚上升级了一下，终于可以用了。直接加一下源:deb http://opensource.wandisco.com/debian/ squeeze svn17添加一下key```bash wget http://opensource.wandisco.com/wandisco-debian.gpgsudo apt-key add wandisco-debian.gpg
之前有同事看了有2个监控图，然后就问我为什么tcp的连接数基本没有变化，但是网卡的数据流量增加了不少？ 这个其实比较好分析，应用系统和前端的LB之间实际是keepalive的持久连接。当单个应用服务器上请求量不是太的时候，应用服务器上看到的连接数和用户的请求量其实不是一个线性的关系，维持的连接数多少，主要看前端LB设置的保留多少个空闲连接。但是后端应用服务器（apache）上每个持久连接默认配置只能处理100个请求，所以当业务量增加的时候可以看到TIME_WAIT的数量增加了。同时网卡流量也对应增加的。
近来比较火的一个问题就是DNS放大攻击，详细的介绍可以参考这里。cloudflare被攻击的流量超过20G。这个攻击思路其实和smurf攻击类似。smurf攻击是对一个子网的广播地址发起一个伪造IP源的ICMP包，这样这个子网的所有机器都会icmp-reply到这个伪造的IP地址上。造成只需要少量的肉鸡就能引起很大的攻击流量。而DNS放大攻击是伪造一个DNS查询的报文，源地址改成想要攻击的IP。单个查询的包64字节，如果是ANY类型查询(或者DNSSEC记录)，那么回复报文一般会大几十倍。当然，如果攻击者自己制造一个很大的TXT记录，那么可能返回的更大的报文，攻击的强度就会更大。这样2M带宽的肉鸡，能制造的攻击流量就能到几百兆了，几十个G攻击流量很容易制造。 [这里](http://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack)
其实在DB120之类的路由器上装tcpdump什么的非常简单，有16M的ROM基本随便装自己想玩的东西。但是对于只有4M ROM的tp-link 740来说就比较麻烦了。一方面是ROM比较小，另外一方面是要想保存数据的话可以用nc之类的同步传输数据。我是直接选中tcpdump和nfs客户端。这样可以直接远程挂载，把抓包的文件直接放远程服务器上，方便后期的分析。1.下载openwrt代码git clone git://git.openwrt.org/12.09/openwrt.gitcd openwrt && ./scripts/feeds update -a && ./scripts/feeds install -a2.配置openwrt基本上就是选上ar71xx的cpu，然后模版选上TP-LINK 740ND就行了，注意选上tcpdump,nfs-utils,kmod-fs-nfs,wpad 3.编译openwrtmake -j 10 V=99直接等编译好把openwrt-ar71xx-generic-tl-wr740n-v1-squashfs-sysupgrade刷到路由器就OK了。 然后就可以直接在路由器上挂载上远程的NFS，放抓包的文件。
今天遇到了一个和dns ttl相关的问题。线上一个nginx服务器代理了一些外部的资源，把外部的http的资源变成https的供我们自己的https页面上用。但是今天看到了有很多错误日志，显示的是连upstream的机器失败了。我看了一下配置文件，直接在nginx服务器上访问配置的url是正常访问的。再在nginx服务器上解析了一下对应的IP，发现和错误日志里显示的不一样了。看样子是外部的dns切换了IP，nginx一直是在访问老的失效的IP。 网上看了一下nginx的WIKI，也问了一下tengine的开发同学。nginx wiki上说是会遵循DNS的ttl设置，但是结果确实不是这样。自己简单测试了一下。测试环境：1. 1台linux服务器，装上nginx-1.2.8即可。2. 1台linux服务器跑dnsmasq，设置好ttl并开启日志，也在上面装了wireshark方便抓包。配置文件如下worker_processes 1;error_log logs/error.log;events {worker_connections 1024;}http {include mime.types;default_type application/octet-stream;sendfile on;keepalive_timeout 65;server {listen 8888;server_name localhost;charset utf-8; }} 发现启动的时候会做4次dns查询，但是后面无论多久是不会重新进行nginx.test.org的查询的,而wireshark显示TTL确实是被置为了10s。Domain Name System (response)[Request In: 7][Time: 0.000074000 seconds]Transaction ID: 0x925fFlags: 0x8580 (Standard query response, No error)1… …. …. …. = Response: Message is a response.000 0… …. …. = Opcode: Standard query (0)…. .1.. …. …. = Authoritative: Server is an authority for domain…. ..0. …. …. = Truncated: Message is not truncated…. …1 …. …. = Recursion desired: Do query recursively…. …. 1… …. = Recursion available: Server can do recursive queries…. …. .0.. …. = Z: reserved (0)…. …. ..0. …. = Answer authenticated: Answer/authority portion was not authenticated by the server…. …. …. 0000 = Reply code: No error (0)Questions: 1Answer RRs: 1Authority RRs: 0Additional RRs: 0Queriesnginx.test.org: type A, class INName: nginx.test.orgType: A (Host address)Class: IN (0x0001)Answersnginx.test.org: type A, class IN, addr 220.xx.xx.xxName: nginx.test.orgType: A (Host address)Class: IN (0x0001)Time to live: 10 secondsData length: 4Addr: 220.xx.xx.xx ...
前几天看论坛上有人问LVS几种模式的选择问题，简单地回复了一下。觉得很多做运维的新人都对这个选择存在疑惑，就单独写写。 LVS主要是DR,TUN,NAT和淘宝的FULLNAT模式，对于绝大部分人而言只能选择原版内核支持的前三种。 1.DR模式DR模式是效率最高的一种，对于每个请求LVS把目的mac改成从RS中选择的机器的mac，再将修改后的数据帧在与服务器组的局域网上发送。但是局限性是LVS机器需要和RS至少能有一个网卡同在一个VLAN下面，这样限制了DR模式只能在比较单一的网络拓扑下使用。 2.TUN模式TUN模式其实性能与DR模式相比差别不大的，TUN模式下会动态地从RS列表选择一台服务器，将请求报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的服务器；RS服务器收到报文后，先将报文解封获得原来目标地址为VIP的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。TUN模式可以解决DR模式下不能垮网段的问题，甚至可以垮公网进行。但是需要RS能支持ipip模块。 3.NAT模式NAT模式对RS没有其他要求，唯一的要求是得把RS的网关设置为LVS机器。因为进出的流量都要通过LVS机器，所以性能相对会差很多，而且部署的规模很难做大。 以上DR模式和TUN模式在部署的时候都需要在本机绑定VIP，非常麻烦，比如我们之前有的老应用因为一些历史问题单个应用的VIP有40来个，如果用LVS做负载均衡基本就崩溃了，每次新增/删除一个VIP，估计得线下测试好多次ip addr add/del的用法。NAT模式在部署的时候也是太麻烦了。而且还有一个很关键很关键的是，使用了LVS后万一被人ddos怎么办？syn-cookie在抵挡攻击的时候效果一般不是太好，这样攻击透过lvs直击后端应用就杯具了。所以在很多大公司都不敢直接把lvs放公网，前面得加个防火墙啥的。所以淘宝单独搞了一个fullnat模式，一方面可以解决部署绑VIP、或者把RS的网关设置为LVS机器IP带来的部署复杂问题，另外一方面是加了一个syn-proxy等等，可以抵挡下一般的网络层攻击。但是使用FULLNAT模式后确实有个麻烦的是后端机器看不到用户的IP了，所以RS上还得用装上打过补丁的内核，对取IP的操作就劫持才能获取到用户IP。 对于大规模网站，其实无聊单独使用哪种LVS都是不能替换商业设备的，所以还是得配合nginx or haproxy做负载均衡。这个时候最简单的就是lvs(fullnat)+nginx/haproxy（nginx官方版本现在没有4层代理功能，haproxy对后端又不支持keepalive）,当然使用DR模式或者TUN模式也还可以的。总之基本都得用2层才能搞得定，满足大部分应用上的需求。其实对于很多小公司，我觉得直接用nginx/haproxy就OK了。搞的那么复杂维护成本会非常高的，自动化运维没有跟上的时候只会把自己给玩死。 在使用LVS之前，建议大家一定仔细看看文档，没有好好看文档就别瞎折腾了。1、http://zh.linuxvirtualserver.org/handbooks2、http://www.linuxvirtualserver.org/Documents.html#manuals
上周把blog开启了cache php结果后，主要是为了解决假想的一种短时间内请求过大php-fpm性能跟不上的问题。但是今天发现了一个比较奇怪的问题，就是打开的blog首页的时候页面是空白的。然后想起这个可能是和我针对dnspod的监控有特殊配置的原因。因为dnspod的访问比较频繁，所以我设置了直接返回200的特殊配置，避免无谓消耗机器的性能。42 location / {4344 # First attempt to serve request as file, then45 # as directory, then fall back to displaying a 404.46 try_files $uri $uri/ /index.php;47 # Uncomment to enable naxsi on this location48 # include /etc/nginx/naxsi.rules49 if ($http_user_agent ~ monitor ) {50 return 200;51 access_log off;52 }53 fastcgi_cache blog;54 } 自己当时配置的时候只是去连续刷新几次，看是否成功cache住了页面。但是实际平时都是dnspod的监控在访问，直接返回了200，这样如果这样的页面被cache，自己打开的时候就啥东西都看不到了。解决的方式就是修改一下dnspod的监控页面，比如监控的URL改成/favicon.ico之类的。 但是这样修改也会有个漏洞，比如我手动设置user-agent为monitor，使劲访问/，则首页缓存住的一直是一个空页面，所以想了个办法，把user-agent单独map到一个变量上，然后cache_key里把这个变量加上25 map $http_user_agent $agent {26 default ‘normal’;27 ~monitor ‘dnspod’;28 } curl -I -A “monitor” http://blog.gnuers.orgHTTP/1.1 200 OKServer: nginx/1.2.7Date: Wed, 03 Apr 2013 12:11:55 GMTContent-Type: application/octet-streamContent-Length: 0Connection: keep-alive – – ::ffff:101.226.68.137:35145 – – [03/Apr/2013:13:46:19 +0000] blog.gnuers.org “HEAD / HTTP/1.1” 200 0 “-” “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; QQDownload 713; .NET CLR 2.0.50727; InfoPath.2)” normal “-” “unix:/var/run/php5-fpm.sock” “- -” 0.214 0.214 log_format main ‘$http_orig_client_ip – $remote_addr:$remote_port – $remote_user [$time_local] $host “$request” $status $body_bytes_sent “$http_referer” ‘‘"$http_user_agent – $agent – $hitstatus" “$http_x_forwarded_for” “$upstream_addr” “$ssl_protocol $ssl_cipher” $request_time $upstream_response_time’; ...
Graphviz是一个比较简单的画图程序，之前看别人用这个自动画图生成上百个系统的依赖关系觉得挺玄乎的。今天照着http://www.ibm.com/developerworks/cn/aix/library/au-aix-graphviz/ 简单学习了一下。digraph G{A->B;E [shape=box,color=red]J [shape=box, fillcolor="#ABACBA", style=filled]B-> { E;F } -> G ->J;{ A;G } -> J;{A;F}->K;} Graphviz 参考文档： http://www.ibm.com/developerworks/cn/aix/library/au-aix-graphviz/http://www.graphviz.org/content/attrshttp://blog.163.com/prevBlogPerma.do?host=lockriver&srl=487232242010101761749383&mode=prev
使用VPS的时候肯定也会考虑到安全上的问题，简单配置一下iptables。直接贴一下我自己写的2个设置脚本。首先得写一个清理规则、重置默认策略的脚本放crontab里面，以免自己设置错了策略造成自己不能登录。 清理规则脚本： #!/bin/bash source /etc/profile DIR=$(dirname $0) LOG=$DIR/clean.log iptables -F iptables -X iptables -Z # reset counter iptables -P INPUT ACCEPT # set default action for INPUT packages date > $LOG echo "clean the iptables rule" >> $LOG iptables 规则设置脚本： #!/bin/bash # for my vps iptables -F # remove all rules iptables -X # remove all chains defined by myself iptables -Z # reset counter iptables -P INPUT DROP # set default action for INPUT packages iptables -P OUTPUT ACCEPT # set default action for OUTPUT packages iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # allow all traffic through lo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # allow all established and related INPUT for port in 22 80 443 do iptables -A INPUT -p tcp --dport $port -m state --state NEW -j ACCEPT done iptables -A INPUT -p icmp -m limit --limit 20/m -j ACCEPT 查看规则： ...