haproxy 配置基础

  1. mode health
    该模式用于健康检查，tcp层面的，只返回OK，如下：
  2. stats
    1. 通过http页面查看状态：
    2.  通过tcp socket查看状态：


      这个socket也可以是一个unix socket：(或者同时写两个都是可以的）


      使用nc也行：

      tcp（或unix模式）有很多命令可以使用
    3. 一个一般的配置

       

 

 

 

 

参考资料： http://www.ttlsa.com/linux/haproxy-study-tutorial/

haproxy sni

目标：

让haproxy实现sniproxy的功能；sniproxy可以通过简单配置允许访问任意的https，但是haproxy针对每个要访问的server进行明确的配置，不过这个已经满足我们的需求了；目前对我们来讲，haproxy中的resolvers 指令是非常需要的

配置一：

最初配置时少了tcp-request 的两个（或者任意一个选项），会导致偶尔请求失败，因为if条件没有起作用，使得总是轮训

配置方式二：

最初配置时少了tcp-request 的两个（或者任意一个选项），使得无法找到一个合适的后端，于是就SSL connect error

第三种写法：

这里的tcp-request 选项写在backend中是也是可以的，如下：

一个包含443和80的配置：

 

参考资料： http://blog.haproxy.com/2012/04/13/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/

基于sni的https负载均衡

ssl（会话层）的负载均衡介于http（应用层）负载均衡和tcp（传输层）负载均衡之间；

对于tcp（传输层）的负载均衡只能基于端口来做，访问同一个端口的请求就意味着转发到相同的后端服务器；

而对于http（应用层）的负载均衡可以介于应用层的很多东西来做，如：host、sessionid等；

对于https来讲，一般会将https证书放在负载均衡服务器上，对应用层数据解包之后再负载均衡；如果负载均衡不在自己管辖范围（亦或是处于别的原因考虑，如： 性能）而不想将证书放在负载均衡上，如何让一个负载均衡服务于多个服务呢？

这时候就可以考虑，通过sni来解析到servername之后，直接将请求通过tcp的方式转发到指定的服务，这样不需要对数据包进行解密操作，提高了性能，也更不需要将对应的证书放在负载均衡上了。

举个栗子： http://blog.haproxy.com/2012/04/13/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/

神秘的loadavg

一般来讲，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之 docker ps无响应

现象：

docker exec无法进入容器，docker ps没有响应，strace跟踪docker daemon进程未发现明显异常（基本是水平不够，所以看不出来），但是能知道docker ps之所以没有响应，是和锁有关系，应该是有一个什么操作阻塞所致。

解决过程：

  1. docker daemon的事情基本和所启动的容器有关系，可以肯定一点的是，重启daemon就能好，但是该daemon下启动着几十个虚拟机，都将会停止，影响面比较大，而且该问题将来必然还会出现；所以，重启daemon是下下策
  2. 如果能找到有问题的容器，然后杀掉该容器，或者也许能找到问题根源；但是似乎比较难
  3. 庆幸的是，从日志上基本可以知道开始出现问题的时候刚好是启动某个容器的时候，那么，很有可能是该容器导致的，不妨试一试
  4. 所有容器的1号进程都一样，子进程都相像，docker destroy、docker ps 、docker inspect都没有响应，如何杀掉指定的容器？
  5. 办法： grep 所有容器的config.json，根据容器名确定哪个config.json 是有问题的容器的，然后，该config.json 中有该容器1号进程的pid，然后取出而杀之
  6. 问题解决

其他想到的：

  1. 一般来讲，每个容器都有一个hostname，默认是容器id的前面一部分，如果能知道这个问题都好办；但是我们的hostname被自定义了，那么，在知道hostname的情况下，找容器1号进程pid非常方便，因为hostname是进程环境变量的一部分（HOSTNAME)，所以，可以：
    grep -l the_hostname /proc/*/envrion
    其中就包含容器1号进程的pid
  2. 如果能在1号进程名上区分开来会更加方便，我们的docker容器的1号进程都是/sbin/init，如果能添加一个进程/sbin/init 不会在意的多余的参数作为标识，便是极好的（一般来讲是可以的），但是测试发现给/sbin/init 添加的参数在ps的时候都是不给显示的（大概这里的init是entrypoint，不是cmd）
  3. 在创建容器的时候，给容器指定一个具有标识性的环境变量，也将有助于找到进程的pid
  4. docker top的时候，我们可以看到容器里面的进程信息，但是这里看到的进程id是容器里面的私有pid，每个私有pid都在宿主机上对应一个全局的pid，根据全局的pid也可以通过 “pstree -p 全局的pid ”来查看容器里面的所有进程，然后，还可以做到不进入容器就能strace容器里面的进程的pid
  5. nsenter和docker的exec都能进入容器里面，但是docker的exec依赖docker daemon进程，如果docker daemon进程无法响应，就不好使了；而nsenter却不依赖docker daemon进程，直接就可以进入容器内部（我没有试过哦）

stunnel vs spipe vs shadowsocks

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来实现：

  1. 将需要代理的域名，通过dns解析到stunnel
  2. stunnel_client对数据进行加密传输给stunnel_server，stunnel_server解密数据并转给sniproxy
  3. sniproxy进行代理

spipe 是基于共享秘钥加密的，没有认证功能；也有其他基于ssl的实现方式，具有认证功能，如： https://github.com/dchest/spipe

stunnel是通过ssl实现的，具有认证功能

基于ssl握手认证的实现需要配置证书相关的东西，相对共享秘钥来讲麻烦一些