拓扑:

使用ansible快速部署一个主流的Web架构_第1张图片

 

 

拓扑说明:

  1. 两台服务器配置Keepalived+Nginx做双主模型的Load Balance,主机名为lb1和lb2

  2. 两台服务器配置lamp,用于处理动态资源请求,主机名为lamp1和lamp2

  3. 两台服务器配置varnish作为静态资源缓存服务器,主机名为varnish1和varnish2

  4. 两台服务器配置Nginx用于处理静态资源请求

  5. 额外需要一台服务器安装ansible,使用ansible批量管理所有服务器

 

 

关键技术点:

1. Keepalived配置了邮件报警脚本,当节点的状态发生改变时,会发送报警邮件(脚本中的邮箱需修改)

 

2. Load Balance部分使用Nginx进行动静分离

 

3. 调度动态资源流量时,为了绑定session会话,使用的是ip_hash算法,如果使用sticky方式调度,需要调整缓存规则,否则访问静态资源时由于拥有cookie信息,资源无法被缓

 

4. 调度静态资源流量时,为了提高缓存命中率,使用的是ip_hash算法。可以考虑使用consistent_hash算法(一致性哈希)。但经过测试,Nginx使用consistent_hash算法时,无法实现对后端服务器的健康状态监测以及故障转移。因此,如果需要使用consistent_hash算法,建议使用Tengine

 

5. 关于静态资源缓存部分,使用的是多层级缓存。前端LB上,Nginx配置了proxy_cache,用于存放少部分热点数据,后端Varnish上存放经常被访问的数据。由于测试用,前端LB上缓存的时间很短

 

6. 所有web服务每天会分割一次access_log

 

7. 在响应报文中添加自定义Hearder,可显示相应资源是从哪台服务器上获取的,便于以后排错

 

 

还可以进一步改进的地方:

1. 实验配置中的缓存策略可以进一步修改和优化

 

2. varnish的日志服务还未配置

 

3. 可以使用Tengine替代Nginx,使用consistent_hash算法提高缓存命中率的同时,分散缓存的存储位置

 

4.    关于ansible的安全隐患:

由于使用密钥方式进行通信,因此一旦ansible server被非法登录,其他被管理节点也存在被篡改的风险。因此,可考虑专门创建一个ansible用户用于和其他被管理节点使用密钥方式进行ssh通信,其他用户如果需要使用ansible来管理服务器,需要sudo至ansible用户来执行ansible命令,这样在日志中会有相应的记录

 

 

实验环境:

 

所有服务器ssh端口号: 2222

 

ansibleserver与被管理节点的通信方式:  使用密钥方式进行ssh通信,remote_user为root

 

所有服务器使用hosts来解析主机名,因此所有服务器的hosts需要保持一致

 

 

ansible_server   Centos7.2

192.168.1.200

 

lb1  Centos 7.2

192.168.1.202

 

llb2  Centos 7.2

192.168.1.203

 

varnish1  Centos 7.2

192.168.1.208

 

varnish2  Centos 7.2

192.168.1.209

 

lamp1 Centos 6.5

192.168.1.101

 

lamp2 Centos 6.5

192.168.1.102

 

static_server1 Centos 7.2

192.168.1.205

 

static_server2 Centos 7.2

192.168.1.206

 

 

最终效果:

使用ansible快速部署一个主流的Web架构_第2张图片

 

使用ansible快速部署一个主流的Web架构_第3张图片

 

 

附件为ansible所需的所有配置文件,包含了实验中所需的所有角色,一共是两个压缩分卷。感兴趣的可以下载测试