Posts

搞过N套ospf集群，流量不均衡基本都是cost值不同引起的。第一次是我扩容之前的一个集群，原来就2个机器跑ecmp，流量还算是均等。后来考虑到容量上可能会有不足我就扩容了2个机器，结果发现扩容的机器ospf起来后老的2个机器就没有流量了。在核心交换机上查到4个area的cost不同，新的2个机器的cost没有设置是1，然后老的2个机器的cost以前在核心交换机上设置为了1000，让网络的同学帮忙在核心交换机上把新的2个机器的cost也改成1000后恢复，能形成4条ecmp路由。第二次是我自己新建的一套，集群起来后就看到只有1个机器有流量，把那个机器干掉后其他3个机器的流量基本能均等。因为默认路由是从交换机学习的，所以自己看了一下路由发现有问题的那个机器的metirc 是11 ，而其他的3个机器的默认路由metric都是10001. 找配合的网络的同学在交换机上看了下，上面没有单独去设置cost，但是确实是只有一条路由的cost是20，而另外一个集群的上联交换机能看到4条cost相同的路由只有一条路由的：有4条路由的：后来排查后发现是有1个机器的ospf配置里auto-cost reference-bandwidth被注释了。这个命令的作用是跟进带宽自动计算cost— OSPF Command: auto-cost reference-bandwidth <1-4294967>— OSPF Command: no auto-cost reference-bandwidthThis sets the reference bandwidth for cost calculations, where this bandwidth is considered equivalent to an OSPF cost of 1, specified in Mbits/s. The default is 100Mbit/s (i.e. a link of bandwidth 100Mbit/s or higher will have a cost of 1. Cost of lower bandwidth links will be scaled with reference to this cost). ...

最近遇到几次DNS的主备同步问题。 每分钟动态生成反解，然后发现有的slave服务器上不更新。通过日志看到每次都是最后一个slave机器收到notify消息去master上请求传输zone时有报错，提示master服务不可用。后来发现是master上的transfers-out没有单独指定，这个值默认是10，所有可能比较多slave机器请求时就失败了。把这个配置根据实际的情况调整后解决的。 海量的域名同步时，slave查询soa都查不过来。 到底多大是海量？这个自己看看自己机器上的域名总数能占到中国所以域名的几个百分点以上吧。当数量大了后确实是各种问题都出来了，这个我是观察了一下有个serial-query-rate 可以设置soa查询速度的，默认是20/S，对于有海量域名的DNS来说这样显然是跟不上节奏的，直接把这个调整到5W/S，查询速度飕飕的。对于master的压力其实也还好，就当时收到那么点请求。相应地tcp-clients和transfers-in，transfers-per-ns也要做好调整。 SOA的TTL设置问题。 这个其实也不算是什么问题。就是nxdomain的缓存时间是有SOA TTL决定的（如果本地LDNS没有单独设置的话）。有人先把1个域名删除了，接着又有人去解析一下这个被删除的域名，然后之前的人把域名又加上去。。结果所有人在办公网访问不了这个新增的域名。其实这个就是NXDOMAIN的缓存问题。我只有直接把SOA TTL缩短一下。 很多性能上的问题我们需要根据日志来看到底存在的瓶颈是在哪里，然后再去考虑如何优化。没有目的的优化是瞎折腾。

ospf的部署因为涉及交换机配置和服务器上qugga的配置，在配置的时候一般都比较麻烦。对应ospf的一些关键配置项需要在配置前协商好，比如 hello-interval 和 dead-interval如果不匹配的话是没有办法建立起邻居关系的，另外还有ospf类型(p2p or 广播类型,etc),验证的方式、密码，area ID。当前这些都是建立在网络接线没有任何问题的前提下，如果网络接线不小心接错了2根，那就更悲剧了，其中的心酸泪唯有自己遇到了才能体会。 所以要简化自己在服务器上的配置需要从2个方向入手。一是在在配置前检查接线是否有问题，二是能自动化配置的地方就搞自动化。 因为一般配置都是网工先在交换机上把ospf配置好，所以对于双上联的情况可以比较简单的抓包查看area id是否一直来判断接线是否有问题。 tcpdump -i eth4 -nn -vv proto ospf -c1 2>/dev/null |grep Area tcpdump -i eth5 -nn -vv proto ospf -c1 2>/dev/null |grep Area 另外一个比较烦的是互联地址的配置，其实也可以直接抓包看到交换机的端口上的互联IP，可以推算出本地网卡应该配置的地址。 tcpdump -i eth4 -nn -vv proto ospf -c1 2>/dev/null |grep OSPFv2 tcpdump -i eth5 -nn -vv proto ospf -c1 2>/dev/null |grep OSPFv2 有了以上得到的信息其实就可以很方便写个脚本自动生互联网卡的配置文件，以及zebra、ospfd配置文件.在大批量配置ospf的时候可以事半功倍。

