微信搜索superit|邀请体验:大数据, 数据管理、OLAP分析与可视化平台 | 赞助作者:赞助作者

Nginx的集群和负载均衡

nginx aide_941 9℃

撸了今年阿里、腾讯和美团的面试,我有一个重要发现…….>>
Nginx的集群和负载均衡

负载均衡配置案例1
设置上游服务器:
# 设置上游服务器:
upstream imgserver{
#weight权重 maxfails错误次数 fail_timeout超时时间.down 表示单前的server暂时不参与负载.其它所有的非backup机器down或者忙的时候,请求backup机器. 在upstream里设置ip_hash,就可以针对同一个C类地址段中的客户端选择同一个后端服务器可以解决session问题. Sticky基于cookie的负载均衡.
ip_hash; # 建议不要和Sticky同时使用;
Sticky; #建议不要和ip_hash同时使用;
server 192.168.1.100:80; weight:2 max_fails=2 fail_timeout=30s;
server 192.168.1.101:80; weight:2 max_fails=2 fail_timeout=30s;
server 127.0.0.1:7070 backup;
server 127.0.0.1:9090 down;
}
下游调用
# 下游调用:
location ~ \.(jpg|jpeg|png|gif) {
#转发到上游服务器的地址池
proxy_pass imgserver;
# 将用户的IP信息同时带过去,要不然,后端服务器获得的IP地址将是代理服务器的IP;
proxy_set_header X-Forwarded-For $remote_addr;
}

负载均衡案例2,通过ip_hash
ubuntu 下负载均衡搭建
1准备条件 服务器最少3台

修改配置文件:
cd /etc/nginx/conf.d/

1.添加一个配置文件
upstream a.com {
server 服务器IP:端口;
server 127.0.0.1:80;
server 127.0.0.1:8080;
}

2 配置虚拟主机

vim /etc/nginx/sites-available/default

server{
listen 80;
server_name a.com;
location / {
proxy_pass http://自己配置;(转发到哪里)
}

ln -s /etc/nginx/sites-available/{nidepaizhi} /etc/nginx/sites-enabled/

//检查配置文件是否有错
nginx -t
//重启服务器
nginx -s reload

3其他参数配置
扩展:

1.轮询(默认方式)

每个请求按时间顺序逐一分配到后端服务器,如果后端服务器down掉,能自动剔除

2 weight

指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。
upstream bakend {
server 服务器IP:端口 概率值;
server 127.0.0.1:80 weight=10;
}
3 ip_hash

每个请求按访问ip的hash结果分配,

这样每个访客固定访问一个后端服务器,可以解决session的问题

upstream resinserver{

ip_hash;

server 192.168.159.10:8080;

server 192.168.159.11:8080;

}

4

location / {
proxy_pass http://a.com; #这个地址一定是上面定义的负载均衡的名字
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

均衡策略:
我之前所常用的策略:
基于cookie值区别用户做负载均衡.(在cookie储存sessionID,通过sessionID进行判断)
通过redis直接使用redis保存用户的的登录信息进行判断.
nginx可以根据客户端IP进行负载均衡,在upstream里设置ip_hash,就可以针对同一个C类地址段中的客户端选择同一个后端服务器,除非那个后端服务器宕了才会换一个,可以解决session问题.。
Sticky基于cookie的负载均衡.

我现在的均衡策略:
就是不配Sticky或ip_hash直接用按权重轮训就行了, session同步什么的都不用担心.现在都把session存在Redis中了.
百度转载的五种均衡分配方式: nginx可以根据客户端IP进行负载均衡,在upstream里设置ip_hash,就可以针对同一个C类地址段中的客户端选择同一个后端服务器,除非那个后端服务器宕了才会换一个。 nginx的upstream目前支持的5种方式的分配

1、轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。
upstream backserver {
server 192.168.0.14;
server 192.168.0.15;
}

2、指定权重
指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。
upstream backserver {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
}

3、IP绑定 ip_hash
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。
upstream backserver {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}

4、fair(第三方)
按后端服务器的响应时间来分配请求,响应时间短的优先分配。
upstream backserver {
server server1;
server server2;
fair;
}

5、url_hash(第三方)
按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。
upstream backserver {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}

在需要使用负载均衡的server中增加

proxy_pass http://backserver/; #转发到哪里去
upstream backserver{
ip_hash;
server 127.0.0.1:9090 down; (down 表示单前的server暂时不参与负载)
server 127.0.0.1:8080 weight=2; (weight 默认为1.weight越大,负载的权重就越大)
server 127.0.0.1:6060;
server 127.0.0.1:7070 backup; (其它所有的非backup机器down或者忙的时候,请求backup机器)
}

max_fails :允许请求失败的次数默认为1.当超过最大次数时,返回proxy_next_upstream 模块定义的错误

fail_timeout:max_fails次失败后,暂停的时间

 

 

 

 

Ansible安装完后使用ssh进行连接测试

liglewang 2017-07-28 00:15:31 10475 收藏
展开
在安装ansbile后,都会写个简单配置文件,测试ansible管理与目标机的连通性,如测试ping

我的hosts文件
[rems2@rems2 playbooks]$ cat hosts
testserver ansible_ssh_host=127.0.0.1 ansible_ssh_user=root
1
2
环境有限,测试与本机的连通性,使用root用户

执行测试机报错信息
[rems2@rems2 playbooks]$ ansible testserver -i hosts -m ping
testserver | UNREACHABLE! => {
“changed”: false,
“msg”: “Failed to connect to the host via ssh: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).\r\n”,
“unreachable”: true
}
1
2
3
4
5
6
这个问题郁闷了好大一会,在macos上没遇到过问题

问题原因
原因在于没有在ansible管理节点上添加目标节点的ssh登陆认证信息。

1. ansible管理节点生成ssh-key
# ssh-keygen
1
执行成功后,将会在~/.ssh目录下生成2个文件:id_rsa和id_rsa.pub

2. 添加目标节点的ssh认证信息
[rems2@rems2 .ssh]$ ssh-copy-id root@127.0.0.1 —>我这里是连的本机
The authenticity of host ‘127.0.0.1 (127.0.0.1)’ can’t be established.
ECDSA key fingerprint is 2f:d6:db:35:4f:6d:7b:76:aa:c2:51:7f:8d:ec:91:6c.
Are you sure you want to continue connecting (yes/no)? yes
/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed — if you are prompted now it is to install the new keys
root@127.0.0.1’s password:

Number of key(s) added: 1

Now try logging into the machine, with: “ssh ‘root@127.0.0.1′”
and check to make sure that only the key(s) you wanted were added.
1
2
3
4
5
6
7
8
9
10
11
12
测试ansbile
[rems2@rems2 playbooks]$ ansible testserver -i hosts -m ping
testserver | SUCCESS => {
“changed”: false,
“ping”: “pong”
}
1
2
3
4
5
OK了
————————————————
版权声明:本文为CSDN博主「liglewang」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/liglewang/article/details/76223290

转载请注明:SuperIT » Nginx的集群和负载均衡

喜欢 (0)or分享 (0)