BBR介绍 BBR (Bottleneck Bandwidth and RTT)算法对弱网络下提升性能有一定帮助。虽然说在国内很多公司也都内部有类似的内核协议栈的改进，并且很多的效果都不比google差，但是这个好歹是进入了kernel 主干的，大家都可以自由使用。 centos7 编译升级 centos编译内核rpm yum -y install gcc ncurses ncurses-devel bc openssl–devel perl-devel make localmodconfig make menuconfig # 选中BBR grep -i bbr .config #确认是否选中 make rpm ### 修改引导项目 grub2-set-default 0 grub2-mkconfig -o /boot/grub2/grub.cfg 重启后查看 [root@CentOS ipv4]# uname -a Linux CentOS 4.9.0 #1 SMP Sat Dec 17 00:47:52 CST 2016 x86_64 x86_64 x86_64 GNU/Linux [root@CentOS ipv4]# sysctl net.ipv4.tcp_available_congestion_control net.ipv4.tcp_available_congestion_control = bbr reno cubic ## ubuntu 16.04升级 因为我买AWS EC2的时候忘记选磁盘了，磁盘只有8G，造成本地编译内核的时候发现编译不了。就网上找了几个deb包直接安装上了。 ```bash wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9/linux-image-4.9.0-040900-generic_4.9.0-040900.201612111631_amd64.deb wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9/linux-headers-4.9.0-040900-generic_4.9.0-040900.201612111631_amd64.deb get http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9/linux-headers-4.9.0-040900_4.9.0-040900.201612111631_all.deb ...

http段增加配置 server { listen 80; server_name status.taobao.com; location = /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } }

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

直接把这个服务关闭了，测试了不影响带外登陆。 [email protected]: service.dead: - enable: False - provider: systemd

使用calico的ipam dirver创建网络 如果使用docker默认的ipam创建calico网络，则不支持访问策略控制。1. 创建pool 创建network 更新profile增加2个互相访问 创建容器测试 1. 使用vnet1/vnet2分别创建2个容器docker run --name vnet1 -d --net vnet1 acs-reg.sqa.alipay.net/min.peng/minios /sbin/initdocker run --name vnet2 -d --net vnet2 acs-reg.sqa.alipay.net/min.peng/minios /sbin/init 说明 1. 可以直接使用默认的docker的ipam-driver 创建网段，但是那样就没法做策略了,且nat-outgoing和ipip的选项实际是全开的。比如docker network create --driver calico --opt nat-outgoing=true --opt ipip=false --subnet=10.20.0.0/22 vnet1docker network create --driver calico --opt nat-outgoing=true --opt ipip=false --subnet=10.30.0.0/22 vnet2 使用了ipam-driver calico的话，内部的服务没法对外暴露端口。。但是nat-outgoing和ipip的配置是生效， 3. 参考文档http://docs.projectcalico.org/v1.5/getting-started/docker/tutorials/basic

目标 对比一下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

之前网上都传PHP7得性能相对于PHP5有大幅的提升。简单做了一次升级 rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm yum remove -y php-common && yum install php70w-fpm php70w-opcache php70w-mysql systemctl restart php-fpm 对比一下升级前后的首页cache不命中时RT变化 0.363s VS 0.097。可以确定升级后的rt有大幅下降。

乘着双11的时候在阿里云买了一台vm，替换之前申请的AWS的机器。因此大陆访问AWS的机器实在是卡的不能用。。此次乘着重新迁移，把wordpress部署写成了一个salt的sls文件。 www-data: user.present: - shell: /bin/false - createhome: False group.present: - addusers: - www-data blog-pkgs: pkg.installed: - pkgs: - nginx - mariadb-server - php-fpm - php-mysql - php - tcpdump {% for d in ["log/mysql","run/mysqld" ]: %} /var/{{d}}: file.directory: - user: mysql - group: mysql - recurse: - user - group - makedirs: true {% endfor %} {% for d in [ "/var/log/nginx/","/var/cache/nginx","/var/lib/nginx/tmp/fastcgi"]: %} {{d}}: file.directory: - user: www-data - group: www-data - makedirs: true - require: - user: www-data {% endfor %} {% for f in ["dhparam.pem","server.crt.2016","server.key.2016"]: %} /etc/nginx/cert/{{f}}: file.managed: - source: salt://base/conf/nginx/{{f}} - makedirs: true {% endfor %} mariadb: service.running: - enable: True - reload: True - watch: - file: mysql-conf - require: - file: mysql-conf php-fpm: service.running: - enable: True - reload: True - watch: - file: php-conf - require: - file: php-conf nginx: service.running: - enable: True - reload: True - watch: - file: /etc/nginx/conf.d/443.conf - require: - user: www-data nginx_reload: cmd.wait: - name: systemctl reload nginx - watch: - file: /etc/nginx/conf.d/443.conf - file: /etc/nginx/nginx.conf - file: /etc/nginx/fastcgi_params php_reload: cmd.wait: - name: systemctl reload php-fpm - watch: - file: php-conf /etc/nginx/conf.d/443.conf: file.managed: - source: salt://base/conf/nginx/443.conf - template: jinja /etc/nginx/nginx.conf: file.managed: - source: salt://base/conf/nginx/nginx.conf - template: jinja /etc/nginx/fastcgi_params: file.managed: ...