提高PaaS平台可用性的方法
技术领域
本发明涉及云计算平台领域,具体来说涉及一种私有云的实现方法,尤其涉及一种提高PaaS平台可用性的方法。
背景技术
云计算(Cloud Computing)是虚拟化(Virtualization)、效用计算(Utility Computing)、IaaS(基础设施即服务)、PaaS(平台即服务)、SaaS(软件即服务) 等概念混合演进并跃升的结果,云计算是一种按照用户需求、便利地通过网络获取计算资源的计算模式,这些资源可以来自一个共享的、可配置的资源池,并能够快速地获取和释放,它提供了一个全新的互联网商业服务模型,即用户可以通过网络以按需、易扩展的方式租用所需的服务。云计算技术利用高速互联网的传输能力,将计算、存储、软件、服务等资源从分散的个人计算机或服务器移植到互联网中集中管理的大规模高性能计算机、个人计算机、虚拟计算机中,从而使用户像使用电力一样使用这些资源。采用云计算的模式能够提高计算效率和资源的可用性。云计算有三个显著特点:一是按需租用;二是在广大范围的用户广泛协同及资源共享;三是资源有效的调配。目前,云计算按照数据的面向对象可以分为公有云、私有云、混合云。公有云是为公共普通客户使用而构建的,计算资源为所有的人共享。私有云是为一个客户或者企业单独使用而构建的,因而提供对数据、安全性和服务质量有更高的要求。混合云是公有云和私有云的混合服务模式。
目前云计算领域主要分为下面三种,即:SaaS(Software-as-a-Service)软件即服务;PaaS(Plartform-as-a-Service)平台即服务;IaaS(Infrastructure-as-a-Service)基础设施即服务。
SaaS是Software-as-a-service(软件即服务)的简称,是随着互联网技术的发展开始出现并兴起的一种全新的软件应用模式,是云计算领域发展最成熟、应用最广泛的服务。它本质上只是应用软件的传送/按需式利用,例如,由数千顾客通过浏览器同时访问的电子邮件应用程序。通过SaaS软件用户只需要可以访问互联网就能使用软件。基于SaaS的软件大大降低了软件,尤其是大型软件的安装使用成本。 软件托管在服务提供商服务器上,减少了客户的管理维护成本,可靠性也更高。Salesforce.com是SaaS模式的典型代表。
PaaS是Platform-as-a-Service(平台即服务)的简称,是把应用服务器、数据库等基础平台作为一种服务提供的模式。PaaS平台可以将操作系统、应用开发环境等平台级产品服务的方式提供给用户,用于允许开发人员部署在基于云的基础设施上托管的应用。通过PaaS服务,应用开发人员在无需关注底层的中间件平台与其他资源的前提下就可以开发程序。并且不需关注底层中间平台的运营维护。PaaS降低了应用开发团队的维护成本,提升了企业内部的资源的利用率。PaaS平台对应用开发团队提供了强大而稳定的基础运营平台,以及专业的技术支持队伍,优质的平台级服务保证支撑应用系统长时间、稳定的运行。
IaaS是Infrastructure-as-a-Service(基础设施即服务)的简称,是把数据中心、基础设施硬件资源通过Web分配给用户使用的商业模式。其中为客户端提供虚拟服务器和/或按需式资源、如存储装置,根据需要对它们付费,与消费实用程序资源相似。
通常的PaaS平台架构如图1所示,主要组件中的负载均衡器对于平台中的每一个应用程序,来自客户端的请求将会被其根据一定的规则转发到其后的Web服务器或者应用服务器;Web服务器,用于平台上应用程序的部署。对于基于Java/Ruby的应用程序,这部分通常使用应用程序服务器,在本文中不区分这两者,因为他们之间的区别并不影响我们的描述。数据库服务器,用来存储应用的数据。
一般的网站或者基于web多层应用程序架构如图1所示,这个架构在大多数情况下表现良好。尽管图中只描述一个负载均衡服务器,但在实际中目前有大量成熟的集群方式来解决高可用性,以及负载均衡的问题。传统的PaaS平台架构中,所有的应用程序均部署于该平台上,对于每一个应用的新增,删除以及变更,通常都由管理员去手工配置相关服务器的配置文件,然后使其生效,这就造成了大量的管理负担。
申请号为201110219673.2的中国专利文献公开了一种PaaS云平台的资源调度方法,PaaS云平台中管理节点检测各子节点的负载情况,对于负载超过阈值的子节点,将所述子节点中负载开销最大的应用,重新部署到负载最轻且未部署所述应用的子节点,该申请能够在资源调度时保证应用服务质量,减少应用副本迁移的信令开销,实现PaaS云平台的负载均衡。但是该技术未解决服务器配置文件的自动化处理问题,对于实例的增删都需要手工进行配置,造成了大量的资源浪费。
申请号为201110453030.4的中国专利文献公开了一种基于云计算的PaaS平台系统及其实现方法,该系统统包括有服务请求管理模块、SaaS应用系统、服务发布系统、云操作系统、市场销售管理系统、云计算服务和云计算硬件虚拟化框架;利用云操作系统对服务器集群进行硬件虚拟化,然后根据应用系统不同要求配置不同的操作系统,对硬件资源进行动态、统一地分配管理;同时使不同系统的用户绑定不同的用户认证证书,采用实时加解密的主动加密防泄密,对集成在PaaS平台上的应用系统权限进行控制。本发明解决个系统独立性、安全性和资源高效利用问题,可以应用于云计算的PaaS平台系统中。该技术也未解决服务器配置文件的自动化处理问题。
发明内容
为了克服现有技术中的上述不足,本发明的目的在于提供一种自动处理PaaS平台中应用程序的方法,提出一种自动处理PaaS平台中应用程序的增删改查而无需平台管理员参与的方法,从而提供一种可以为公司或者组织内部的PaaS平台提供高可用性的方法。
为了达到上述目的,本发明提出的方法包括应用实例初次启动,增加应用实例和移除应用实例,其特征在于该方法具体包括以下步骤:确定应用部署的实例的数目以及应用的域名;当开发者将该应用上传到PaaS平台的某一个共享存储器上时,PaaS系统会向平台内的所有服务器资源池发布消息,PaaS平台上的服务器收到消息后,判断其是否满足应用所需要的软件环境、硬件资源,以及是否已经部署过该实例;如果收到消息的服务器满足应用需要的条件,该服务器通知PaaS平台将应用部署在该服务器上,并通过消息告知应用应该部署的IP地址与端口;根据应用需要部署的实例数N,PaaS平台获取并解析前N个收到的消息,并且根据消息内容在目标应用服务器上部署并且启动应用实例;当实例启动成功时,该实例所在的服务器使用消息通知PaaS平台该应用实例已经成功启动,PaaS平台获取并且解析该成功启动消息,根据消息内容对负载均衡器的转发策略进行更新;当系统需要增加一个实例时,PaaS系统向平台内的所有服务器资源池发布消息,PaaS平台上的服务器收到消息后,判断服务器是否满足应用需要的条件,若满足条件,则通过消息告知应用应该部署的IP地址与端口,PaaS平台根据获取到的信息更新负载均衡器的转发策略;当应用需要删除一个实例时,部署应用实例的物理服务器在成功停止运行的实例后,向PaaS平台发送消息通知该实例已经停止,PaaS平台在收到消息并解析后应该更新负载均衡器的转发策略,去除对已经停掉的该物理服务器上的运行实例的转发。
进一步,上述方法包括设定一个定时器,在收到一条成功启动信息后一段时间后再更新负载均衡器的转发策略。
进一步,上述方法中加入监控机制,以实现动态扩展。
进一步,上述方法中对于正常运行的应用实例,为监控系统定时上报心跳数据。
进一步,上述方法中每5秒钟上报一次心跳数据,对于连续丢失两次心跳数据的应用实例,将其记为已死亡。
进一步,上述方法中监控系统发送消息给PaaS平台,PaaS平台收到相应的消息后,更新负载均衡器的转发策略,在转发列表中去除已经被标记为死亡的运行实例,然后PaaS平台根据需要启动一个新的应用实例来代替已经死亡的运行实例。
进一步,上述方法中在监控系统中监控应用所部署的物理服务器的CPU或者内存等物理资源,根据监控的数据,或者系统管理员所设置的阈值,如果硬件资源的使用率已经超过所设置的阈值,PaaS平台动态的增加应用的部署实例,如果监控系统发现某个应用的实例大量资源空闲,PaaS平台去除掉部分已经部署的实例。
进一步,上述方法中负载均衡器更新转发策略进一步包括:在该负载均衡器中写入一个语句,该语句用于保持一个独立的配置;为负载均衡器配置虚拟主机;该负载均衡器将代理该应用的所有请求到应用所部署的服务器;该负载均衡器获取到请求的子域名,然后通过配置文件对其进行转发;在应用启动的时候根据启动所在的应用实例,更新该配置文件。
进一步,上述方法中当更新配置文件完成后,通过负载均衡器命令让其动态加载变化的配置;当负载均衡器重新加载后,应用就被外部用户来访问。
本发明相对于现有技术的优点在于:无需管理员手动操作;能够实现不停机的情况下增加应用实例;如果加入监测机制,很容易的实现动态扩展。
附图说明
图1为常用的网站或者基于Web的应用程序架构;
图2为根据一个实施例的方法初次启动的流程图;
图3为根据本发明一个实施例的方法的增加应用实例的流程图;
图4为根据本发明一个实施例的方法的删除应用实例的流程图。
具体实施方式
下面参考附图对本发明的电子银行操作系统的优选实施例进行详细的描述,需要注意的是,下面的描述仅是示意性的,其中所涉及的内容并不构成对发明所涉及内容的限制,本领域技术人员在下面公开内容的基础上还可以有许多不同的变化方式,这些都属于本发明的保护范围。
在整个PaaS平台中,每一个应用都可以通过一个独立且唯一的顶级或者二级域名被客户端所访问。每一个部署在平台上的应用都会被部署在多台不同的物理服务器上。同样,每一台物理服务器上都会部署多个应用的实例。下文中,为了简化描述,我们假设每台物理器只有一块网卡,意味着每台物理服务器只有一个IP地址。在只有一个IP地址的前提下,为了达到在一台物理服务器上部署多个应用的目的,我们需要将不同的应用实例部署为监听不同的端口.
如图2所示,描述了平台中的实例进行初次启动的方法流程图。在应用开发者上传应用之前,开发者应该确定应用部署的实例的数目以及应用的域名。为了描述方便,我们假定有一个应用a1,域名为a1.paas-example.com, 需要部署两个不同的实例。当开发者将a1上传到PaaS平台的某一个共享存储器上时,PaaS系统会向平台内的所有服务器资源池发布消息。PaaS平台上的服务器收到消息后,判断其是否满足应用所需要的软件环境,硬件资源,以及是否已经部署过该实例,为了避免单点失败,我们不应该在同一台物理服务器上部署一个应用的多个实例。如果收到消息的服务器满足应用需要的条件,该服务器应该通知PaaS平台可以将应用部署在该物理服务器上,并通过消息告知应用应该部署的IP地址与端口。根据应用需要部署的实例数N,PaaS平台获取并解析前N个收到的消息,并且根据消息内容在目标应用服务器上部署并且启动应用实例。为了通过应用事先指定的域名访问到应用的实例,用来转发请求的负载均衡器必须获知应用实例所部属的应用服务器的IP地址与端口号。所以,为了获取相关的信息,当应用的实例启动成功时,该实例所在的服务器应该使用消息通知PaaS平台该应用实例已经成功启动。PaaS平台获取并且解析该成功启动消息,根据消息内容对负载均衡器的转发策略进行更新。为了不过于频繁的更新负载均衡器的转发策略,我们可以设定一个定时器,在收到一条成功启动信息后一段时间后再更新负载均衡器的转发策略。例如,对于应用a1, PaaS平台获取到的启动消息为 s1:8080 和 s2:8080. 在更新完负载均衡器的转发策略后,所有访问 a1 指定的域名a1.paas-example.com的请求都会被转发到s1:8080和s2:8080这两台真正的物理服务器上。
如图3所示,描述了一个在平台中增加应用实例的方法流程图。当系统需要增加一个实例时,PaaS系统向平台内的所有服务器资源池发布消息。PaaS平台上的服务器收到消息后,根据上文描述的软件,硬件以及是否部署过等规则判断服务器是否满足应用需要的条件。若满足条件,则通过消息告知应用应该部署的IP地址与端口。PaaS平台根据获取到的信息更新负载均衡器的转发策略,当更新成功后,应用就相当于成功增加了一个运行中的实例。
如图4所示,描述了平台中删除应用实例的方法流程图。当应用需要删除一个实例时,部署应用实例的物理服务器在成功停止运行的实例后,向PaaS平台发送消息通知该实例已经停止。PaaS平台在收到消息并解析后应该更新负载均衡器的转发策略,去除对已经停掉的该物理服务器上的运行实例的转发。
如果加入监控机制,可以很容易的实现动态扩展。对于每一个正常运行的应用实例,其应该给监控系统定时上报心跳数据。例如,根据网络情况,我们选择每5秒上报一次心跳数据,对于连续丢失两次心跳数据的应用实例,我们将其极为已经死亡。监控系统可以发送消息给PaaS平台,PaaS平台收到相应的消息后,更新负载均衡器的转发策略,在转发列表中去除已经被标记为死亡的运行实例,然后PaaS平台可以根据需要启动一个新的应用实例来代替已经死亡的运行实例。在监控系统中可以监控应用所部署的物理服务器的CPU或者内存等物理资源,根据监控的数据,或者系统管理员所设置的阈值,如果硬件资源的使用率已经超过所设置的阈值,那么PaaS平台可以动态的增加应用的部署实例。同样道理,如果监控系统发现某个应用的实例大量资源空闲,PaaS平台也可以去除掉部分已经部署的实例。这样可以实现资源的最大化利用。
在实际中,我们采用Nginx( 一个常用的负载均衡器)服务器作为负载均衡服务器. 在Nginx的配置文件中写入下面的语句:
include ../include.conf/*.conf;
对于每一个应用,都保持一个独立的配置,例如,采用应用的UUID(通用唯一识别码)作为文件名。一个UUID为 axu 的应用,其配置文件为 ../include.conf/axu.conf.
下一步我们配置Nginx的virtual host( 虚拟主机 ),Nginx将代理(Proxy)该应用的所有请求到应用所部署的服务器.使用Nginx的好处是,对于后端的多台应用服务器,Nginx会帮我们将请求代理到其中的一台服务器上. 下面是一个例子:
# application.cluster will hold the available clusters
# at any given point of time
include ../include.conf/*.conf;
server {
listen 80;
server_name www.example.com;
access_log logs/example.access.log main;
error_log logs/example.error.log;
if ( $host ~* (\w+)\.platform2\.letv\.com ) {
set $subdomain $1;
}
location / {
proxy_pass http://$subdomain;
proxy_set_header X-Real-IP $remote_addr;
error_page 500 502 503 504 /50x.html;
# Other parameters
}
}
Nginx可以获取到请求的子域名,然后对其进行转发. 如Client访问
app1.platform2.letv.com. Nginx 会将其转发到 proxy_pass http://app1
在../include.conf/目录中,我们可以找到app1.conf路径,里面可能会有如下的配置:
upstream app1{
ip_hash;
server server1:8500;
server server2:8501;
}
在应用启动的时候我们可以根据启动所在的应用实例,更新这段配置文件。比如,app1现在部署在server3上,监听8000端口,那么app1.conf文件变为
upstream clustapp {
ip_hash;
server server3:8000
}
当更新完成后,我们通过Nginx命令让其动态加载变化的配置
nginx -s reload
当Nginx重新加载后,应用就可以被外部用户来访问了,所有操作均为程序完成,无需管理员手动实现.
本发明的优点在于能够实现无需管理员手动操作,并且可以在不停机的情况下增加应用实例,在加入监测机制的情况下,可以很容易的实现动态扩展。
以上所述,仅为本发明较佳的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求的保护范围为准。