实际在部署虚拟化的时候我们往往都会把宿主机和VM各自的地址段单独规划。借助OpenWrt可以自己划分一下vlan。OpenWrt上设置vlan tag可以参考之前的文章。比如我的network配置文件,划分了3个VLAN（其实最好不要使用vlan 0），非默认vlan里每个lan口都是打了vlan tag： config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config interface 'lan' option ifname 'eth1.0' option type 'bridge' option proto 'static' option ipaddr '10.0.1.1' option netmask '255.255.255.0' config interface 'lan1' option ifname 'eth1.1' option type 'bridge' option proto 'static' option ipaddr '10.1.1.1' option netmask '255.255.255.0' config interface 'lan2' option ifname 'eth1.2' option type 'bridge' option proto 'static' option ipaddr '10.2.1.1' option netmask '255.255.255.0' config interface 'wan' option ifname 'eth0' config switch 'eth1' option reset '1' option enable_vlan '1' config switch_vlan option device 'eth1' option vlan '0' option ports '0 1 2t 5*' config switch_vlan option device 'eth1' option vlan '1' option ports '0t 1t 2t 5*' config switch_vlan option device 'eth1' option vlan '2' option ports '0t 1t 2t 5*' config interface 'wwan' option proto 'dhcp' 其他还需要修改好dhcp和firewall配置文件（可以简单参考之前的文章）。在自己笔记本上测试的，把有线网卡eth0加了vlan 2，把没有eth0放到br0网桥，eth0.2放到了br2。测试dhcp br0和br2分别获取到IP。 ...

