System

1. 基本统计 - /var/www/blog/wp-content/themes/twentyten/header.php 的后添加 <script type="text/javascript"> var _speedMark = new Date(); </script> 2. 测速统计 - /var/www/blog/wp-content/themes/twentyten/footer.php

目标 对比一下docker overlay、calico和host网络的带宽，延迟。 测试环境硬件 千兆网卡 BCM5719 CPU E5-2630 0 @ 2.30GHz 测试环境软件 kernel 3.10.0-327 docker 1.12.3 calico 0.23.0 测试的compose 1. calico compose netperf1: image: netperf:1.0 net: vnet restart: always mem_limit: 20480M labels: - "com.alipay.proj=netperf" environment: - "affinity:container!=*netperf*" - "constraint:node==*test1*" command: /sbin/init netperf2: image: netperf:1.0 net: vnet restart: always mem_limit: 20480M labels: - "com.alipay.proj=netperf" environment: - "affinity:container!=*netperf*" - "constraint:node==*test2*" command: /sbin/init 2. overlay compose netperf1: image: netperf:1.0 net: vxlan restart: always mem_limit: 20480M labels: - "com.alipay.proj=netperf" environment: - "affinity:container!=*netperf*" - "constraint:node==*test1*" command: /sbin/init netperf2: image: netperf:1.0 net: vxlan restart: always mem_limit: 20480M labels: - "com.alipay.proj=netperf" environment: - "affinity:container!=*netperf*" - "constraint:node==*test2*" command: /sbin/init 3. host compose netperf1: image: netperf:1.0 net: host restart: always mem_limit: 20480M labels: - "com.alipay.proj=netperf" environment: - "affinity:container!=*netperf*" - "constraint:node==*test1*" command: /sbin/init netperf2: image: netperf:1.0 net: host restart: always mem_limit: 20480M labels: - "com.alipay.proj=netperf" environment: - "affinity:container!=*netperf*" - "constraint:node==*test2*" command: /sbin/init 测试结果 1. host [root@satest1 /]# time qperf netperf_netperf2_1 –time 20 tcp_bw tcp_lat udp_lat ...

之前为了测试，直接使用pipework把宿主机器上的一张网卡塞到容器内，整个过程如下 /usr/sbin/pipework –direct-phys enp6s0f3 106aac56d226 192.170.100.202/24 docker inspect ‘–format={{ .State.Pid }}’ 106aac56d226 DOCKERPID=44810 NSPID=44810 ln -s /proc/44810/ns/net /var/run/netns/44810 ```bash ip link show enp6s0f3 ip link set enp6s0f3 up ip link set enp6s0f3 netns 44810 ip netns exec 44810 ip link set enp6s0f3 name eth1 ipcalc -b 192.170.100.202/24 ```bash ip netns exec 44810 ip addr add 192.170.100.202/24 brd 192.170.100.255 dev eth1 ip netns exec 44810 ip link set eth1 up ip netns exec 44810 arping -c 1 -A -I eth1 192.170.100.202

