Scale Out将是未来的企业架构

来源:互联网 发布:日文游戏汉化软件 编辑:程序博客网 时间:2024/05/22 04:25


从企业IT架构体系上来看,特别是对于Web2.0网站来说,必须考虑的就是可扩展性:随着使用人数的增多,能够及时的扩展IT系统的能力。解决这个问题,通常有两种解决方式:Scale up和Scale out,两种扩容的方式分别从两个维度来解决数据库压力。

Scale Out(横向扩展):从字面意思来看,Scale Out是使用靠增加处理器来提升运算能力和增加独立服务器来增加运算能力。就是指企业可以根据需求增加不同的服务器和存储应用,依靠多部服务器、存储协同运算,借负载平衡及容错等功能来提高运算能力及可靠度。

Scale Up(纵向扩展):指企业后端大型服务器以增加处理器等运算资源进行升级以获得对应用性能的要求,但是更大更强的服务器同时也是更昂贵的,往往成本会大于部署大量相对便宜的服务器来实现性能的提升,这当中的代表当属IBM zSeries大型机。而且服务器性能所能提高的程度也有一定的上限。

Scale Up劣势渐现

目前来看,一般来讲Scale out要比Scale up便宜。各大搜索引擎普遍采用普通x86服务器+Linux组成的scale out架构,其它主流web服务也大多采用这种架构,例如Yahoo、Taobao、新浪等,而一些ERP厂商入用友近两年来也开始大量放弃价格昂贵的RISC架构。

从数据存储的角度来看,曾经当我们需要构架一个不断增长的大型数据中心时,Scale up存储系统几乎是最好的,唯一的的选择。但是这也意味着当加入昂贵的存储设备时,业务需要中断且更难以管理。当然,Scale up存储系统前端处理能力和后端的磁盘数量还可以不断扩展,但总体来说,都是在一个固定的存储系统架构上去升级扩展,当扩展到一定程度,就很难继续扩展下去,尤其是前端控制器的数量。也因此导致了当后端磁盘不断增多,而前端控制器无法扩展的情况下产生的性能瓶颈。

Scale Out将是未来的企业架构

现在,有了scale out存储系统,一切似乎变得简单多了。部署工作大大简化,储存架构达到上亿级。另外Scale up架构每加一个结点进来,性能和容量同时增长,不会影响原有使用。用户按需采购存储,一旦容量不够了,再购置一台接到原有存储上就可以了。

所以未来的企业架构应该使用向外扩展(Scale Out)来实现可扩展性,同时可以让使用者得以保留通过增加服务器以提升系统能力的后路。

从存储来看,未来的企业需要的是一个能够应对非结构化数据激增带来的巨大挑战的架构,横向扩展存储系统的基础是NAS空间,可以添加若干并行工作的节点并作为一个节点进行管理,从而实现吞吐量和容量的独立扩展。在单一系统映像下,这些系统可以扩展到多个PB级存储,从而使它们成为理想的整合平台。

同时,横向扩展存储池可对底层存储进行虚拟化,创建可随业务需求变化而动态调整的资源,带宽、处理能力和存储容量可以单独调整和实时扩展。这种资源创建概念对当前持续不断增加的企业基础设施获得更高的可用性和可靠性至关重要。横向扩展存储有利于最大程度地降低管理成本、数据中心空间、电源和冷却需求。共享资源池可提供更高的利用率,极大地减少浪费。横向扩展存储的经济价值体现在改进扩展能力、加速配置、提升性能和简化管理、提高存储利用率等方面。

横向扩展存储系统克服了物理机架和模块的限制,可作为单一系统,通过增加控制器或是容量节点来实现性能和容量的独立升级,提高IT投入的回报率。同时,线性扩展能力为业务的长期高性价比提供保障。解决了传统单一系统,模块化系统需要物理磁盘级别的管理、数据布局和性能调优的弊端。横向扩展平台不仅能够提升性能而且还可以降低操作成本,使单一系统在单一全局域名下,简单地扩展到若干PB容量范围,成为管理猛增数据的理想存储平台。

2011年,由于企业IT用户对其存储系统的扩展性、灵活性和性能需求的增长,横向扩展的存储产品和方案不断涌现。EMC、HDS和NetApp都已经推出扩展性更好的X86的解决方案,如:EMC的VMAX平台(SAN)和Isilon 产品(多协议);HDS的USP-V (SAN)、VSP introduction (SAN)和 HNAS (BlueArc-based NAS 系统);以及NetApp的GX (now ONTAP 8 Cluster Mode) NAS系统;而国内厂商华赛也在去年推出自己的平面扩展产品HS的OceanSpace 5000。同时,IBM的DS8000系列所构成的系统也具有横向扩展的特征。

在开源软件方面,也有许多横向扩展存储解决方案,比如Lustre, PVFS2, GlusterFS等集群文件系统,HDFS, KFS, MFS,FastDFS, TaobaoFS等分布式文件系统。

横向扩展的瓶颈问题

现实的问题,如果要实现Scale out架构必然要面对分布式计算的问题,而目前基于分布式计算的解决方案已经有很多,比如Hadoop、Mapr等等,但问题也在于,基于分布式计算的性能优化一直是企业未能大量采用的瓶颈之一。

其次,Scale Out方案还需要对原先是用的软件进行大量的重写工作,以保证系统能在分布式服务器上运行(Scale Up方案则对现有软件几乎没有改动要求)。这一步往往是每个公司的开发人员的噩梦。

再者,Scale Out方案始终面临着数据集中的问题,即拆分过的数据在服务器逻辑体系中仍然是各自相对集中的而非无限随意拆分。如果大量的逻辑放在传统的数据库服务器一端,数据库服务器将会使得系统失去Scale out的能力和可能。因此,要保证Scale out的能力就必须保证数据库只处理实质性的数据提交和不可避免的数据查询,这也是以MongoDB、Redis等全新的NoSQL解决方案日渐受到青睐的原因。

对于分布式计算的技术问题,国外有一些开源的项目,我们可以借鉴,在一定程度上可以去努力解决。与此同时,我们还需要考虑到我们自身网站的数据的特点。像联机游戏、IM、BSP这些数据,通常每个用户都可以抽象成一个数据对象,可以独立存储在任何一个地方,数据之间关联度不大,这种情况比较适合采用 Scale Out的方式。但对于另外一些数据,比如电子商务网站的买卖信息,它们之间的关联度大,这时候往往查询需要耗费很多的资源;还有一些事物型的应用,保证数据的完整性是更为重要的,在这个时候,采用Scale Out的方式不一定适合。从整体上看,采用Scale out的方式是web2.0网站的主流,适应了网站数据不断且不太好预计增长的主要需求,而Scale up这种方式更为适合业务数据具有较强关联性且数据增长可预期的企业。

0 0
原创粉丝点击