一个域名的权威DNS往往都有多个，有其实域名服务商或者一般的互联网大公司的NS可能非常多。那么我们的local dns做递归的时候是如何选择使用哪个NS呢。一般是根据SRTT算法来做选择。不过的软件的方式有所不同，总的来说有几种：1. 选择RT最短的NS。2. 平均选择RT小于一定阈值的NS。3. 把NS参考RT和一些其他的因素进行排序，按照不同的比例进行选择。 可以参考一下这个PDF。 [PDF](http://www.google.com.hk/url?sa=t&rct=j&q=Name%09%20%20%20Server%09%20%20%20Selec%2Bon%09%20%20%20of%09%20%20%20DNS%09%20%20%20%20Caching%09%20%20%20Resolvers%09%20%20&source=web&cd=1&cad=rja&ved=0CCoQFjAA&url=%68%74%74%70%73%3a%2f%2f%77%77%77%2e%64%6e%73%2d%6f%61%72%63%2e%6e%65%74%2f%66%69%6c%65%73%2f%77%6f%72%6b%73%68%6f%70%2d%32%30%31%32%30%33%2f%4f%41%52%43%2d%77%6f%72%6b%73%68%6f%70%2d%4c%6f%6e%64%6f%6e%2d%32%30%31%32%2d%4e%53%2d%73%65%6c%65%63%74%69%6f%6e%2e%70%64%66&ei=mY6LUuHED8nniAfCrYHYAg&usg=AFQjCNH4TlHk2K_1r4q6ia_NgtMJlTRVmA&bvm=bv.56643336,d.aGc)

做公有云的应该都能感受到比做私有云多N倍的痛苦。比如服务器硬件的问题，如果是内部的应用按理说应用都做到了无状态，随便挂几个机器基本没有任何影响，把机器下线慢慢修就行。但是对于有上十万台服务器规模的人来说，每周挂几十个机器是非常非常平常的，有时内核有bug你也无能为力，升级肯定是需要重启机器的，会对上面跑的VM造成影响，不升级就只有等死。虽然说xen和kvm都是有热迁移，但是实际效果往往差强人意，比如当每秒钟内存内读写的内容比网络速度快的时候，就永远不可能完成热迁移了，如果谁的VM上跑了个memcache之类的，基本就没法迁移。另外很多负载比较重的VM，迁移起来可能对服务的影响也比较大。 在自己的两台笔记本上测试了一下KVM的迁移，整理一下。 每台笔记本上都是跑的debian testing，先是修改/etc/network/interfaces配置一下网桥（VM都是使用桥接的形式，每个VM和笔记本获取到的IP都是1个网段） pm@debian:~ $ cat /etc/network/interfaces # The loopback network interface auto lo iface lo inet loopback # The primary network interface #allow-hotplug eth0 #NetworkManager #iface eth0 inet dhcp auto br0 iface br0 inet dhcp bridge_ports eth0 bridge_fd 0 bridge_maxwait 0 安装基本的包 aptitude install qemu-kvm libvirt-bin virt-manager virt-top 创建镜像文件，从ISO安装系统3.1 create image file qemu-img create -f qcow2 debian3.qcow2 10G 如果要调整大小，比如增大size，可以直接命令操作 qemu-img resize debian3.qcow2 +2G 3.2安装系统，sudo 运行一下脚本就可以安装了。 $ cat install_debian3.sh virt-install \ --name=debian3 \ --os-type=linux \ --os-variant=debianwheezy \ --vcpus=2 \ --ram=1024 \ --accelerate \ --hvm \ --vnc \ --vncport=6668 \ --network=bridge=br0,mac=RANDOM,model=virtio \ ```bash --disk path=/home/pm/image/debian3.qcow2,format=qcow2,bus=virtio,cache=writeback \ --cdrom=/home/pm/downloads/debian-7.2.0-amd64-xfce-CD-1.iso 1. virsh下启动系统,使用vnc登录进去（知道IP也可以直接ssh登录） sudo virsh list –all sudo virsh start debian3 sudo virsh shutdown debian3 sudo virsh edit debian3 (edit domain xml config file) sudo virsh dumpxml debian3 ...

这几天有开发同学反馈说是线上的应用dns解析总是失败，我自己测试了连续dig 1000次都是正常的。今天也把合作方的同学一起叫上了。因为之前是看对方有的CNAME设置的TTL是0,造成每次需要重新解析，dns服务器没有办法做cache。 今天排除了很久，后来看了线上的日志才发现问题的本质是业务量非常小，每天就几十笔调用，即便对方把TTL改成60后，实际每次应用服务器查询dns的时候，dns服务器都是需要重新递归一次（每次两三秒），所有可能没有解析出来应用都已经报错了。 这个也没有啥好的解决的方式，要么应用把这个超时时间增大，要么自己另外跑个脚本周期性地访问dns缓存住这样的域名。

之前每次编译内核都是自己慢慢手动把每个选项都确认一下。费时间不说，主要之自己最终实际还是编译了很多不用的模块，造成编译的时间是比较长的。今天试了下localmodconfig还不错。现在的内核配置的时候都是可以先make localmodconfig的，这个只是把当前内核加载了的模块都选上。如果自己有额外的没有插在电脑上的硬件驱动需要支持，可以单独menuconfig 单独选上。 测试了一下编译最新的内核，第一次的编译时间可以在13分钟左右搞定，之前每次都是要编译一个多小时(CPU是i5-2410M)。 make localmodconfig make menuconfig fakeroot make-kpkg -j 4 –initrd –revision=1.0V kernel_image kernel_headers

最近由于需要用iptables设置一些过滤规则，也有bind里配置acl的时候有合并地址段的需求。看了下cpan里有个现成的模块，几行代码就可以做这个合并工作。 #!/usr/bin/perl use strict; use warnings; use Net::CIDR::Lite; my $cidr = Net::CIDR::Lite->new; while (my $line=<>) { $cidr->add($line); } foreach my $line( @{$cidr->list} ) { print "$line\n"; } 试了下把之前100多W个段合并到5K多个段。另外如果习惯使用python的话也可以使用cidrize模块进行ip段的合并操作。 #!/usr/bin/env python import cidrize import sys import string def ipmerge(str): obj=cidrize.optimize_network_range(str) return "; \n".join(cidrize.output_str(obj).split(", "))+"; " def main(): if len(sys.argv)!=2: print “./ipmerge.py ipfile.txt” sys.exit(1) try: fd=open(sys.argv[1],“r”) except IOError as e: print “open ip file failed,",e lines=”" for line in fd: lines += line.rstrip(";\n")+"," lines=lines.rstrip(",") print ipmerge(lines) if name == “main”: main() ...

有的时候需要一个简单的tcp代理。其他机器通过这个机器做代理上网。可以选择在这个服务器上部署squid之类的做透明代理，不过简单期间也可以直接使用ssh隧道转发，有大家用ssh翻墙的方式有点类似。比如有A，B，C三台机器，只有C能上外网。除了在A，B上使用ssh -D xxx C的形式外，也可以就在机器C上开一个允许外部访问的端口。在机器C上运行：ssh -g -D 8080 127.0.0.1 然后在机器A，B就设置代理IP为C的IP，端口8080上网了。主要是-g允许外部主机访问本地转发的端口。``` -g 允许远端主机连接本地转发的端口.