1. docker网络现状 当前虽然docker网络的解决方案很多，但是docker官方的方案都不是太成熟，原因有以下几点：1. host/bridge这种模式只适合自己在virtualbox上玩玩,bridge模式NAT依赖contrack表在session多的时候会让你机器都登陆不上（不要YY把nf_conntrack_max配置的大点能高枕无忧）。2. 剩下的macvlan/ipvlan其实是更适合中大型企业现有VLAN模型的方案，无耐对内核的要求太高，基本就是没法用。没人会因为尝试docker把生产OS切到4.X的版本。3. 在最新版本的docker中，已经可以创建overlay的网络类型了。但是稳定性还有待考验。 在我看来，一个成熟的虚拟化网络整体方案，需要满足2个场景：1. 支持传统的基本VLAN模式，这是能在企业内快速实施的基础条件。因此现在大家的企业对docker的扩展都是在用ovs之类的支持vlan。2. 支持overlay，但是这个overlay不是纯孤立的一个网络。需要能做到跨network的联通，也要能做到与真实网络的打通。 2. 尝试过的docker网络方案 目前尝试过calico和官方的overlay方案。 2.1 calico方案 calico本质上是自己在一组机器上创建一个BGP网络，自己控制一个虚拟网络中下一跳得路由，三层能通的机器都部署calico。如果是在共有云的机器上，因为大家都会在宿主机器上做arp绑定等控制，只需要加一下IPIP让豹纹发出之前做一次ipip封装即可。对calico的测试用得比较多，一个主管的判断就是：能用，不够可靠。所谓的不够可靠主要体现在几方面：1. 有时扩容一个节点，calico-node容器死活起不来，无奈的时候只能把KVstore整个目录干掉，相当于整个集群铲了重建。2. 一个机器重启，发现起不来了。。然后整个集群重建。 2.2 官方overlay的方案 官方overlay的方案相对来说会更可靠，因为它会随着docker每个release的版本不断成熟。相关的例子可以参考nginx商业化后的行为，天然会排斥一些和自己有竞争关系的公司的方案。官方的overlay本质上是走vxlan，性能上可能会calico稍微差一些。 3. 部署案例 3.1 swarm部署 3.1.1 etcd部署每个方案的实施都是需要先部署一个swarm集群。swarm部署的基础关键在准备好一套KV的方案。因此是简单的测试，所有我做的比较简单 hostname -i 3.1. 2 swarm部署挑选3个机器部署swarm的管理节点 然后所有的节点起agent join上去 3.2 官方overlay部署 管方的overlay配置比较简单 需要注意指明overlay使用的宿主机器网卡 3.3 calico部署 1. 部署$ echo " export ETCD_ENDPOINTS=http://XXXX:2379" >> /etc/profile$ source /etc/profile; calicoctl node --libnetwork$ source /etc/profile; calicoctl statusXXX:calico-node container is running. Status: Up 48 secondsIPv4 BGP statusIP:XXXX.37 AS Number: 64511 (inherited)+--------------+-------------------+-------+----------+-------------+| Peer address | Peer type | State | Since | Info |+--------------+-------------------+-------+----------+-------------+| XXXX.22 | node-to-node mesh | up | 06:04:52 | Established || XXXX.23 | node-to-node mesh | up | 06:04:52 | Established || XXXX.39 | node-to-node mesh | up | 06:04:52 | Established |+--------------+-------------------+-------+----------+-------------+ 使用docker的ipam driver 创建网络(支持端口暴露，不支持策略控制)$docker network create –driver calico –opt nat-outgoing=true –opt ipip=false –subnet=10.10.0.0/22 vnet$docker network create –driver calico –opt nat-outgoing=true –opt ipip=true –subnet=10.11.0.0/22 ipipnet 使用calico自己的IPAM（支持访问策略控制，不支持端口暴露）$calicoctl pool add 100.100.1.0/24 –nat-outgoing$calicoctl pool add 100.100.2.0/24 –nat-outgoing$docker network create –driver calico –ipam-driver calico –subnet=100.100.1.0/24 vnet1$docker network create –driver calico –ipam-driver calico –subnet=100.100.2.0/24 vnet2

任何一个服务的规模达到一定量级都会出现各种瓶颈点，传统的IDC内部DNS也不例外。根据多年的实际经验把工作中遇到的点集成到了一个图。主要瓶颈点：1. DNS记录更新瓶颈2. DNS同步瓶颈3. DNS缓存应答瓶颈4. DNS递归瓶颈 到底多大规模的内网DNS系统能称为大？个人定6个9标准：1. IDC数量至少9个。2. 域名全网生效SLA 9s内。3. 一个IDC的DNS数量大于9台。4. 调用DNS API的外部业务系统至少9个。5. 单个机房DNS服务的范围超过9999台服务器。6. DNS系统内的域名zone数量超过99个。 如果你管理的内网DNS系统规模满足一半以上的条件，想必你也会遇到各种奇葩的问题。从上图给出的几个瓶颈点出发几个优化的建议： 控制外部API的调用并发，如果有的系统需要批量更新大量的域名，可以使用合并发送nsupdate操作的模式，注意单个nsupdate报文不要超过65535字节. dns master服务器最好使用SSD服务器，因为nsupdate操作时zone文件的频繁会写非常消耗IO。 master上注意增大serial-query-rate以保证master的notify发送速度，估算值serial-query-rate >=slave规模*同时更新zone数量，实测发送速度可以超过2k/s。 master上增大transfers-out的值，需要>=slave规模*同时更新zone数量， slave上transfers-in transfers-per-ns 需要大于本地zone的数量，否则导致新节点启动时因超过quota值部分zone会延迟半个小时以后再同步；slave 上serial-query-rate 超过本地zone的数量。 salve机器上常备dnstop分析实时流量。 salve服务器上如果有公网IP，务必配置好iptables，放置被当作反射器去攻击他人，并经常会有国安局、公安局领导约谈。

