集群
集群是什么 :
简单来说, 集群就是指一组(若干个)相互独立的计算机, 利用欧冠甘肃通信网络组成的一个较大的计算机服务系统, 每个集群节点(即集群中的每台计算机)都是运行各自服务的独立服务器. 这些服务器之间可以彼此通信, 协同向用户提供应用程序, 系统资源和数据, 并以单一系统的模式加以管理. 当用户客户机请求集群系统时, 集群给用户的感觉就是一个单一的独立服务器, 而实际上用户请求的是一组集群服务器.
打开谷歌, 百度的页面, 看起来很简单, 也许你觉得用几分钟就可以制作相似的网页, 而实际上, 这个页面的背后是有成千上万太服务器集群协同工作的结果.
若要一句话描述集群, 即一堆服务器合作做同一件事, 这些机器可能需要整个技术团队架构, 设计和统一协调管理, 这儿写机器可以分布在一个机房, 也可以分布在全国全球各个地区的多个机房.
为什么要用集群 :
要说为什么要使用集群, 就要了解一下集群的特点!
1. 高性能
一些国家重要的计算密集型应用(如天气预报, 核试验模拟等), 需要计算机有很强的运算处理能力. 以全世界现有的技术, 即使是大型机, 其计算能力也是有限的, 很难单独完成此任务, 因为计算时间可能会相当长, 也许几天, 甚至几年或更久. 因此, 对于这类复杂的计算业务, 便使用了计算机集群技术, 几种即使上百条, 甚至成千上万台计算机进行计算.
耳熟能详的谷歌, 百度, 淘宝都不是几台大悉尼国际可以构建的, 都是上万台服务器组成的高性能集群, 分布不同的地点.
2. 价格有效性
通常一套系统集群架构, 只需要几台或者数十台服务器主机即可. 与动辄价值上百万元的专用超级计算机相比便宜了很多. 在达到同样性能需求条件下, 采用计算机集群架构比采用同等运算能力的大型计算机具有更高的性价比.
早期的淘宝, 支付宝的数据库等核心系统就是上百万元的小型服务器. 后因使用维护成本太高以及扩展设备费用成几何级数翻倍, 甚至成为扩展瓶颈, 人员维护和也十分困难, 最终使用PC服务器集群将其替换, 比如, 将数据库系统从小型机结合Oracle数据库迁移带了MySQL开源数据库结合PC服务器上来。 不但成本下降了, 扩展和为维护也跟那个容易了.
3. 可伸缩性
当服务负载, 压力增长时, 针对集群系统进行较简单的扩展即可满足需求, 且不会降低服务质量.
通常情况下, 硬件设备若想扩展性能, 不得不增加新的CPU和存储设备, 如果加不上去了, 就不得不购买更高性能的服务器. 如果采用集群技术, 则只需要将新的单个服务器加入下你又集群架构中即可, 从访问的客户角度来看, 系统服务无论是连续性还是性能上都几乎没有变化, 西永在不知不觉中完成了升级, 加大了访问能力, 轻松的实现了扩展. 集群系统中的节点数目可以增长到几千乃至上万个, 其伸缩性远超过单台超级计算机.
4. 高可用性
单一的计算机系统总会面临设备损毁的问题, 如CPU, 内存, 主板, 电源, 硬盘等, 只要一个部件坏掉, 这个计算机系统就可能会宕机, 无法正常提供服务. 在集群系统中, 尽管部分硬件和软件也会发生故障, 但是整个系统可以保证7*24小时工作.
集群架构技术可以使得系统在若干硬件设备孤战发生时仍可以继续工作, 这样就将系统的停机时间减小到了最小. 集群系统在提高系统可靠性的同时, 也大大减小了故障带来的业务损失, 目前几乎100%的互联网网站都要求7*24小时提供服务.
5. 透明性
多个独立计算机组成的松耦合集群系统构成一个虚拟服务器. 用户或客户端程序访问集群系统时, 就像访问一台高性能, 高可用的服务器一样, 集群中一部分服务器的上线, 下线不会中断整个系统服务, 这对用户也是透明的.
负载均衡
负载均衡概述
web服务器, 直接面向用户, 往往要承载大量并发请求, 单台服务器难以负荷, 而使用多态web服务器组成集群, 前端使用nginx负载均衡, 将请求分散的打到后端服务器集群中
实现负载的分发, 那么会大大提升系统的吞吐率, 请求性能, 高容灾.
nginx要实现负载均衡需要哟用到proxy_pass代理模块配置
nginx负载均衡与nginx代理不同地方在于 :
nginx代理仅代理一台服务器, 而nginx负载均衡则是将客户端请求代理转发至一组upstream虚拟服务池.
nginx可以配置代理多态服务器, 当一台服务器宕机之后, 仍能保持系统可用.
nginx负载均衡实验配置
分配服务器upstream配置 :
在nginx配置文件(nginx.conf) > http区域内 :
upstream django {server 10.0.0.10:8000;server 10.0.0.11:9000;
}
----------------------------------------------------
负载均衡池内放两个服务器, 默认以轮询的方式去调度负载均衡池内的服务器
在nginx.conf > http区域 > server区域 > location区域内添加proxy_pass :
http {
include mime.types;
default_type application/octet-stream;access_log /data/access.log main;#定义负载均衡池(即存放服务器的池子)
upstream h {
server 192.168.12.128:8000;
server 192.168.12.129:8000;}server {
listen 80;
server_name www.xd.com;location / {
root /data/xd;
index index.html index.htm;# 发送过来的请求匹配到 / , 就执行以下代码(去负载均衡池内分配服务器)
proxy_pass http://h;
# 这个proxy_params文件创建在/opt/nginx1-12/conf底下
include proxy_params;
}------------------------------------------------------------# 手动创建proxy_params参数文件
touch /opt/nginx1-12/conf/proxy_params# 写入信息
proxy_set_header Host $http_host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_connect_timeout 30;proxy_send_timeout 60;proxy_read_timeout 60;proxy_buffering on;proxy_buffer_size 32k;proxy_buffers 4 128k;
此时负载均衡配置初步完成, upstream默认按照轮询方式负载, 每个请求按时间顺序注意分配到后端节点.
upstream分配策略 :
weight权重
upstream django {server 192.168.12.128:8000 weight=5;server 192.168.12.129:9000 weight=10;#这个节点访问比率是大于8000的
}
ip_hash
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器
upstream django {ip_hash;server 192.168.12.128:8000;server 192.168.12.129:9000;
}
backup(备份服务器)
在非backup机器繁忙或者宕机时, 请求backup机器, 因此机器默认压力最小
upstream django {server 192.168.12.128:8000 weight=5;server 192.168.12.129:9000;server 192.168.12.130:8080 backup;
}
应用服务器简单配置 :
1. 准备两个服务器并配置一段flask代码并运行
# 准备代码 myflask.py
from flask import Flask
app=Flask(__name__)
@app.route('/')
def hello():return "我是128服务器
"
if __name__=="__main__":app.run(host='0.0.0.0',port=8000)
---------------------------------------------------------------------
from flask import Flask
app=Flask(__name__)
@app.route('/')
def hello():return "我是129服务器
"
if __name__=="__main__":app.run(host='0.0.0.0',port=8000)
----------------------------------------------------------------------
python3 myflask.py
通过访问nginx负载均衡器入口(www.xd.com), 查看负载均衡是否分配正常, 默认轮询
nginx负载均衡调度算法 :
调度算法 概述
轮询 按时间顺序逐一分配到不同的后端服务器(默认)
weight 加权轮询,weight值越大,分配到的访问几率越高
ip_hash 每个请求按访问IP的hash结果分配,这样来自同一IP的固定访问一个后端服务器
url_hash 按照访问URL的hash结果来分配请求,是每个URL定向到同一个后端服务器
least_conn 最少链接数,那个机器链接数少就分发
ip_hash配置, 根据客户端ip哈希分配, 不能和weight一起使用.
nginx动静分离负载均衡 :