一般我们在服务涉及多个网段的时候是直接配置一下策略路由，达到哪个口进哪个口出的目的。最近手上又批机器，因为各种原因。机器上2个网卡各上联到不通的交换机，每个网卡配置的IP也是不同的。考虑到单个交换机挂掉的情况，我就直接配置了2个默认的网关，设置不同的优先级。配置相对简单，单个交换机挂掉的时候还能工作。
<br />#cat route-eth0
default via 10.20.25.1 metric 1
[root@test /etc/sysconfig/network-scripts]
#cat route-eth1
default via 10.20.25.12 metric 2
[root@test/etc/sysconfig/network-scripts]
#
另外需要注意设置一下rp_filter允许从1个网卡进来的包走另外一个网卡出去。
<br />net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
今天有同学不小心在/etc/profile.d/下的一个脚本里加了一个exit。然后就杯具了，无论如何都登录不进去，试过了ssh，rsync，sftp都不行。
/etc/profile.d/下的配置文件会在/etc/profile生效的时候顺便被执行了一遍，其实bash是可以指定不读取配置文件，直接进去把对应的文件有sed修改好就行了。
sudo ssh -t 192.168.1.6 "bash --noprofile ;sed -i 's/exit//' /etc/profile.d/xxx.sh "
无论是权威还是递归DNS，防攻击都是特别需要的。但是现在一般开源的bind在这方面又总是有些欠缺。最近一段时间一直在查看相关的文档。
对于普通的ISP的递归DNS，一方面只允许自己的客户IP段来递归，另外可以配合使用rrl限流模块。rrl限流模块在有大量请求的时候还是可以起到不少作用的。只是这个限流的值需要把握好。
对于自己单独搞的递归DNS。类似114的这种，一般使用anycast模式，多个机房间用BGP进行流量分配，硬抗的能力能提升不少;另外就是做流量清洗，可以学习到每个IP段正常的DNS请求进入时候的TTL值，一般的DNS伪造的攻击很难试出这个正常的TTL值。
最简单的模式，也可以抓包做流量分析，直接把疑似黑名单封了。
线上经常因为系统盘的故障或者是SAS卡驱动的问题使得/或者/home掉了，那么ssh信任登录的时候就会因为找不到AuthorizedKeysFile里面指定的文件而造成无法登录服务器。
解决的思路就是可以设置多个authorized_keys,比如放一份到内存里面（可能会存在一些安全问题，不过内部系统应该可控）。openssh到5.8版本以上，可以AuthorizedKeysFile后面支持多个路径，之前的版本比如centos 5(OpenSSH_4.3p2)的可以设置AuthorizedKeysFile2。
sshd_config设置
AuthorizedKeysFile %h/.ssh/authorized_keys /sshkeys/.ssh/authorized_keys
或者
AuthorizedKeysFile2 /sshkeys/.ssh/authorized_keys
需要注意/run/shm/或者/dev/shm的权限问题。最好在根文件系统下单独建立个目录，把shm下的bind过去
mount –bind /dev/shm/sshkeys/ /sshkeys/
登录的时候可以看到服务端会读取2个authorized_keys文件。
Sep 6 14:24:07 root sshd[17173]: debug1: userauth-request for user root service ssh-connection method publickey
Sep 6 14:24:07 root sshd[17173]: debug1: attempt 2 failures 1
Sep 6 14:24:07 root sshd[17172]: debug1: temporarily_use_uid: 0/0 (e=0/0)
Sep 6 14:24:07 root sshd[17172]: debug1: trying public key file /root/.ssh/authorized_keys
Sep 6 14:24:07 root sshd[17172]: debug1: restore_uid: 0/0
Sep 6 14:24:07 root sshd[17172]: debug1: temporarily_use_uid: 0/0 (e=0/0)
Sep 6 14:24:07 root sshd[17172]: debug1: trying public key file /sshkeys/.ssh/authorized_keys
Sep 6 14:24:07 root sshd[17172]: debug1: matching key found: file /sshkeys/.ssh/authorized_keys, line 8
~
time-wait其实本来没有啥，但是经常成为让大家恐惧的东西。比如大家一直在试图降低web服务器、代理服务器上的time-wait数量。
time-wait本身的作用是提供全双工关闭、过时重复报文段失效，其实也没有什么。唯独是在做反向代理的时候需要特别注意time-wait过多的情况，
主要是做代理的时候容易出现tw状态过多把本地端口耗完的情况。一般缓解的方法：
1. 改成使用长连接去连后端的服务器。
2. 修改ip_local_port_range增加可用的端口范围
3. 同时打开tcp_tw_reuse和tcp_timestamps选项，这样收到最后1个包后1s后可以开始重用。这个是在tcp_ipv4.c里定义的
/* With PAWS, it is safe from the viewpoint
of data integrity. Even without PAWS it is safe provided sequence
spaces do not overlap i.e. at data rates <= 80Mbit/sec.
Actually, the idea is close to VJ's one, only timestamp cache is
held not per host, but per port pair and TW bucket is used as state
holder.
If TW bucket has been already destroyed we fall back to VJ's scheme
and use initial timestamp retrieved from peer table.
*/
if (tcptw->tw_ts_recent_stamp &&
(twp == NULL || (sysctl_tcp_tw_reuse &&
get_seconds() - tcptw->tw_ts_recent_stamp > 1))) {
tp->write_seq = tcptw->tw_snd_nxt + 65535 + 2;
if (tp->write_seq == 0)
tp->write_seq = 1;
tp->rx_opt.ts_recent = tcptw->tw_ts_recent;
tp->rx_opt.ts_recent_stamp = tcptw->tw_ts_recent_stamp;
sock_hold(sktw);
return 1;
}
同时打开tcp_tw_recycle和tcp_timestamps选项,开启tw的快速回收，3.5个RTO后可以回收。但是如果客户端是走NAT访问的，不能设置这个选项。
人为降低tcp_max_tw_buckets设置tw的最大数量
openssl speed rsa2048 -multi 1
OS | |sign/s | verify/s
ubuntu 12.04 | OpenSSL 1.0.1 | 514.464 | 16570.7
Ubuntu 12.10 | OpenSSL 1.0.1c|518.936 | 16643.5
debian 7 | OpenSSL 1.0.1e | 531.255 | 16881.9
fedora 18 |OpenSSL 1.0.1e-fips| 514.936| 16472.8
centos 6.4 |OpenSSL 1.0.0-fips|377.027 |12570.8
总体看来，centos可能是因为本上的库比较老，openssl的性能差的太多了。
我顺便测试了一下4core和8core的VM性能
8core:
rsa 2048 bits 0.000260s 0.000008s 3840.8 130618.7
rsa 2048 bits 0.000251s 0.000008s 3989.4 130098.3
rsa 2048 bits 0.000250s 0.000008s 3994.4 129883.1
rsa 2048 bits 0.000259s 0.000008s 3868.3 129858.7
rsa 2048 bits 0.000257s 0.000008s 3886.1 128886.2
rsa 2048 bits 0.000246s 0.000008s 4068.9 128406.2
rsa 2048 bits 0.000251s 0.000008s 3981.6 130107.1
rsa 2048 bits 0.000246s 0.000008s 4064.1 130652.3
rsa 2048 bits 0.000246s 0.000008s 4065.7 129577.9
rsa 2048 bits 0.000249s 0.000008s 4012.6 127419.9
基本都是500 X 8的性能，4core的时候基本都是2K的性能（500 X4 ），整体还是很多不错的。说明至少自己多花的钱还是有价值的，基本是线性扩展的。
dd if=/dev/zero of=test1 bs=102400 count=90240 oflag=direct
dd if=test1 of=/dev/null bs=102400 count=90240 iflag=direct;
9240576000 bytes (9.2 GB) copied, 70.0601 s, 132 MB/s
90240+0 records in
90240+0 records out
9240576000 bytes (9.2 GB) copied, 21.4463 s, 431 MB/s
基本的方案是本地RAID，然后LVM划分给每个VM使用。
另外购买的存储盘的大文件速度和本地盘基本相同，下次有时间再测试一下实际的延迟时间是否有大的差异。
4.unixbenche的综合评测
跑了下单核512M内存的VM大概能到1500分左右。
前几天在国内的某VPS上充了点钱，拿来做测试机器。发现其openssl rsa2048的速度还比较快，说明CPU性能比较好。相比之前我自己的测试服务器理论上直接是物理机测试，单个core的性能却差很多。想了下可能是和openssl、glibc、gcc之类的版本有点关系。但是自己的测试服务器上又不能直接重装其他发行版。想到一起有个debootstrap的工具，就直接在centos的服务器上装了下。使用
[bash][/bash]
sudo debootstrap –arch amd64 wheezy ./wheezy/ http://centos.ustc.edu.cn/debian/
[bash][/bash]
就可以获得一个wheezy的环境.
sudo chroot wheezy /bin/bash
后安装一下openssl就可以进行测试。可以直接把多个版本都搞好，然后一个一个测试对比。
线上有的服务器停机应用比较大，单身如果又遇到网络驱动之类的有bug那就麻烦了，徘徊于等死与找死之间。想着所有的机器都是双上联做了bond的，可不可以一次升级一个网卡呢？做了bond单次挂1个网卡应该是无损的。
上周把我的这个想法给内核组的同学说了，没有想到这周就给出了具体的方案。我自己稍微测试了下，把脚本的一些细节地方修改了下昨天测试2个网卡连续切换驱动10次无丢包。
不过有实际的大流量的时候还有待验证。
传统的VPS厂商对外的时候都会比较忌讳谈超卖的比例。不过linode的FAQ上直接说名的平均的情况，到是挺不错的。
How many Linodes share a host?
Linodes of the same plan are grouped together onto a host. We adjust the number of slots on each host according to its resources and hardware specification. On average, a Linode 1GB host has 40 Linodes on it. A Linode 2GB host has on average 20. Linode 4GB host: 10 Linodes; Linode 8GB host: 5;
结合到linode的套餐其实就能大概看明白了。
每个宿主机上能跑40个1G的VM（另外比如8G内存的不超过5G），那么说明其宿主机的内存配置还可能就48G的，料想这个FAQ可能只是针对今年升级前的老机型的。老的机型应该是2个Intel(R) Xeon(R) CPU L5520 4core的CPU，配上48G内存，磁盘做raid后容量2T左右。老机型就是把16个逻辑核平均当40个逻辑核卖。
从今年最新的blog里面看到现在新的机型都是E5-2670，8core带HT。那么服务器应该内存也应该到64G或者96G了，而且现在的套餐里也多了16G内存的，在之前的48G机型这样会出现跨numa节点的访问，性能会很差。现在每个服务器上逻辑核总数32个，VM的密度不变的话单个宿主机能跑的VM数量可以翻一倍，可以节省很多机架费用(硬件价格不断下降，机架价格像房租一样不断上涨)。现在的每个VM用的都是8个core，看样子应该是开了numa，绑定了每个VM使用的CPU在一个numa节点上，这样只要没有出现跨节点的内存分配的话，VM的性能会比没有开numa的好30%左右。不同套餐的用户使用权重来分优先级。
另外从linode的blog上也能看到最新的网络架构，7K+5K+2K，比较常见的架构了。
linode这种做最轻量级的VPS厂商其实还是比较容易的，主要是看公司整体考虑，适当的提高价格，避免控制超卖的比例不够时亏本，类似brust这种超卖应该都是无比严重。。
SPF（发信方策略框架）记录就是在txt记录(现在也有专门的spf记录)里标明该域的邮件只能从指定的服务器发出，否则都是假冒的。现在有2个版本,spf1和spf2。不过被转发的邮件就不能通过SPF检查的。比如用163的邮箱给一个用gmail的人发邮件，对方又把自己的邮箱直接转发到了qq的邮箱上，这样就不能通过spf校验。
简单看看spf格式的txt记录：
dig -t txt google.com
google.com. 3600 IN TXT “v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all”
继续
dig -t txt _spf.google.com 结果是
“v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all”
再继续
v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ~all
v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all
以上就是google设置的发送邮件源IP段，如果不是这些段发送的邮件，都可能是假冒的邮件。邮件系统的反垃圾处理，其实基本都会做SPF校验,比如我自己的邮箱给gmail发邮件:
Received-SPF: pass (google.com: domain of xx AT gnuers.org designates 184.105.67.102 as permitted sender) client-ip=184.105.67.102;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of xx AT gnuers.org designates 184.105.67.102 as permitted sender) smtp.mail xx AT gnuers.org