准备干净的vm模版，clone出4台。ip规划如下enp0s3 外网网卡，桥接模式，dhcpenp0s8 内网网卡，bridge到bridge0(192.168.1.1/24) 2. 打通centos-console 到其他几个服务区的信任登陆centos-console 192.168.1.10centos-test1 192.168.1.11centos-test2 192.168.1.12centos-test3 192.168.1.13 3. 在跳板机器创建consul容器，做服务发现docker run --restart=always -d -p 8500:8500 --name=consul progrium/consul -server -bootstrap 4. 创建swarm-masterdocker-machine create --driver generic --generic-ip-address 192.168.1.11 --generic-ssh-user root --engine-registry-mirror=https://wfsgsp6x.mirror.aliyuncs.com --engine-install-url=https://get.daocloud.io/docker/ --swarm --swarm-master --swarm-discovery="consul://192.168.1.10:8500" node-master 5. 创建nodedocker-machine create --driver generic --generic-ip-address 192.168.1.12 --generic-ssh-user root --engine-registry-mirror=https://wfsgsp6x.mirror.aliyuncs.com --engine-install-url=https://get.daocloud.io/docker/ --swarm --swarm-discovery="consul://192.168.1.10:8500" node-woker1docker-machine create --driver generic --generic-ip-address 192.168.1.13 --generic-ssh-user root --engine-registry-mirror=https://wfsgsp6x.mirror.aliyuncs.com --engine-install-url=https://get.daocloud.io/docker/ --swarm --swarm-discovery="consul://192.168.1.10:8500" node-woker2 6. 查看machine[root@centos-console cert]# docker-machine lsNAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORSnode-master - generic Running tcp://192.168.1.11:2376 node-master (master) v1.12.0node-woker1 - generic Running tcp://192.168.1.12:2376 node-master v1.12.0node-woker2 - generic Running tcp://192.168.1.13:2376 node-master v1.12.0 7. 登陆管理docker -H 192.168.1.11:3376 --tlsverify --tlscacert=/root/cert/ca.pem --tlscert=/root/cert/server.pem --tlskey=/root/cert/server-key.pem info enp0s3 外网网卡，桥接模式，dhcp ...

大家常用的bond模式主要是mode 1和4.其中mode1就是简单的主备模式，mode4是两个网卡都有流量的。以下是每种模式的简单介绍： balance-rr or 0 — Sets a round-robin policy for fault tolerance and load balancing. Transmissions are received and sent out sequentially on each bonded slave interface beginning with the first one available. broadcast or 3 — Sets a broadcast policy for fault tolerance. All transmissions are sent on all slave interfaces. 802.3ad or 4 — Sets an IEEE 802.3ad dynamic link aggregation policy. Creates aggregation groups that share the same speed and duplex settings. Transmits and receives on all slaves in the active aggregator. Requires a switch that is 802.3ad compliant. ...

1、选管理属性权值最大的路由2、选LOCAL_PREF最大的路由3、优选IGP路由，次选EGP路由4、优选AS_PATH最短的路由5、选源编码最低的路由，IGP低于EGP,EGP低于incomplete的路由6、选MULTI_EXIT_DISC最低的路由7、优选EBGP路由，次选联盟EBGP路由8、选NEXT_HOP最近的路由9、如果以上属性都相同，切都来自同一个临近的AS，且启用了BGP多路径就是ecmp。10、如果没有启用BGP多路径，就选路由器ID最小的路由。 PS：本来前面差不多写完了所有的BGP路由熟性，不小心刷了一下搞没了。懒得写了，其实都是从书上摘下来的。也可以看看这个。 [这个](http://mt.cucn.edu.cn/net/%E8%B5%84%E6%96%99%E4%B8%8B%E8%BD%BD/cisco/BGP%E8%B7%AF%E7%94%B1%E5%8D%8F%E8%AE%AE%E8%AF%A6%E8%A7%A3(%E5%AE%8C%E6%95%B4%E7%AF%87).pdf)附上H3C的文档

有的时候需要一个简单的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 允许远端主机连接本地转发的端口.

公司大量的服务器使用了intel的网卡，主要是intel I350/82580/82576。 各个版本的igb驱动都出现过detected tx unix hang的报错。大部分是老版本igb的bug，更新到新版后基本都解决了。不过最近发现有几台I350（4端口）的升级了驱动还是存在这样的报错。Detected Tx Unit Hang in Quad Port Adapters http://downloadmirror.intel.com/20927/eng/e1000.htmIn some cases ports 3 and 4 don’t pass traffic and report ‘Detected Tx Unit Hang’ followed by‘NETDEV WATCHDOG: ethX: transmit timed out’ errors. Ports 1 and 2 don’t show any errors and will pass traffic.This issue MAY be resolved by updating to the latest kernel and BIOS. The user is encouraged to run anOS that fully supports MSI interrupts. You can check your system’s BIOS by downloading the LinuxFirmware Developer Kit that can be obtained at http://www.linuxfirmwarekit.org/ ...