5 PaaS DIY
PaaS是一个软件层,通常连接网络资源包括操作系统实例、数据库服务器实例、网络服务器实例,甚至负载均衡,并连成一个单一的,共享的逻辑承载层,提供按需硬件和操作系统服务,而且还提供应用程序平台和解决方案堆栈。
PaaS 服务可将与应用程序部署关联的大多数 IT 管理方面自动化,包括资源配置、分段和测试、负载平衡、数据库访问以及访问平台库。PaaS 的关键功能是多组织体系结构:即多个不相关的应用程序可运行在相同的硬件和软件基础设施上,从而节约成本以及更有效地利用计算资源。开发人员只需关注应用程序本身,而不需要关注部署和 IT 问题。
那在本章节里面,我们自己根据对PaaS的理解和体会,自己动手拔一拔paas系统里面的这些东西,正如“幸福要靠自己勤劳的双手”一样,要感知或者实践paas平台对业务系统的支撑和帮助,就要对Paas内部也要需要深入的了解,打开黑匣子,搜集一些相关的工具和零件,搭建自己的Paas平台。个人认为paas平台其实不算复杂,只是比10年前搭建SSH框架要稍微复杂一些,呵呵,这样吧,现在旮场。
我们假设几个场景,分布针对不同规模的业务场景。正如前文所述:传统的web应用的架构,在用户期望移动设备和桌面有更佳体验的要求下已经不堪重负,新的架构呼之欲出。也就是说Paas平台帮我们解决部署上的麻烦:简单的部署 + 应用的管理 + 简单的扩展;并提供一些基础平台服务:WEB应用服务器 + SQL数据库 + NoSQL数据库 + 内存服务器 + 消息服务器;但我们自己的web应用需要实现:在应用层面的可水平扩展的服务器 + 模块化的组件,可被拆分和扩展 + 异步的架构,在数据层面的复制 + 分片 +多存储(关系数据库,nosql,内存等),这样应用的业务架构示意图如下:
图50-01 推荐模式
在这个通用的业务架构中,其特点为模块松耦合+请求无状态+通讯异步化。业务架构和paas平台各司其职,相互分工协作。从cloudfoundry到cloudify再到Jelastic,部署越是简单的,它的业务扩展能力其实就是越弱,到了Jelastic,虽然部署非常的简单,简单到只有传个war包即可,但性能的伸缩完全依赖于paas的route(这里是nginx)来实现,扩展有限。所以好的paas平台,不单单是看其提供服务的多寡,支持的语言丰富,还要看是否为部署的应用架构提供了高可用,可水平扩展的业务架构模式。
前文阐述了paas的功能,假设我们需要为自己手头上一堆运行着web和db的服务器实例进行管理和部署,如果按照paas的能力强弱进行等级划分,自己DIY一把,看看能提供什么,需要什么,我们自己又能做些什么。
5.1 DIY before
在diy之前,还有些准备工作需要去做,一些基础知识需要了解。PaaS平台中堆砌了大量的开源软件,它的运行机制其实不会超出我们平时的理解范畴之外,只是选择了某种分布式模式,进行了合理的搭配以及作了自动化处理,有些组合和彼的衔接,所以了解常用的开源软件以及它们的工作方式与应用特点,对于我们的diy大有裨益。这些知识点大致的梳理了一下,我分为如下的内容:
知识点 | 说明 | 备注 |
11.web应用 | 互联网常用和web相关的应用,包括: apache,tomcat,warnish,squid ,memcached,redis |
|
12.备份恢复 |
|
|
13.网络存储 |
|
|
14.运维监控 | Nagios,caicti以及日志管理等,对系统进行监控 |
|
15.性能优化 | 针对架构层面的对系统的优化 |
|
16.应用集群 | 包括了tomcat,nginx,lvs的集群方式 |
|
17.数据集群 | 数据库的集群方式,在互联网中一般采取mysq,借助drbd和heartbeat的能力 |
|
18.通用服务 | 在互联网应用中常用的,包括: 防火墙,dns,vpn,邮件服务器等 |
|
19.部署架构 | 业界通用的集群部署架构模式,通常有 Lvs+keepalived / nginx+keepalied Drbd+heartbeat+nfs/mysql 的混合模式 其中会涉及到几种session的管理方式,paas平台的负载均衡能力也是之前所述方式的一种 | 通用的模式在这里说明,大中小项目中再举具体的范例 |
20.持续交付 | 对于营运类型的项目,会持续的更新和部署,需要采用合适的脚本和持续集成来进行 典型的包括puppet/chef+svn+jenkins | 主要在diy after章节阐述 |
表 51-1:diy知识点
这里和paas diy比较紧密关系的是部署架构,顺带会穿插阐述应用集群和数据库集群以及web的服务相关的内容,所以在diy before的章节中说明;持续交付和运维监控,则是运营和管理的内容了,自然在diy after的章节中阐述。
5.1.1 基础介绍
负载均衡:在现有网络结构上提供廉价方式来扩大服务器带宽,增加吞吐量以及数据处理能力。常用负载均衡的硬/软件如下,按照均衡能力排列:
-
F5 big-ip :可以作 4-7 层的负载均衡,因为是硬件,自然均衡能力是最好的,并提供 12 种均衡能力的算法、会话保持功能以及自动检测故障机器等功能。
-
LVS :是一个负载均衡 / 高可用集群,具有 3 层结构( load balancer/server pool/shared storage ),提供 3 种实现虚拟机实现方式( vs/net ; vs/tun ; vs/dr ),特点是:
-
在负载均衡软件里的性能最强;因为在网络 4 层之上仅作分发之用,没有流量产生。
-
配置性比较低,所以并不需要太多接触,减少人为出错的几率。
-
工作稳定,自身有完整的双机热备方案,如 LVS+Keepalived (推荐) 和 LVS+Heartbeat 。
-
无流量,保证了均衡器 IO 的性能不会收到大流量的影响。
-
应用范围比较广,可以对所有应用做负载均衡。
-
软件本身不支持正则处理,不能做动静分离 ,可以结合 nginx/HAProxy+Keepalived 。
-
-
HAProxy : HAProxy 是一款提供高可用性、负载均衡以及基于 TCP ( 4 层)和 HTTP ( 7 层)应用的代理软件。
-
免费开源,稳定性也是非常好,稳定性可以与硬件级的 F5 相媲美。
-
HAProxy 支持连接拒绝,这个优点也是其它负载均衡器没有的。
-
HAProxy 支持全透明代理(已具备硬件防火墙的典型特点)。
-
HAProxy 现多于线上的 Mysql 集群环境,我们常用于它作为 MySQL (读)负载均衡;
-
带强大的监控服务器状态的页面,实际环境中可结合 Nagios 进行邮件或短信报警。
-
HAProxy 支持虚拟主机。
-
-
Nginx :基于第 7 层的负载均衡,支持 http 和 mail 的均衡,特点:
-
承担高的负载压力且稳定,一般能支撑超过几万次的并发量 ;
-
工作在网络的 7 层之上,提供的正则处理比 HAProxy 更为强大,轻松实现动静分离。
-
对网络的依赖非常小,能 ping 通就就能进行负载功能。
-
可通过端口检测到服务器内部的故障。
-
仅能支持 http 和 Email 。
-
作为中间代理层,对于大型网站可能的架构为 F5/LVS à Nginx( 多台 ) à web 集群。
-
高可用:狭义说是主机的冗余接管,广义说是整个系统高可用的能力,并和lvs/haproxy/nginx结合起来,形成负载均衡/高并发的生成解决方案。
-
Keepalived :运行在 lvs 之上,主要功能是实现真实机的故障隔离和负载均衡器之间的失败切换( failover ),工作在第 3/4/5 层。 keepalived 产生的虚拟 vip 就是整个系统对外的 ip ,如果最外端的防火墙采取的是路由模式,那就映射此内网 ip 为公网 ip 。
-
Heartbeat :和 drdb 一起应用于在线的高可用文件系统;也是 mysql 官方推荐的实现 mysql 高可用的一种手段。
-
DRBD :分布式复制块设备,支持 3 种复制协议:异步复制协议,内存同步,同步复制。在线项目可以采用协议 3 , drbd+heartbeat+nfs , drbd+heartbeat+mysql 。
5.1.2 部署层次
典型的互联网系统架构一般分成负载均衡层、网页缓存层、 WEB层和数据库层和文件服务器层。这里在了解每一层在网站设计中的作用和重要性,找出网站瓶颈加以优化,将网站打造成高可用高可扩展性的网站。下面从和5个层面依次讨论
1、负载均衡层
-
Lvs+ Keepalived 模式 : 现在 linux 系统已经内置了 lvs 功能,为了避免 lvs 的单点故障的出现,采取主备模式,有 2 种高可用软件,这里采取 keepalived ,本身 keepalived 就是为 lvs 设计的,监控集群系统种各个服务节点的状态。 LVS 在性能方面是最好的,尤其是后面的节点 ( 如 Web 或 MySQL 数据库服务器 ) 超过 10 台时,它的性能是最优异的。
-
HAproxy+Keepalived 模式
-
Nginx+Keepalived 模式 : 负载均衡层采取 nginx ,用 keepalived 作 HA 。因为 nginx 在正则处理以及分发和动静分离效果好,在 backup 机实现 cacti+nagios 实现实时监控。如果不在 web 层处理 session 问题,那就在负载均衡层处理,采用粘性会话能力,启用 ip_hash 功能。不过因为自身限制,只能支持 web 集群和 mail 集群。
-
Lvs + Keepalived + nginx 模式 Nginx 作为最前端的负载均衡并不是一个非常理想的选择,一个大型的网站或系统的 话,可以存在多级代理,最前端可用 F5 或 LVS 来作为网站或系统的入口,让它们来顶外部的高并发流量,而 Nginx 由于其强大的正则处理能力,可以作为中层代理,一来可以作为 F5/LVS 的补 充,节约大量成本,形成 F5/LVS -->Nginx( 多台 )-->web 集群的模式:
-
Nginx 负载均衡不存在单点;
-
Nginx 作为 F5 的补充,利用 upstream 模块和正则,实现动静分离;
-
压缩可以通过 nginx 做,后端应用服务器可以不用考虑压缩,提供通用解决方式。
-
方便的运维管理,在各种情况下可以灵活制订方案;
-
即使没有 squid 群组, Nginx 现在可以做为优秀的反向代理加速软件了。
-
2、网页缓存层
网页存储,通常使用squid/Varnish来架设。如果没有独立的web缓存服务器,可使用nginx本身的功能。varnihs是一款比squid更好的产品,网聚的同事已经在使用。
3.WEB层
WEB层这块压力比较大的网站现在都换成了Nginx作为WEB应用服务器,事实上,它的抗并发能力确实超过了预期,高峰期时Nginx并发达到了一万以上,这个是很可观的数字了。
Session管理
-
粘性会话()
-
session 共享(基于 cookie ,基于数据库,基于缓存)
会话保持:识别客户和服务器交付过程的关联性,在负载均衡的同时,保证一系列相关联的访问请求被分配在同一台服务器上。
-
F5 big-ip :简单会话保持,基于 cookie 会话保持, ssl session id 会话保持。
-
Lvs : persistence 机制
-
Nginx : upsteam 模块的 ip_hash 机制。
-
Haproxy : balance source 机制(默认是轮询)
图 51-01:网站部署
这里包括http加速服务器,数据缓存服务器以及共享式文件存储。这里用tomcat/jetty泛指web应用层,在具体架构的时候,也许这里会被拆分为业务拆分或者前后端拆分,这里用简单框图来表述。整个负载均衡层和Web层的工作流程为LVS_DR/nginx+Keeaplived→Nginx反向代理(动静分离)→Tomcat集群,可以保证整个网站不会因为某一台LVS/nginx或Nginx+tomcat机器挂掉而影响网站的运营。如果采取的是lvs+keepalived,tomcat之前一定需要nginx,因为部署的网站一般都会有动静分离、正则分发的需求。
web服务器由nginx+tomcat来处理,提供反向代理,动态静态资源分离和静态文件压缩。
Web缓存层被独立层单独的一层,使用varnihs或squid。如果没有独立的web缓存服务器,可使用nginx本身的功能。如果有独立的web缓存服务器,varnihs是一款比squid更好的产品,网聚的同事已经在使用。
缓存服务器是针对业务系统的数据的缓存,用于减轻业务系统对数据库的IO压力。
文件存储层被独立成单独一层。在下面部分讨论。
4、文件服务器层
如果没有采取共享存储,每台web服务器都是独立的磁盘,需要本地均存放一份代码,为了保证多台web服务器的代码数据一致性,使用rsync+inotify实现动态同步。
倘若硬件条件允许的情况下,推荐使用网络文件系统或者分布式文件系统来存储,方案见下;
-
单 NFS+ 备份 NFS 作为文件服务器,但存在着单点故障,需要人为手动干预;
-
DRBD+Heartbeat+NFS 高可用文件服务器,维护方便,也不存在着单点故障。
-
采用 EMC 的存储方案
-
分布式文件系统 MFS 等,分布式文件系统是解决文件服务器压力过大的最终途径。
-
开发自己的分布式文件系统了,
5、数据库层
互联网应用中一般采用MySQL数据库(但关键核心系统采用oracle,形成mysql+oracle的混合数据库模式)。面对并发的压力,可以采取如下步骤:
-
系统采用 memcached 作为数据缓存,减少对数据库的 IO ,
-
采取读写分离的模式,在生产环境下是一种靠谱的设计方案,从服务的负载均衡推荐使用 LVS ,因为当后面的 MySQL 机器超过十台时, HAProxy 在这方面的性能不如 LVS 。
-
如果业务量过大,接着可采用垂直分库,每一组均采用主从架构,这样可避免了单组数据库压力过大的情况。不建议采用水平分库的模式,原因在前面的章节已经阐述。
-
另外需要 DBA 和开发人员,在数据库参数优化 /SQL 语句优化 / 数据切分上多做功夫。
5.1.3 部署架构
网站架构一般分成负载均衡层、web层和数据库层,文件服务器层,随着网站的PV越来越多,文件服务器的压力也越来越大;不过随着moosefs、DRDB+Heartbeat+NFS的日趋成熟,压力会随着技术的进步而得到逐步的缓解。
网站最前端的负载均衡层称之为Director,起分摊请求的作用,最常见的就是轮询。
F5是通过硬件的方式来实现负载均衡,它较多应用于CDN系统,用于squid反向加速集群的负载均衡,是专业的硬件负载均衡设备,尤其适用于每秒新建连接数和并发连接数要求高的场景;LVS和Nginx是通过软件的方式来实现的,但稳定性也相当强悍,在处理高并发性能不俗。
目前较成熟的负载均衡高可用技术有LVS+Keepalived、Nginx+Keepalived,以前 Nginx没有成熟的双机备份方案,但通过shell脚本监控是可以实现的,有兴趣的可具体参考我在51cto上的项目实施方案;另外,如果考虑 Nginx的负载均衡高可用,也可以通过DNS轮询的方式来实现。
负载均衡高可用中的高可用指的是实现负载均衡器的HA,即一台负载均衡器坏掉后另一台可以在<1s秒内切换,最常用的软件就是Keepalived和Heatbeat,成熟的生产环境下的负载均衡器方案有Lvs+Keepalived、Nginx+Keepalived;如果能保证Heartbeat的心跳线的稳定的话,Heartbeat+DRBD也是成熟的应用,适用于NFS文件服务器或Mysql。
大型网站架构中其实可以结合使用F5、LVS或Nginx,选择它们中的二种或三种全部选择;如果因为预算的原因不选择F5,那么网站最前端的指向应该是LVS,也就是DNS的指向应为lvs均衡器,lvs的优点令它非常适合做这个任务。重要的ip地址,最好交由lvs托管,比如数据库的ip、webservice服务器的ip等等,这些ip地址随着时间推移,使用面会越来越大,如果更换ip则故障会接踵而至。所以将这些重要ip交给lvs托管是最为稳妥的。
VIP地址是Keepalived虚拟的一个IP,它是一个对外的公开IP,也是DNS指向的IP;所以在设计网站架构时,需要多申请一个对外IP。在项目实施过程中发现,Lvs和Nginx对https的支持都非常好,尤其是LVS,相对而言处理起来更为简便。
在LVS+Keepalived及Nginx+Keepalived的故障处理中,二者都方便;如果发生了系统故障或服务器相关故障,即可将DNS指向由它们后端的某台真实web,达到短期处理故障的效果。
另外关于session共享的问题:Nginx可以用ip_hash机制来解决;而F5和LVS都有会话保持机制来解决这个问题,此外,还可以将session写进数据库,或者写入缓存,这就需要架构师进行取舍。
经过对负载均衡层和web层的架构处理,前端层的并发问题解决后,压力就会传递给后端的文件服务器层和数据库层,单NFS不可能胜任目前的工作,可行的方案是moosefs和 DRDB + Heartbeat + NFS;而Mysql服务器,成熟的应用方案还是主从(读写分离)模式。
前面铺垫了这么多内容,无非想说明大规模网站的设计和部署,其实并不遥远和神秘,它和我们周边开源软件息息相关,借用作者的智慧,以及自己付出一些实践的成果,我们也能在互联网的浪潮中不至于被远远的落下,作为本章节的收尾,后续将开展我们的diy行动,其实可见我们的diy paas平台在部署上和别人的大规模网站的部署何其相似,所以说在互联网时代没有黑箱,只有白盒,借助自己勤劳的双手自行diy,深刻感受一下Pass平台的嬲塞魅力把,所以请大家正襟危坐,全神贯注,目不斜视,现在旮场,进入我们的diy阶段。
本身Paas平台博大精深,内容庞杂,业界也有很多不同的方案和产品,每个解决方案都有自己的亮点和适用场景,并不没有所谓的好与坏,好与底。能解决自己的问题,提升公司的整体技术能力,就是合适的,所以在这里对Paas平台稍微归类,纯属个人行为,只为了阐述方便,不代表业界通用说法。这里我按照Paas的CloudControl作为类型的区分,可以分为3个时代:
-
脚本式 CC (奴隶时代):由脚本构筑,没有明确的 cloudControl ,部署 / 管理 / 监控采取的是脚本和自动调度程序,再配合特定的模板和规则。系统处于堆砌方式,需要运维人员的强烈管理意识,依赖众多劳苦的 IT 民工,所以处于奴隶时代。
-
独立式 CC (封建时代):有独立的 cloudcontrol 对整个 paas 云端进行管理,包括部署,发布监控等, cc 和部署的应用之间是有状态的,也就是说 cc 和 apps 的关系是 1:n 的关系。部署简单,监控有力,因为带有状态,部署的 apps 的个数有限,如果借助某种定义语言或者模板来说明部署方式,将极大的简化部署工作,可实现 noops 的能力。因为此时已经有了类似家族管理的作风, CC 就是家长,强调规范化调理化,家族内部次序井然,所以处于封建时代。
-
分离式 CC (资本时代):有多个独立的 cloudcontrol , cc 本身是多节点,对外统一暴露, cc 和 apps 之间没有状态关联,而是通过某种消息机制建立发布和订阅关系, cc 和 apps 的对应关系是 n:m ,可部署相当多的 apps 服务。为了整个云端能良好的运行,需要进行良好的维护。整个系统庞大而次序井然,分工明确各司其职,各个组件都是独立而平等,通过发送和订阅的方式,整个系统进行着步骤有序的运转,所以处于资本时代。
上一篇 从项目开发到云端架构(15) :http://timeson.iteye.com/blog/1701957
下一篇 从项目开发到云端架构(17) :http://timeson.iteye.com/blog/1707071