简言之: 就是通过一种机制,让client告诉server自己有哪些特性,便于server能更好地为该client提供定制的服务
参考: https://imququ.com/post/http-client-hints.html
https://docs.imgix.com/tutorials/responsive-images-client-hints?_ga=1.267838798.110287679.1468903970
DevOps
简言之: 就是通过一种机制,让client告诉server自己有哪些特性,便于server能更好地为该client提供定制的服务
参考: https://imququ.com/post/http-client-hints.html
https://docs.imgix.com/tutorials/responsive-images-client-hints?_ga=1.267838798.110287679.1468903970
1 2 3 4 5 6 7 |
listen status bind *:3127 mode http stats enable stats uri / stats realm HAProxy\ Statistics stats auth statsadmin:password |
1 |
stats socket *:3126 #写在global中就可以 |
1 |
stats socket /var/lib/haproxy/stats #目录要事先创建好 |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 |
global log 127.0.0.1 local2 chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 4000 user haproxy group haproxy daemon # turn on stats unix socket stats socket /var/lib/haproxy/stats stats socket *:3126 defaults mode http log global option dontlognull retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m timeout http-keep-alive 10s timeout check 10s maxconn 30000 resolvers dns nameserver svr1 172.16.162.194:53 listen status bind *:3127 mode http stats enable stats hide-version stats uri / stats realm HAProxy\ Statistics stats auth statsadmin:password listen http_health bind *:3129 mode health listen http_tun bind *:3128 mode http option http-tunnel default_backend http_tun_backend backend http_tun_backend mode http acl acl_baidu req.hdr(host) -i www.baidu.com use-server svr_baidu if acl_baidu server svr_baidu www.baidu.com:80 resolvers dns listen http_proxy bind *:80 mode http default_backend http_backend backend http_backend mode http acl acl_baidu req.hdr(host) -i www.baidu.com acl acl_beebank req.hdr(host) -i www.beebank.com use-server svr_baidu if acl_baidu use-server svr_beebank if acl_beebank server svr_baidu www.baidu.com:80 resolvers dns server svr_beebank www.beebank.com:80 resolvers dns listen ssl_proxy bind 127.0.0.1:443 mode tcp default_backend ssl_backend backend ssl_backend tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } acl acl_baidu req_ssl_sni -i www.baidu.com acl acl_beebank req_ssl_sni -i www.beebank.com use-server svr_baidu if acl_baidu use-server svr_beebank if acl_beebank server svr_baidu www.baidu.com:443 resolvers dns server svr_beebank www.beebank.com:443 resolvers dns |
目标:
让haproxy实现sniproxy的功能;sniproxy可以通过简单配置允许访问任意的https,但是haproxy针对每个要访问的server进行明确的配置,不过这个已经满足我们的需求了;目前对我们来讲,haproxy中的resolvers 指令是非常需要的
配置一:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
defaults timeout client 30s timeout server 30s timeout connect 5s resolvers dns nameserver svr1 172.16.162.194:53 listen ssl_proxy bind 127.0.0.1:443 mode tcp tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } acl acl_baidu req_ssl_sni -i www.baidu.com acl acl_beebank req_ssl_sni -i www.beebank.com use-server svr_baidu if acl_baidu use-server svr_beebank if acl_beebank server svr_baidu www.baidu.com:443 check resolvers dns server svr_beebank www.beebank.com:443 check resolvers dns |
最初配置时少了tcp-request 的两个(或者任意一个选项),会导致偶尔请求失败,因为if条件没有起作用,使得总是轮训
配置方式二:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
defaults timeout client 30s timeout server 30s timeout connect 5s resolvers dns nameserver svr1 172.16.162.194:53 listen ssl_proxy bind 127.0.0.1:443 mode tcp tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } acl acl_baidu req_ssl_sni -i www.baidu.com acl acl_beebank req_ssl_sni -i www.beebank.com use_backend baidu if acl_baidu use_backend beebank if acl_beebank backend baidu server svr_baidu www.baidu.com:443 check resolvers dns backend beebank server svr_beebank www.beebank.com:443 check resolvers dns |
最初配置时少了tcp-request 的两个(或者任意一个选项),使得无法找到一个合适的后端,于是就SSL connect error
第三种写法:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
defaults timeout client 30s timeout server 30s timeout connect 5s resolvers dns nameserver svr1 172.16.162.194:53 listen ssl_proxy bind 127.0.0.1:443 mode tcp tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } default_backend ssl_backend backend ssl_backend acl acl_baidu req_ssl_sni -i www.baidu.com acl acl_beebank req_ssl_sni -i www.beebank.com use-server svr_baidu if acl_baidu use-server svr_beebank if acl_beebank server svr_baidu www.baidu.com:443 check resolvers dns server svr_beebank www.beebank.com:443 check resolvers dns |
这里的tcp-request 选项写在backend中是也是可以的,如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
defaults timeout client 30s timeout server 30s timeout connect 5s resolvers dns nameserver svr1 172.16.162.194:53 listen ssl_proxy bind 127.0.0.1:443 mode tcp default_backend ssl_backend backend ssl_backend tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } acl acl_baidu req_ssl_sni -i www.baidu.com acl acl_beebank req_ssl_sni -i www.beebank.com use-server svr_baidu if acl_baidu use-server svr_beebank if acl_beebank server svr_baidu www.baidu.com:443 check resolvers dns server svr_beebank www.beebank.com:443 check resolvers dns |
一个包含443和80的配置:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
defaults timeout client 30s timeout server 30s timeout connect 5s resolvers dns nameserver svr1 172.16.162.194:53 listen http_proxy bind *:80 mode http default_backend http_backend backend http_backend mode http acl acl_baidu hdr(host) -i www.baidu.com acl acl_beebank hdr(host) -i www.beebank.com use-server svr_baidu if acl_baidu use-server svr_beebank if acl_beebank server svr_baidu www.baidu.com:80 check resolvers dns server svr_beebank www.beebank.com:80 check resolvers dns listen ssl_proxy bind 127.0.0.1:443 mode tcp default_backend ssl_backend backend ssl_backend tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } acl acl_baidu req_ssl_sni -i www.baidu.com acl acl_beebank req_ssl_sni -i www.beebank.com use-server svr_baidu if acl_baidu use-server svr_beebank if acl_beebank server svr_baidu www.baidu.com:443 check resolvers dns server svr_beebank www.beebank.com:443 check resolvers dns |
ssl(会话层)的负载均衡介于http(应用层)负载均衡和tcp(传输层)负载均衡之间;
对于tcp(传输层)的负载均衡只能基于端口来做,访问同一个端口的请求就意味着转发到相同的后端服务器;
而对于http(应用层)的负载均衡可以介于应用层的很多东西来做,如:host、sessionid等;
对于https来讲,一般会将https证书放在负载均衡服务器上,对应用层数据解包之后再负载均衡;如果负载均衡不在自己管辖范围(亦或是处于别的原因考虑,如: 性能)而不想将证书放在负载均衡上,如何让一个负载均衡服务于多个服务呢?
这时候就可以考虑,通过sni来解析到servername之后,直接将请求通过tcp的方式转发到指定的服务,这样不需要对数据包进行解密操作,提高了性能,也更不需要将对应的证书放在负载均衡上了。
一般来讲,cpu使用率和iowait都会导致系统的loadavg很高,而且很多人也只限于cpu使用率和iowait导致系统的loadavg很高,于是,发现loadavg很高时,赶紧看看是cpu导致的还是iowait导致的,一般来讲都能很快定位问题;但是当发现cpu使用率几乎为0,iowait几乎为0,但是loadavg奇高便目瞪口呆了。
其实,不仅io等待会影响loadavg,其它资源的等待(如: 内存)也会导致loadavg的升高,只是很少遇到而已;一般来讲,进程在申请资源的时候,进程状态标识为D,如果很多进程状态为D,或者某些进程长时间处于状态D,都将导致loadavg的升高,而且进程的这种状态是非可中断的,试图发现阻塞在哪里的时候,发现的却是,strace的时候,strace没有响应,ltrace的时候,ltrace没有响应,pstack的时候,pstack没有响应,甚至ctrl+c都无法终止,幸运的话,ctrl+z可以推到后台并停止,然后kill 之
一般来讲,问题只要容易重现,就容易解决,不容易重现,就比较麻烦;尤其,等待内存资源的情况不太常见,如果真的没有内存了,你还能继续调试吗?而且默认情况下,当没有内存的时候,系统便会祭出oom来大开杀戒了;那么如何模拟呢?
docker给我们提供了限制内存使用(其实是cgroup)功能,而且可以设置禁用oom,那么,这就够了;在禁用oom的情况下,限制内存使用1g(注意最好禁用swap),然后启动容器,运行一个程序试图在容器里面申请2g的内存,我们将会发现进程申请1g内存之后卡住不动,系统cpu不高、iowait不高,loadavg在慢慢攀升
一个真实的情景:
在不晓得docker默认存储空间107G的情况下,把存储空间用满了,然后iowait很高,系统的loadavg也很高
现象:
docker exec无法进入容器,docker ps没有响应,strace跟踪docker daemon进程未发现明显异常(基本是水平不够,所以看不出来),但是能知道docker ps之所以没有响应,是和锁有关系,应该是有一个什么操作阻塞所致。
解决过程:
其他想到的:
执行docker centos6的容器里面的/sbin/init 0 无法退出容器:
执行完/sbin/init 后,sshd进程以及其他一些进程都退出了,但是容器并没有停止,docker exec 进去发现卡在了 umount 进程,strace该进程时,发现阻塞在write系统调用,具体没再往下查了(有时间再研究)
shadowsocks ~= spipe + socket5_proxy
即:
shadowsocks_client —–基于共享密码的加密数据—-> shadowsocks_server(解密数据,并将解密后的数据作为socket5协议来处理)
spipe和stunnel只是简单的数据的加密传输
如果client支持socket5代理,则使用shadowsocks比较方便;如果client不支持socket5代理,则需要在shadowsocks_client 前面添加一个支持socket5代理的proxy,如:(polipo)
如果client不支持任何代理设置,则可以通过一个自建的dns+stunnel+sniproxy来实现:
spipe 是基于共享秘钥加密的,没有认证功能;也有其他基于ssl的实现方式,具有认证功能,如: https://github.com/dchest/spipe
stunnel是通过ssl实现的,具有认证功能
基于ssl握手认证的实现需要配置证书相关的东西,相对共享秘钥来讲麻烦一些
Centos7之前,我们都通过service命令来管理(启动、停止、重启)服务,通过chkconfig来管理服务的自启动; 然而,这两个命令并不属于同一个软件包, service命令属于initscripts软件包,chkconfig是一个单独的chkconfig软件包。
service命令非常好用,但是服务名和操作的顺序不太符合一些人的口味,如: service mysql start ; 有些人就经常写做: service start mysql
而,chkconfig虽然可以添加、查看服务,但是添加的服务脚本也有一点苛刻,脚本中需要添加:
1 2 |
# chkconfig: 2345 20 80 # description: some desc |
别以为这是注释,没有的话,chkconfig add是不认的,如果不chkconfig add的话,chkconfig也list不出来你的服务的。
Centos7中服务的管理使用的是systemctl, 他是systemd软件包中的一个命令,该命令不仅仅管理服务,包括关机都能管
几个关键路径:
参考资料: http://www.linuxidc.com/Linux/2015-04/116648.htm
systemd-vs-sysVinit-cheatsheet