拓扑:前端
拓扑说明:web
两台服务器配置Keepalived+Nginx作双主模型的Load Balance,主机名为lb1和lb2算法
两台服务器配置lamp,用于处理动态资源请求,主机名为lamp1和lamp2后端
两台服务器配置varnish做为静态资源缓存服务器,主机名为varnish1和varnish2缓存
两台服务器配置Nginx用于处理静态资源请求安全
额外须要一台服务器安装ansible,使用ansible批量管理全部服务器服务器
关键技术点:cookie
1. Keepalived配置了邮件报警脚本,当节点的状态发生改变时,会发送报警邮件(脚本中的邮箱需修改)session
2. Load Balance部分使用Nginx进行动静分离ssh
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所需的全部配置文件,包含了实验中所需的全部角色,一共是两个压缩分卷。感兴趣的能够下载测试