集群方案分析（共7篇）
集群方案分析 篇1
1. 引言
在高负载的网络环境中,采用负载均衡技术是一种普遍的做法。Linux平台下的LVS[1]是当前使用极为普遍的负载均衡技术,广泛应用于WEB服务器、视频点播等高负载、高并发的网络服务中。在以往的关于LVS和负载均衡的研究当中,多局限于网络服务的集群配置和LVS的调度算法研究,极少考虑它在服务于多用户的集群环境中的应用。本文论述了一种集群解决方案,可以向众多用户提供Linux平台下的开发和学习环境。同时针对这种特殊的应用,提出了相应的性能优化措施。
2. 应用环境
在某些实际环境中,众多用户需要使用Linux系统,比如软件公司在Linux平台下开发软件,或学校中学生学习Linux课程。但由于种种原因,用户的计算机需要使用windows系统,或者无法为每名用户都提供一个Linux系统,此时需要设计一个Linux的集群环境来加以解决。
具体需求如下:(1)每名用户都可在任意时间使用Linux系统。(2)为了使用方便,登陆地址必须使用固定域名或IP。(3)无论用户登陆到哪个节点中,进入的依然是自己的主目录。(4)用户不能滥用节点资源,导致其他用户不能正常工作。
为了满足以上需求,采用LVS、NIS、NFS[2]和Autofs技术,搭建一个Linux集群网络。整个集群通过LVS实现负载均衡,采用NIS集中认证,并将用户的主目录保存在NFS服务器中。网络拓扑如图1。
简要流程如下:在用户登陆时,LVS服务器作为入口地址,LVS将登陆请求转发至集群中的某一节点X,节点X认证信息发往NIS服务器,通过认证后,成功登入进节点X,节点X自动挂载NFS服务器中的用户主目录。
3. 配置方案
所有服务器和集群节点均采用Red Hat Enterprise Linux6操作系统,用户登陆地址设为172.16.57.101。
3.1 配置NIS服务器
首先为所有用户创建本地账号。然后设置NIS域名,编辑/etc/sysconfig/network,添加一行
3.2 在集群节点上配置NIS客户端
3.3 配置NFS服务器
编辑/etc/exports
/data/nfs/home 172.16.57.0/24(rw,sync)
3.4 在集群节点上配置autofs
3.5 配置LVS服务器
使用piranha-gui来配置LVS[3],配置结果保存在/etc sysconfig/ha/lvs.cf中,内容如下:
设置LVS服务器的虚拟网卡,创建及编辑/etc/sysconfig/network-scripts/ifcfg-eth0:1,内容如下:
3.6 配置集群节点
创建虚拟网卡lo:1,编辑/etc/sysconfig/networkscripts/ifcfg-lo:1,内容如下:
4. 集群的性能分析
在本文论述的集群方案中,有两项突出的问题:用户行为的不可预知性和NFS服务器的性能瓶颈。
在大多数的集群方案中,集群提供的服务都是和用户无关的,比如说是WEB服务器集群、邮件服务器集群等,因此各个节点的压力仅仅和连接数有关,因此完全可以通过LVS的调度算法来均衡各个节点的压力。但在本文中论述的集群方案中,节点的负载可以和连接数完全无关。比如某台服务器已登陆50名用户,但都在做文本编辑,因此节点负载很低。此时新登陆一名用户开始做编译,节点立刻就达到满负荷,同时其他50名用户的工作将会受到严重干扰,他们就会认为该节点出现了严重的性能问题。
此外,在此集群方案中,NFS服务器上存储了所有用户的主目录,因此其I/O负载很大,很有可能成为整个集群的性能瓶颈。
5. 性能问题解决方案
5.1 防止用户浪费系统资源
针对第一个问题,通过增加节点数量是不可取的。更好的办法是限制用户对节点资源的使用。
利用bash的内置功能,即可达到此目的。在这里我们限制每个用户的单个进程最多可以使用15秒的CPU,128M内存,超过此限制时进程就会被强制终止。具体配置如下:
将所有用户都归属于用户组user,组id为500。然后创建并编辑/etc/profile.d/limit.sh,内容如下:
5.2 优化NFS性能
针对NFS的性能问题,此前的研究都是通过修改NFS挂载参数、优化NFS客户端和服务端之间的网络连接参数等方面入手,本文采用的是通过优化NFS服务器本地的I/O性能来达到优化NFS性能的目的。
在Red Hat Enterprise Linux 6中,默认的磁盘调度器是CFQ(Complete Fair Queuing)。CFQ调度器的设计原则是尽量公平,以进程的I/O优先级为基础,将I/O带宽分配给各个进程。Linux 2.6内核还提供了deadline调度器,deadline的设计原则是任何I/O请求都会在一定的时间内得到服务。因此,CFQ调度器更适合通用服务器和桌面系统,而deadline调度器比较适合数据吞吐量较大的应用场合。
为了验证这一假设,在真实服务器上做了实际的测试。测试环境如下:
硬件服务器采用IBM System x3650 M2,配置为Intel(R)Xeon(R)CPU E5504 2GHz(4核),4G内存,146G 2.5英寸SAS单硬盘,操作系统均为Red Hat Enterprise Linux 6,通过百兆交换机互连。
测试过程如下:
NFS服务器共享了四个目录,每个目录下各有几十个文件,文件大小从几百K到几M不等,总大小从60M到80M不等。四个NFS客户端同时复制对应目录下的所有文件到本地。当采用CFQ调度器时,四个客户端的复制时间在12秒左右;而采用deadline调度器时,四个客户端的复制时间在9秒左右。deadline调度器的表现明显优于CFQ。
6. 结语
本文提出了一种集群方案,用于大量用户使用Linux系统的应用环境。在文中给出了具体的配置方法,以及此方案可能出现的性能问题,并提供了相应的解决办法。
本方案的不足之处在于,LVS、NIS、NFS均有可能出现单点故障,从而导致整个集群不可用。下一步的研究工作会重点解决此问题,让整个集群可以提供7*24小时不间断的服务。
参考文献
[1].Zhang W.Linux Virtual Server project[EB/OL].http://www.linuxvirtualserver.org.May1998.
[2].S.Shepler,B.Callaghan,D.Robinson,R.Network File Sys-tem(NFS)version4Protocol[S/OL].http://www.ietf.org/rfc/rfc3530.txt.April2003.
[3].Red Hat Inc.Red_Hat_Enterprise_Linux-6-Virtual_Server_Admin-istration[EB/OL].http://docs.redhat.com/docs/en-US/Red_Hat_Enter-prise_Linux/6/html/Virtual_Server_Administration/index.html.November2010.
集群方案分析 篇2
关键词：负载均衡,集群,可伸缩性,可用性
1 引言
互联网的出现使信息访问产生了质的飞跃, 但随之而来的是Web流量的激增 (高并发访问) , 由于涉及信息量十分庞大, 用户访问的频率也高, 许多基于Web的大型公共信息系统 (如电子图书馆、BBS、搜索引擎和远程教育等) 需要在实时性和吞吐量方面都具有较高性能的Web服务器支持。在介绍Weblogic集群之前, 先看看传统的双机架构, 这种架构存在以下几点不足之处:采用主机备机的方式, 一般主机使用比较频繁, 导致另外比较空闲, 资源利用不均衡;当一个Server发生故障的时候, 必须通知用户使用另外一台的Server, 管理和维护比较麻烦;用户切换应用的时候, 需重新登录, 有些延误时间。
实际上, 服务器的处理能力和I/O已经成为提高Web服务的瓶颈。如果客户的增多导致通信量超出了服务器能承受的范围, 那么其结果必然是服务质量下降。显然单台服务器有限的性能不可能解决这个问题, 一台普通服务器的处理能力只能达到每秒几万个到几十万个请求, 无法在一秒内处理上百万个甚至更多的请求。显然, 采用高性能的主机系统 (小型机或大型机) 是可行的, 但是除了价格十分昂贵外, 这种高速、高性能的主机系统, 很多情况下也不能解决同时处理几万个并发, 因为, 高速主机系统只是对于复杂的单一任务和有限的并发处理显得高性能, 而Internet中的Web服务器大多数处理是“简单任务”、高强度并发处理, 因此即便有大资金投入高性能、高价格的主机系统, 也不能很好的满足Web应用的需要。这就是利用Web服务器集群实现负载均衡的最初基本设计思想。
2 集群的优点是什么?
2.1 可伸缩性
可以动态增加部署在WebLogic Server集群中的应用程序的容量以满足需要。可以将服务器实例添加到集群中而不会中断服务, 应用程序将继续运行而不会影响客户端和最终用户。
高可用性。在WebLogic Server集群中, 当服务器实例失败时应用程序可继续进行处理。可通过将应用程序组件部署到集群中的多个服务器实例, “集群”这些组件, 这样, 如果在其上运行某个组件的服务器实例失败, 则将此组件部署到的其他服务器实例可以继续进行应用程序处理。
集群WebLogic Server实例的选择对于应用程序开发人员和客户端是透明的。但是, 了解启用集群的技术基础结构将有助于编程人员和管理员最大化其应用程序的可伸缩性和可用性。
2.2 集群的关键功能是什么?
2.2.1 应用程序故障转移
简单的说, 故障转移是当应用程序组件 (在下列部分中通常称作“对象”) 正在处理某个特定作业时某些处理任务部分由于任何原因而变得不可用, 已失败对象的副本将结束此作业。WebLogic Server支持自动或手动将集群服务器实例从一台计算机迁移到另一台计算机, 可迁移的受管服务器被称作“可迁移服务器”。本功能适用于要求高可用性的环境。
2.2.2 负载平衡
负载平衡是在环境中跨计算资源与网络资源平均分发作业和关联的通信。
2.2.3 哪种类型的对象可以集群
集群的应用程序或应用程序组件在集群中的多WebLogic Server实例上可用。如果已集群某个对象, 则此对象的故障转移和负载平衡是可用的。将对象均匀部署到集群中的每个服务器实例, 可以简化集群管理、维护和故障排除。
Web应用程序可由不同类型的对象组成, 包括企业Java Bean (EJB) , servlet和Java Server Pages (JSP) 。每种对象类型都具有唯一的一组与控制、调用以及它如何在应用程序内起作用相关的行为。由于此原因, WebLogic Server用于支持集群的方法, 以及用于提供负载平衡和故障转移的方法, 会因不同的类型对象而异。可在WebLogic Server部署对下列类型的对象进行集群:Servlet、JSP、EJB、远程方法调用 (Remote Method Invocation, 简称RMI) 对象、Java消息服务 (JMS) 目标、Java数据库连接 (JDBC) 。
2.2.4 什么类型的对象不可集群
以下API和外部服务不可在WebLogic Server内集群:包含文件共享的文件服务、时间服务。在集群的各个WebLogic Server实例中仍可使用这些服务。但是这些服务不能使用负载平衡或故障转移功能。
2.3 集群有哪些限制
集群中的WebLogic主机必须使用永久的静态IP地址。动态IP地址分配不能用于集群环境。如果服务器位于防火墙后面, 而客户机位于防火墙外面, 那么服务器必须有公共的静态IP地址, 只有这样, 客户端才能访问服务器。
集群中的所有WebLogic服务器必须位于同一个局域网, 并且必须是IP广播可到达的。
集群中的所有WebLogic服务器必须使用相同的版本。
结束语
本文提出了基于WebLogic的集群Web服务器的设计方案, 系统能够达到负载均衡的目的, 该方案已经在多个网站中使用并取得了很好的效果
参考文献
LTE无线宽带集群方案研究 篇3
集群通信, 是通过专用无线进行调度的通信系统, 已广泛应用于现代物流、交通及电力等领域中。整体上看, 基于TD-LTE技术的TD-LTE宽带集群具有下列几大优势:
1) 高宽带。下行和上行传输率分别为100Mbps和500Mbps, 其中数据、语音等都能经该通过实现传输, 有助于实现军用信息化。
2) 高频谱利用率。该方案综合运用OFDM、MTMO技术, 有效提高了其频谱利用率。
3) 缩短了呼叫时间。通过优化系统的内部架构, 减少了延时 (5ms) 。
4) 安全性高。TD-LTE系统设置了加密管理器和软硬接口, 因而拥有空口与端到端加密功能。
二、TD-LTE宽带集群研制的关键点
2.1频段划分
国际电联将LTE分成了4个频段, 分别为200MHz、100MHz、108MHz与20MHz。450MHz频段被誉为公共频段, 在对讲机与集群通信中得到广泛应用。700MHz是LTE (698M-806MHz频段) 中的最佳频段。对TD-LTE宽带集群而言, 低于1GHz (700MHz, 400MHz频段) 的频率较低, 辐射范围骗贷, 其系统覆盖能得到逐步改善, 可有效减少建网成本。
2.2小区覆盖
从覆盖面积与效果来看, 低频段要比高频段具有更显著的优势。在相同地区用低频段进行覆盖, 可降低基站数量与建网成本, 系统终端的功耗也将减少, 其使用年限将延长。
2.3呼叫时延
针对公安等集群系统而言, 通话的低时延、及时性等极为关键, 可确保指令的准确到达。通常情况下, 业务终端呼叫应控制在500ms内, 话权抢占时间应控制在200ms, 以实现较高的指挥调度。TD-LTE宽带集群呼叫时延主要涉及下列几项关键技术:1) 通过NAS消息来取代以往的POC SIP:减少参与网元;运用合理的UE基带芯片来缩短消息处理时间;通过广播等方式将集群语音传输出去。
2.4改造终端芯片
终端TD-LTE专网芯片, 可根据公网TD-LTE芯片做出适量改动, 改动部分集群话音协议 (公网协议) 。通常, 基带IC与RF IC所支持的频段范围相对较宽, 无需进行更改。集群终端迈入宽带化后, 其数据传输与视频等耗费的电量, 远高于窄带集群, 为此, 宽带集群终端应尽量采用芯片方案和功率控制等技术, 以降低终端的能耗。
2.5系统安全性
针对公安等用户而言, 通话与网络的安全性极为关键, 宽带集群应适应其安全性需求。宽带集群系统对空中接口实行了严格加密, 具有双向鉴权, 其安全性能相对较高。这其中, 基础设施安全系统均采用专业的服务器, 并将开发接口提供给加密资质较强的单位。终端中应留出SIM卡接口、串口或加密芯片等等, 由具有加密资质的部门来选择加密算法与密钥。
2.6窄带与宽带的兼容性
为有效利用窄带集群系统, 减少部署成本, 我们应妥善处理好窄带与宽带之间的兼容性问题, 具体可采取下列措施:设计双模双待或单待的终端, 如终端超出了窄带集群系统的覆盖范围, 可采用窄带模式工作, 以降低功耗;而当终端处于宽带集群系统覆盖之下时, 可转换为宽带模式, 以减少其运行功耗。
三、TD-LTE宽带集群解决方案的应用
鼎桥展出的一体化终端, 即典型的TD-LTE宽带集群专网方案。它以TD-LTE技术为基础, 可在同一网络环境下提供专业级的集群话音, 实现宽带数据的无线传输、视频调度等通信功能。从语音业务分析, 鼎桥宽带集群解决方案可提供高效的语音集群业务, 建立群组与话权抢占时延都应控制在300ms与150ms范围内。不管是在功能还是性能方面, TD-LTE方案都高于目前窄带集群系统的整体水平。值得一提的是, 鼎桥无线宽带集群系统的研制基础在于TD-LTE技术, 可使多路高清视频数据实现有效传输。鼎桥自行研制和提供了该方案的终端芯片, 其大体可分为CPE、车载和手持终端等类型。现阶段, 鼎桥宽带集群已基本建成专用终端的产业链, 并在机场、政务和港口等领域中得到初步应用。
四、结论
TD-LTE宽带集群无线系统, 为多媒体应用平台创造了安全的无线通道。随着社会的不断发展, 该系统中的软交换技术、多码同步传输技术等关键问题将得以解决, 整个系统的应用前景将更为明朗。
摘要：无线宽带集群与传统集群不同, 其实际应用需以高速率、大宽带、视频等为支撑。从当前情况来看, 以公网TD-LTE为基础研制TD-LTE宽带集群, 将会是不错的发展选择。文章将对LTE无线宽带集群方案展开详细探讨。
关键词：LTE无线宽带集群,关键点,应用
参考文献
[1]龙恳.TD-SCDMA向LTE TDD演进中的多天线技术[D].北京邮电大学, 2014
[2]常沛.LTE系统中的干扰管理技术研究[D].北京邮电大学, 2013
数字集群通信系统工程方案研究 篇4
1 主流集群通信体制方案的分析比较研究
集群通信系统与公众的蜂窝移动系统相比具有呼叫接续快、采用半双工通信方式和支持私密呼叫和群组呼叫等特点。
1.1 TETRA系统
TETRA是就是陆上集群无线电, TETRA标准是由欧洲电信标准协会 (ETSI) 制定的, 它的技术指标和性能能满足广大的处理应急业务、工业和商业部门的专用用户的使用要求。包括3种基本通信方式:话音加数据 (V+D) 通信, 优化分组数据 (PDO) , 直通通信 (DMO) [3]。
1.2 GT800系统
GT800是基于GPRS和GSM—R技术、拥有独立知识产权的数字集群系统。它结合蜂窝技术, 通过对TDMA和TD-SCDMA技术的优化与融合, 提供专业用户所需的高性能、大容量的集群业务和功能, 系统稳定, 可持续发展能力强。
GT800在核心设备部分, 增添了功能号码节点、组呼寄存器、排队机等, 从而为指挥调度应用提供更灵活的支持[4]。
1.3 GOTA系统
GOTA的含义是开放式集群架构。GOTA数字集群系统和业务解决方案是中兴通讯在多年发展基础上, 根据目前电信市场需求, 推出的商业化的新一代集群技术和产品。
GOTA技术在成熟CDMA技术的基础上进行了优化和改进, 围绕着无线信道共享和快速链接这两项关键技术提出解决方案, 使新增的集群业务不会对传统通信业务和网络资源带来不利影响[5]。
1.4 iDEN系统
iDEN系统是一种基于数字蜂窝网络的集群通信系统, 集移动电话、数据传输、集群调度和短信息传输于一体, 采用TDMA技术、VSELP矢量和激励的线性预测编码技术和抗干扰能力强的M-16QAM正交振幅调制技术, 双工通话结构以及频率复用方式, 使得系统低功率、大容量、广域覆盖[6]。
1.5 主流集群通信体制方案的分析比较
四种数字集群通信系统均可提供基本的集群业务, 补充业务及必要的全双工电话互连业务, 都具有完善集群功能[7]。四种数字集群通信系统的对比见表1。
2 TETRA集群通信系统工程的研究与设计
2.1 TETRA集群通信系统工程的研究与设计
TETRA的通信业务包括话音, 电路方式数据传输, 短数据信息及分组数据业务。TETRA标准还支持丰富的补充业务, 其中许多补充业务是TETRA特有的。
TETRA数字集群系统的硬件系统实现从语音的采样, 语音压缩编码, 信道编码, 中频调制, DA变换, 然后通过模拟数据线传送出去, 这是上行链路。下行链路要实现AD变换, 中频解调, 信道解码, 语音解码, 语音输出。该硬件平台既要可以实现上行链路的功能, 也要可以实现下行链路的功能。
2.2 TETRA集群通信系统工程方案应用范例
上海地铁二号线无线通信系统设计采用数字中区制800MHz频段集群系统组网, 系统采用TETRA标准。基本设计是:系统是MOTOROLA的DIMENLA, 8个EBTS, 18信道, 54个虚拟信道, 5台调度台, 55台车台, 250台手机, 22台固定台。
3 GOTA集群通信系统工程研究与设计
3.1 GOTA集群通信系统工程的研究与设计
终端、无线子系统BSS、调度子系统DSS就构成一个GOTA的基本网络结构, 为了能够支持电话互连业务、数据业务和短消息服务, GOTA除其基本结构外还接入了交换子系统、数据业务子系统和短消息服务中心。
3.2 GOTA集群通信系统工程方案应用范例
GOTA数字集群系统可广泛应用于抢险救灾、医疗急救、公共交通、矿山工地、酒店管理、公共调度、餐饮娱乐、会议展览、企业和小区管理、公安、交警以及家庭小团体等, 可大大提高生产率和工作效率, 且GOTA拥有完全的自主知识产权, 能够完全自主开发生产从系统到终端的全套产品, 因此GOTA系统应用于军队、公安、安全及政府部委等重要部门, 对国家安全更具重要意义。
4 结语
通过上述对主流集群通信体制方案的分析, 针对数字集群通信系统, 着重对比了TETRA系统、GT800系统、GOTA系统、iDEN系统, 并根据系统各自的优劣方面, 对TETRA集群通信系统工程方案和GOTA集群通信系统工程方案进行了设计, 并以TETRA系统和GOTA系统为例, 分别给出TETRA集群通信系统工程方案和GOTA集群通信系统工程方案的应用范例。
参考文献
[1]郑祖辉, 陆锦华, 郑岚.数字集群移动通信系统[M].电子工业出版社, 2005.
[2]谭学治.我国数字集群通信前景分析[J].通信产业报, 2009.
[3]莫静飞, 廖宇.集群通信应用及发展方向[J].通信机世界报, 2008.
[4]华为技术有限公司, 适合国内市场应用的数字集群解决方案[J].电信网技术, 2006.
[5]李侠宇.国内数字集群的发展和技术比较[J].移动通信, 2007.
[6]钱宁铁.TETRA和GSM-R系统特点和射频性能分析[J].中国无线电, 2004.
集群方案分析 篇5
1 面向服务的集群部署体系
集群技术的出现和应用, 是解决上述问题的有效方法。集群是指一组相互独立的服务器, 在网络中表现为单一的系统, 并以单一系统的模式加以管理。此单一系统为客户端工作站提供高可靠性的服务。一个集群系统是一群松散结合的服务器组, 以统一的功能形成一个虚拟的服务器[1], 集群内各节点服务器通过内部局域网相互通讯。大多数模式下, 集群中所有的计算机拥有一个共同的名称, 对于一个Client (客户端) 来说, 通常在访问集群系统时不会意识到它的服务是由具体的哪一台服务器提供。任何一台服务器运行一个应用时, 应用数据被存储在共享的数据空间内。每台服务器的操作系统和应用程序文件存储在其各自的本地储存空间内。当一台节点服务器发生故障时, 这台服务器上所运行的应用程序将在另一节点服务器上被自动接管。当一个应用服务发生故障时, 应用服务将被重新启动或被另一台服务器接管[2]。当以上的任一故障发生时, 客户都将能很快连接到新的应用服务上。集群服务器一起工作, 提供比单台服务器功能更强大、可靠性更高的应用程序平台。
与传统的系统模型相比, 通过面向服务的思想开发支持集群部署的企业信息系统, 有效减少了服务与服务之间的耦合。面向服务架构 (Service-Oriented Architecture, SOA) 是一种业务驱动的架构方式, 支持对业务进行整合, 使之成为一种相互联系、可重用的业务任务或者服务。在基于SOA架构的系统中, 具体应用程序的功能是由一些松散耦合且具有统一接口定义方式的组件组合构建起来的, 并提供一个抽象的服务层, 对服务使用者隐藏了服务的实现细节。因此构建在各种系统中的服务可以用统一和通用的方式进行交互, 系统具有可复用、灵活和可扩展等诸多优势[3]。譬如对于某种商品进货的业务流程, 面向服务把其划分为获取商品信息、审核订单信息、进货等几个服务。当其中某一个服务有所更改时, 只要接口没有改变, 则可以直接替换该服务。J2EE技术中的EJB在此提供了有效支持, 每一个服务都封装在一个EJB中, 使得所有的服务都能以“热插拔”的形式提供。一旦需要更改某个服务, 只需要将其“拔”下来, 把新的服务“插”回去即可。该过程对用户是完全透明的, 服务与服务之间为松耦合。并且由于服务被EJB技术封装, 使得集群部署的时候, 系统服务也处于应用级别集群, 提供了更好的稳定性。企业信息系统可以有效地长期运行, 新的服务可以便捷地添加进原来的系统中。
2 方案实施
在企业信息系统的集群解决方案 (见图1) 中, 笔者使用BEA公司的WebLogic服务器。BEA WebLogic是用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用的JAVA应用服务器。将JAVA的动态功能和JAVA Enterprise标准的安全性引入大型网络应用的开发、集成、部署和管理之中, 对企业级标准全面支持, 包括EJB、JMS、JDBC、XML等。BEA WebLogic Server拥有处理关键Web应用系统问题所需的性能、可扩展性和高可用性, 它是专门为企业级电子商务应用系统开发的。企业电子商务应用系统需要快速开发, 并要求服务器端组件具有良好的灵活性和安全性。WebLogic还拥有出色的集群技术, 既实现了网页集群, 也实现了EJB组件的集群, 这并不需要任何专门的硬件或者操作系统支持。网页集群可以实现透明的复制、负载均衡以及表示内容容错, 组件集群则处理复杂的复制、负载均衡和EJB组建容错, 以及状态对象的恢复。无论是网页集群还是组件集群, 对于企业信息系统解决方案所要求的可扩展性和可用性都是至关重要的。
对于集群部署的企业信息系统, 由于Web页面访问量不一定很大, 而且前端也不一定是Web页面, 可能是Web服务, 所以可以使用代理服务器重定向作为Web页面的负载均衡方法。为了保证受管理的服务器即使崩溃后, 也能够通过主服务器对其重新启动或者设置, 所以代理服务器同时也是主服务器, 管理其他的服务器实例。这样可以保证受管理服务器的灵活和稳定。其中WebLogic实例1、实例2和实例3都是受管理的服务器, 配置成集群。系统模型使用EJB技术, 采用相同设置, 分别部署在3个WebLogic实例服务器上, 使用WebLogic本身提供的应用级别集群技术。这样做可以提供业务组件有效的容错能力, 保证了系统的稳定性, 并且使得系统具备一定的伸缩性。所有对于业务组件的客户, 可能是前端用户从Web页面提交的请求, 也可能是Web Services接收的请求, 都会通过远程调用来调用业务组件, 通过WebLogic内部的算法实现, 达到了对业务组件访问的均衡负载[4]。集群后的业务组件共享并访问同一个数据库。
3 结束语
与单一服务器相比, 松散耦合结构的服务器集群系统有以下主要优点:
(1) 高性能。网络服务的工作负载通常是大量相互独立的任务, 通过一组服务器分而治之, 可以获得很高的整体性能。
(2) 可伸缩性强。根据需要, 可以动态地将新的服务器添加到集群系统中, 提高数据处理能力。其伸缩性远超过单台超级计算机。
(3) 高可用性。集群利用多台服务器的冗余, 通过检测软硬件的故障, 将故障屏蔽, 由存活节点提供服务, 实现高可用性。从发生故障的服务器自动切换到正在运行的服务器的能力, 可以保证对客户端具有应用程序的无缝可用性, 而无需客户端知道出现了问题。
集群技术给企业用户提供了一个灵活方便的信息系统管理环境, 其灵活的架构、易于扩展和部署的服务, 为解决大型应用信息系统功能结构的拆分、突破性能瓶颈的限制提供了高效的技术手段。
摘要：集群服务器作为一种服务器应用的新模式正在受到越来越多的重视。本文根据企业业务的需求, 提出面向服务的企业信息系统集群部署方案, 该方案具备更好的稳定性、可扩展性。
关键词：集群部署,面向服务架构,EJB
参考文献
[1]俞枫.大型券商集中交易系统实现架构的研究[J].计算机工程, 2006, 32 (9) :247-249.
[2]李媛媛.Linux Web集群在电子商务中的应用[J].商场现代化, 2007 (3) :141.
[3]李永喜.一种基于内容的Web服务器集群调度算法[J].计算机应用与软件, 2008, 25 (3) :215-216.
集群方案分析 篇6
随着信息化建设的快速发展,公司各类应用系统也不断增加。作为应用系统运行的基础平台,Oracle数据库的重要性也日益凸显。同时,由于应用系统的不断深化,应用数据量也在快速增长。因此,一方面,需保证数据库的容量,其性能要满足快速发展的应用系统;另一方面,已投入运行的松耦合应用系统已经成为公司生产经营管理的重要平台,如何保障Oracle集群的可靠性就成了非常重要的问题。
本文在讨论了Oracle双机热备和Oracle RAC集群的基本概念和体系结构后,对两种集群进行全方位的比较,并介绍了湖北省电力公司SG186松耦合应用系统的数据库集群部署实现方式。
1 Oracle双机热备集群
1.1 基本概念
Oracle双机热备即通常所说的Active/Standby方式,即2个或多个数据库主机连接一个共享的存储设备,当Active服务器出现故障的时候,通过软件监测(例如心跳诊断),将Standby服务器激活,保证Oracle服务在短时间内完全恢复正常使用。在实际应用中,双机热备需要集群软件的支持,目前常用的产品是IBM公司的高可用性集群多处理(HACMP)集群软件。
1.2 体系结构
以HACMP实现Oracle双机热备为例,由图1可知,HACMP运行在AIX之上,主机应用Oracle数据库。因此,Oracle数据库能够在HACMP的管理下实现双机热备,如果主机发生故障,Oracle数据库就可作为HACMP的一个资源,由备机来接管。
1.3 实现功能
Oracle双机热备只能解决一部分高可用性问题,例如,主机故障、主机上的操作系统故障、主机上的网卡故障、主机网络故障等,同时也无法避免一些问题,包括共享存储和主机本身的故障,而且主机不能完全避免停机,只能减少停机时间。另外,双机热备也不能解决容灾问题。
2 Oracle RAC集群
2.1 基本概念
实时应用集群(Oracle RAC,Real Application Clusters),起源于老版本的OPS(Oracle Parallel Server)。RAC可以实现多节点共享数据库,并发读写数据库,并自动并行处理及实现负载均衡,其中一个节点发生故障时能进行容错和恢复处理,可以实现节点的失败切换,保证数据库7×24 h的高可用性。另外,如果需要更高的计算处理能力,也可往集群中添加新的节点。因此,Oracle RAC为Oracle数据库提供了最高级别的可用性、可伸缩性和低成本计算能力。
2.2 体系结构
Oracle RAC的体系结构如图2所示,包含以下内容。
1)公共网络:这是数据库对外提供服务的网络,应用服务器通过该网络访问数据库服务器。通常情况下,主机都连接在一个或者两个网络交换机上,负责与外界通信。外部网络也有可能连接到不同的网络交换机,保证公共网络的可靠性和失败切换。
2)私有网络:除了公共网络,在主机之间有一个私有网络,这个网络用于在节点之间进行分布式计算、数据交互以及监测对方服务是否正常,在进行复杂分布式计算或者节点间有大量数据交互的时候,会出现较大的流量,因此一般通过交换机互联。
存储网络,一般采用SAN。
数据层可以分为以下5层:
1)CRS(Cluster Ready Ser-vices),Oracle 10 G以上版本中包含的集群软件,用来管理整个RAC环境,包括浮动IP、监听器、ASM存储、DB数据库等;
2)RAC,是Oracle的cluster支持组件;
3)Listener,监听Oracle网络;
4)ASM Inst,ASM服务实例,提供存储管理;
5)DB Inst,这是DB数据库服务层,也是整个RAC环境的最上层。
在RAC的实现中,如果存储管理层不采用ASM,也可以采用裸设备或者第三方存储管理软件(例如OCFS),同时双机集群软件就必须采用相应的Cluster软件,例如IBM公司的HACMP、Veritas公司的VCS等。
2.3 实现功能
Oracle RAC集群可以实现多个节点共享数据库,并自动并行处理及均衡分布负载。如果集群中的某个节点发生故障时,可以进行容错和恢复处理,可以实现节点的失败切换,保证数据库7×24 h的高可用性。同时还能提供主机保护与负载均衡的功能,并提供对RAC集群进行扩展,增加新节点,从而提供很好的可扩展性。但是,Oracle RAC不提供容灾的功能,因此,不能避免共享磁盘存储设备发生故障等类似问题。
2.4 RAC的实现方案比较
2.4.1 集群软件
目前市场上主流的集群软件有IBM HACMP、Veritas VCS、HP SERVICE GUARD等。另外,Oracle自10 G版本开始提供CRS集群软件。
2.4.2 共享存储的模式
1)裸设备。所谓裸设备,就是一种没有经过格式化的分区,也叫原始分区,是一种不需要通过文件系统来访问的特殊字符设备。在Linux下,通过块设备“绑定”到特殊字符设备得到裸设备。因为读写裸设备不需要像访问块设备那样经过内核的块缓冲,所有的I/O读写都是直接在进程的内存空间到物理的寻址空间进行。
此外,由于避免了文件系统处理的开销,所以使用裸设备对于读写频繁的应用(如Oracle、DB2等数据库系统)来说,可以很好地提升应用的性能。
2)OCFS文件系统。OCFS(Oracle Clustered File System)文件系统是Oracle厂商提供的标准集群文件系统,可以支持并发访问,支持Windows和Linux环境。不过由于目前OCFS不够稳定,因此一般用于测试环境或者小规模的数据库应用。
3)ASM自动存储管理。ASM(Automated Storage Management),即自动存储管理,它是自Oracle10 G这个版本Oracle推出的新功能。这是Oracle提供的一个卷管理器,用于替代操作系统所提供的LVM,它不仅支持单实例配置,也支持RAC这样的多实例配置,将给Oracle数据库管理员带来极大的方便。ASM可以自动管理磁盘组,并提供数据冗余和优化,特别是对于企业级的大型数据库管理员来说,可以使管理员从管理成百上千个数据文件这些琐碎的日常事务中解脱开来,以便处理其他更为重要的事务上去。
另外,从Oracle 10 G开始CRS软件与ASM存储管理设置,可以完全脱离第三方Cluster软件在各个平台上安装使用。同时,采用CRS+ASM的方案,不仅成本较低,而且实现了整个集群均采用Oracle产品,由单一厂商提供技术支持,避免了不同厂商相互推诿的问题。
4)第三方集群文件系统。目前,在市场上常见的第三方集群文件系统有:Aix下的GPFS、Veritas Clustered File(VCFS)等,并且技术较为成熟,便于维护。但是由于通过文件系统进行读写,因此性能上不如裸设备方式。各种存储模式的比较如表1所示。2种集群模式的比较(Oracle双机热备和Oracle RAC集群)如表2所示。
3 松耦合系统Oracle RAC数据库集群部署应用
目前,SG186工程松耦合系统包括安全监督与管理系统、纪检监查系统、审计系统、综合计划系统、应急管理系统、档案管理系统、国际合作系统、远程培训系统、法律事务管理系统等多个应用系统。因此,需要为松耦合应用系统搭建一个集中的Oracle数据库集群环境。通过上述对2种集群模式的全面比较,决定采用O-racle RAC集群方式实现集中数据库。
3.1 硬件环境
硬件部署如图3所示。
1)主机环境:采用2台IBM P5 560Q。
2)存储环境:采用IBM DS4700磁盘阵列,并采用2台光纤交换机,搭建SAN存储网络,从而避免单点故障,保障SAN环境的安全可靠性。
3)私有网络环境:采用2台内联交换机实现私有网络,保障私有网络的可靠性与失败切换。
4)公共网络环境:通过2个网卡分别与2个网络交换机相连,负责与外界通信,保证外部网络的可靠性与失败切换。
3.2 软件部署
该集群采用Oracle CRS 10 G集群软件,数据库软件采用RAC10 G和Oracle 10 G版本,共享存储模式采用ASM自动存储管理。因此,不仅成本较低,而且这种方式具备很强的可靠性、容错性及可扩展性。另外,由于整个集群设计的软件均采用Oracle产品,由单一厂商提供技术支持,避免了不同厂商相互推诿的情况。
4 结语
目前,湖北省电力公司松耦合系统Oracle RAC数据库集群运行稳定,为各个应用系统提供了可靠运行的数据基础平台。随着信息化建设的不断推进以及应用的持续深化,数据库的数据量和负荷也会逐渐增加,届时可以考虑在现有的集群基础上增加新节点以满足应用的需求。由于数据是整个企业信息化的核心,因此未来数据库集群仍然是热门话题,其实现技术也会不断的发展。
参考文献
[1]Vallath M.Oracle10G RAC Grid:Ser-vices&Clustering[M].Burlington(USA):Elsevier Digital Press,2006.
[2]Dyke J,Shaw S.Pro Oracle Database10G RAC on Linux:Installation,Administra-tion,and Performance[M].New York(USA):Springer-Verlag New York Inc,2006.
[3]Kyte T,苏金国.Oracle9i&10G编程艺术深入数据库体系结构[M].北京:人民邮电出版社,2006.
[4]张晓明.大话Oracle RAC集群、高可用性、备份与恢复[M].北京:人民邮电出版社,2011.
集群方案分析 篇7
在搭建电子商务系统数据库的时候,经常会遇到这些问题:(1)单一的服务器(注:本文提到的服务器均指数据库服务器)无论从CPU的处理能力还是网络的物理带宽都不能满足要求,用户需要多台服务器一起工作;(2)由于服务器崩溃所带来的损失是难以估量的,因此对系统的可靠性要求非常高,而且在发生故障的时候需要能快速恢复;(3)随着用户数量的不断增加,也需要适当地增加服务器的数量。电子商务系统需具备高性能、高可靠性、易拓展性等特性。在这些特性需求下,数据库集群技术应运而生。接下来,我们介绍一种基于MYSQL Replication的商务系统数据库集群技术的解决方案。
2. 对于数据库的选择
目前流行的数据库软件有:ORACLE、Sybase、Sql Server、DB2、My SQL、Access等。其中My SQL数据库因为其一贯的高性能、高可靠和易用性,成为全球最流行的开源数据库。Google、Yahoo!、亚马逊网站、新浪、网易等国内外许多大型的机构及公司都采用了My SQL。
My SQL有下面几种优势:
(1)普及性:My SQL是全球最流行的开源数据库,并且市场普及性与Sql Server等流行商业数据库软件相当。
(2)简单性:与其它数据库相比,My SQL使用更容易。
(3)低成本:作为开源数据库,My SQL可以让我们降低开发成本和部署成本,将资金更多地投入到其它方面。
(4)良好的支持:My SQL不同于一般的开源项目,它由My SQL公司拥有并提供支持。
(5)灵活性和可拓展性:My SQL有许多额外的可选功能,用户可以根据当前系统的需要进行制定调整。
因此,我们选择My SQL作为我们系统的数据库。
3. MYSQL集群技术
当前流行的MYSQL集群技术主要有两种:My SQL簇(My SQL NDB Cluster)和My SQL Replication。
3.1 MySQL簇(MySQL NDB Cluster)
My SQL簇[1,2]是一种技术,该技术允许在无共享的系统中部署“内存中”数据库的簇。通过无共享体系结构,系统能够使用廉价的硬件,而且对软硬件无特殊要求。此外,由于每个组件有自己的内存和磁盘,不存在单点故障。在My SQL簇中,每一个节点都是完全对等的,因此,对于用户来说,My SQL簇是完全透明的。用户根本不需要知道后台有多少个节点,而可以等值地认为只有一个服务器。然而这种技术存在着下面的缺点:
(1)安装成本比较高:因为My SQL簇是”内存中”的数据库,因此比正常的My SQL需要更多的资源。
(2)不能支持一些常用的特性,比如全文搜索、引用完整性等。
(3)实现方案相对复杂,维护较难。
3.2 MySQL Replication
考虑到My SQL簇的缺点,我们认为,对于绝大多数用户来说,My SQL Replication是更好的选择。My SQL Replication技术可以将主服务器(master)上的数据复制到一台或多台从服务器(slaver)上。人们使用它的目的通常有:提高数据库的服务性能、提高数据库的安全性、方便进行数据分析等[3]。由于这种数据复制是异步的(这有别于My SQL簇),从服务器不用每时每刻都连接着主服务器,因此对于连接的带宽没有像My SQL簇那么严格,用户可以根据自己的需求来设计不同的连接方式。
当我们用Replication来设计我们的解决方案时,必须考虑以下几点:
(1)可用性:Replication没有内建机制使replication达到高的可用性。因此,当我们在设计方案时,必须考虑提高系统的可用性。
(2)可拓展性:为提高性能,需考虑如何更方便地在数据库集群中增加服务器。
(3)透明性:My SQL Replication的服务器有主服务器和从服务器之分,主服务器可以进行读写操作,从服务器只能进行读操作。对于用户来说,My SQL Replication是不完全透明的(这一点有区别于My SQL簇)。我们要解决的是尽量使My SQL Replication对用户透明。
4. 解决方案
上面我们已经介绍了我们要采用的My SQL Replication技术以及要需要注意的问题。在接下来这一小节里,我们会介绍基于My SQL Replication的具体解决方案。
首先,我们必须考虑怎样使数据库集群达到高可用性及高可拓展性。基于文献[4]和[5]的描述,我们给出了当前三种比较流行的服务器组织结构,如图1所示。在表1中,我们给出了这三种组织结构的性能比较。经过比较可以看出,“双主服务器”结构具有最高的可用性及最容易进行故障恢复。因此,我们选择它作为我们的组织结构的基础。
当我们决定了服务器的组织结构之后,接下来要考虑的是怎样使得My SQL Replication对用户是透明的,即主服务器和从服务器的无差别性。很显然,通过修改源代码而使My SQL Replication对用户具有透明性的做法是不现实的,毕竟这是个很大的工程。幸运的是,我们发现了My SQL-Proxy是一个免费的软件,我们可以利用它达到我们的效果而无需修改源代码。我们把My SQL-Proxy加在每个从服务器前面使它像一个代理一样工作:先接受SQL请求,接着做一些处理,对读写请求进行分离,将读操作发给从服务器,将写操作发给附近的主服务器,从而使得整个系统对于用户来说是透明的。
最后,我们要考虑的是:当某一台主机发生故障时,系统怎样快速地进行故障恢复。人工干预的做法是不现实的,因为管理员不能二十四小时盯着系统。我们需要一种自动的故障恢复工具:免费而实用的Mon。Mon能帮我们监视系统,一旦发现系统出错,它能够执行故障恢复程序以便使系统重新运行正常。
因此,我们的设计方案结构如图2所示,来自客户端的数据库操作请求无差别地发往各个服务器,如果对应的服务器是主服务器则直接执行,如果对应的服务器是从服务器,则首先经过My SQL-Proxy处理。读操作直接发到从服务器执行;而写操作,则发往对应的主服务器执行,再将结果反馈给从服务器。整个系统都处于Mon的监控中。
我们将此设计方案应用于某商务系统,达到了我们预期的要求。
5. 结论
本文介绍了My SQL簇和My SQL Replication两种My QL的数据库集群技术,并设计了一种基于My SQL Replication的商务系统数据库集群的解决方案。此方案具有很好的稳定性、可用性、可拓展性,可以作为建立类似系统的一个参考。
摘要：随着电子商务的快速发展,人们对商务系统数据库的稳定性、可用性、可拓展性等提出了更高的要求,而单一的数据库服务器往往达不到这些要求。数据库集群技术的出现,为我们解决这个问题提供了很好的方法。比较了MySQL簇和MySQL Replication两种MySQL的数据库集群技术,并设计了一种基于MySQL Replication的商务系统数据库集群的解决方案。
关键词：电子商务系统,数据库集群,MySQL Replication
参考文献
[1].Mikael Ronstrom,Lars Thalmann.MySQL Cluster Architecture Overview[EB/OL].http://www.jimdowling.info/tmp/research/mysql%20whitepapers/mysql-cluster-technical-whitepaper.pdf.
[2].MySQL5.1Reference Manual:Chapter17[EB/OL].MySQL Cluster NDB6.X/7.X,http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster.html.
[3]MySQL5.1Reference Manual:Chapter16[EB/OL].http://dev.mysql.com/doc/refman/5.1/en/replication.html.
[4]Jeremy Zawodny.Managing MySQL Replication[EB/OL].http://pascal.case.unibz.it/retrieve/3124/Using-MySQL-Replication-in-Large-Scales.pdfowToTestAnIPS.pdf