e-works数字化企业网  »  文章频道  »  基础信息化  »  数据中心

数据中心存储架构的进化

2017/8/24    来源:TWT    作者:佚名      
关键字:数据中心  存储架构  
随着企业业务种类的增多和业务规模的膨胀,传统的简单直连DAS架构已经无法适应日益复杂的IT环境,集中式SAN和NAS架构已经成了现阶段大多数企业的主存储架构,这种架构可以充分利用后端存储资源,轻松实现数据在单个阵列和多个阵列之间的流动,通过引入存储虚拟化技术,可以进一步显著提高存储资源利用率,增强存储架构的安全性,同时实现更多高效的软件特性。
    引言
 
    随着企业业务种类的增多和业务规模的膨胀,传统的简单直连DAS架构已经无法适应日益复杂的IT环境,集中式SAN和NAS架构已经成了现阶段大多数企业的主存储架构,这种架构可以充分利用后端存储资源,轻松实现数据在单个阵列和多个阵列之间的流动,通过引入存储虚拟化技术,可以进一步显著提高存储资源利用率,增强存储架构的安全性,同时实现更多高效的软件特性。在互联网思维下,诞生了SERVER SAN的架构,这种架构极大增强了存储架构的弹性和高可用性。另外,随着业务实时性的增强,需要按照不同的RTO和RPO指标构建相应的本地和异地的数据完整性保护方案。随着数据量的骤增和IT架构复杂性的日益加剧,后端存储的IO性能问题开始浮现并逐渐成为很多企业的关注点和痛点,全闪存阵列,在单位容量和机架空间上可以提供传统高端存储无法企及的极致IO性能指标,可以说当下的全闪存阵列在寻求“快”的同时也在逐步完善作为企业级存储的最关键的“稳”,全闪存阵列日趋完备的特性势必使其在今后数据中心的架构中大放异彩!
 
    本文行文思路主要围绕笔者所在公司数据中心存储架构的发展,同时对近期业内主流厂商全闪存阵列的实地测试进行总结和拓展。
 
    1. 数据中心存储架构演进历经的几个阶段
 
    随着企业业务种类和规模的膨胀,数据中心存储架构的演进从初始的简单直连的DAS架构发展为当下主流的SAN和NAS架构,如下图所示:
 
DAS架构向SAN和NAS架构的进化
 
图1 DAS架构向SAN和NAS架构的进化
 
    直连存储也就是DAS架构,可以把内置盘也归属到这种架构中。前端主机通过SCSI、SAS或者FC等适配器和磁盘阵列直接连接,磁盘的RAID功能可以在阵列端的controller亦或是主机端的适配器上进行配置。这种拓扑结构简洁、部署方便,同时少了主机和阵列间Fabric带来的IO延迟,是一种独享存储的连接方式。早期的这种DAS架构,存储部署不集中,存在所谓的信息孤岛,造成存储资源利用率低。
 
    而对于SAN和NAS拓扑,这种拓扑提高了存储资源的利用率,同时通过SAN的zoning配置和网络交换机的ACL配置增强了主机接入存储的安全性。直到今天,SAN和NAS架构仍然是大部分传统信息企业采用的主存储架构。通过在SAN架构中引入存储虚拟化设备如IBM的SVC、EMC的VPLEX等设备可以实现异构阵列的整合,从而进一步提高存储的利用率,同时通过高可用设置可以规避阵列单点故障。存储虚拟化技术带来了太多的好处,无论是资源的整合、虚拟化层统一实现的高级软件特性,如存储分层、实时压缩、精简配置、数据本地多副本复制以及远程异地容灾功能,另外在管理运维的维度也大大简化了存储管理员的工作负载。
 
    其实,DAS架构并没有因此销声匿迹,反而顺应了“分久必合合久必分”的大势,但是与早期DAS不同的是,当下的DAS架构主要用在SERVER SAN这种分布式的计算环境当中。VMWARE的VSAN也是这种分布式的架构。通过节点的灵活增减以及多副本特性,这种架构有很强的伸缩性、可扩展性和高可用性。通过上层的集群软件和分布式文件系统,可以将异构的硬件整合为一个整体的存储单元对外提供服务。
 
    2. 无间断业务系统带来的苛刻RAS指标
 
    现在大多数企业的生产系统基本都是7*24小时无间断运转的状态,因此这对后端的IT基础设施提出了苛刻的可靠性、可用性和可维护性指标。
 
    各系统部件本身要采用全冗余设计,当然,各主流厂商的商用硬件已经充分考虑了各部件、模块甚至是芯片级的冗余设计。同时冗余还必须考虑存储和以太网链路的冗余连接。
 
    主机端在应用级和操作系统级别都可以部署HA高可用集群软件保证业务系统的高可用。另外可以通过虚拟化技术实现高可用和容错,比如在物理机维护升级时,可以将其上运行的虚机在线无缝迁移到其他运行的主机上。
 
    存储端一方面可以通过存储虚拟化设备完成异构阵列之间的镜像,从而规避阵列单点故障;同时也可借助主机OS级别的LVM镜像技术,完成后端存储的1:1的映射,从而实现高可用
 
    3. RTO&RPO驱动的健壮容灾架构
 
    由于业务系统在发生灾难时,对RTO和RPO指标的要求越来越苛刻,因此需要搭建健壮的容灾架构,以实现在生产中心发生灾难无法继续对外提供服务时,灾备站点可以在SLA约束的时间窗口内完成生产业务的切换。
 
    当然不同的RTO和RPO指标要求会有不同的容灾方案。早期我们的灾备采用数据库备份磁带定期恢复,平时脚本传输归档并应用日志的方式保证两站点数据库数小时的差异状态;而前端的应用数据通过第三方的同步软件比如GOODSYNC完成数据的同步。这种容灾方案成本低,但需要过多的人为干预。随着业务级别的提升,我们采用存储级数据异步复制的设计,数据的差异状态已经缩短为小时级甚至是分钟级。同时结合虚拟化技术的SRM可以大幅减少人为干预,实现灾难发生时灾备的自动切换。当然,如果需要近乎为零的RPO和RTO,可以采用双活的架构。除了可以借助VPLEX搭建METRO双活架构外,还可以采用其他厂商的双活产品,如IBM SVC的METRO MIRROR、NETAPP的METROCLUSTER等。
 
    另外当生产中心业务系统发生一定时间段内的逻辑错误时,如果数据库未启用闪回,则只能依靠存储级的CDP技术实现业务数据的回滚,当然回滚时间轴的长度取决于记录生产数据改变的日志卷的大小。
 
    再完备的数据完整性解决方案都离不开备份这个环节,备份是数据保护的最后一道防线,信息系统必须设计可行、高效的备份方案。对于不同的数据源和不同等级的业务系统需要不同的备份技术,如针对数据库主机,我们可以采用LAN FREE的备份方式,减少备份时对CLIENT的性能影响,提高备份效率。对于NAS的备份,我么也有NDMP这种直接从存储到带库的备份方案可以进一步减小备份对CLIENT的性能干扰。对于虚机的备份,由于虚机文件的高度重复性,可以利用AVAMAR的消重特性,高效完成虚机的备份。
 
    4. 日趋短暂的业务窗口寻求极致的IO性能
 
    4.1 全闪存阵列测试背景
 
    随着存储架构复杂性的增加、应用的密集度增加、生产卷存在多个副本等因素的浮现,后端的存储系统IO愈发密集,各系统之间的IO争用也逐渐凸显。另一方面,信息企业的业务规模和数据量呈现爆炸式的增长,这无疑给支撑业务的后端IT基础设施带来了巨大的挑战,于是各种硬件升级和资源扩容成了每个企业必须面对的课题,而这其中存储的优化却显得尤为重要,这也不难理解,因为CPU、内存和各种内部总线的速度和发展已经远远超越了磁盘存储。另外,虚拟化的大举推进也使得I/O变得越来越密集,因此传统的基于HDD的磁盘阵列亦或是混插几块SSD作为FAST Cache存放热点数据的混合阵列已经无法满足IOPS、I/O latency和MBps throughput要求苛刻的业务了,于是AFA全闪存阵列应运而生。
 
    前不久我们公司有个关键结算业务已经开始出现不能在日结窗口内完成业务作业了,经过一系列的问题诊断,最终确定性能瓶颈在后端的磁盘阵列上,该业务部署在公司2007年采购的某厂商的高端磁盘阵列上,但是后端有限数量的磁盘配置无法提供业务需要的I/O性能指标,虽然后续通过增加磁盘数量和扩充存储前端板卡解决了性能问题,但长远看,为了应对性能要求越来越苛刻的业务,我们需要尽早做好全闪存阵列的技术储备、积累新技术的使用经验。
 
    正是在这种背景下,我们公司开始进行业内各主流厂商的AFA产品测试。下面主要谈下其中跻身AFA领域前列的IBM Flash System系列产品,我们选用了FS840这款产品。
 
    4.2 产品主要技术概览
 
    IBM Flash System 840这款产品可谓是高密度设计,有别于其他友商控制节点和磁盘柜分离,FS840在一体的机身中包含了两个控制器、两个电源、两个电池以及12个Flash板卡槽位,前端的Flash卡直接插在后端的控制器上,磁盘阵列各主要部件都是冗余设计。FS840提供2D即2维的数据冗余保护,在单个Flash板卡内部的内存芯片做一级RAID5的保护,同时Flash卡之间还可以做另一层RAID5或者是RAID0。另外,通过简洁清新的Web UI可以很容易完成存储的配置,几分钟就可以让FS840迅速上岗发挥作用。
 
    4.3 测试环境介绍
 
    本次我们拿到的FS840可谓是“完全定制化”的产品,仅配置了两块2T容量的Flash卡,从这个侧面也可以看出这种Flash卡的成本之高。两块Flash卡只能选择RAID0(在生产系统上这是绝对不许可的,但FS840不支持RAID1),测试使用存储1.6T,占FS840可用容量的42%,客户端是一台IBM Power7 P720主机,装有AIX6.1操作系统和Oracle 11g数据库,机器配置两块8Gb HBA卡,通过两个SAN fabric(均是8Gb)和FS840的4个端口(每个控制器两个端口,另外16Gb降级8Gb使用)连接,每个FS840的LUN有4个path,可见这是一个典型的生产环境的拓扑连接方式。
 
    4.4 FS840性能测试
 
    4.4.1 实际业务测试
 
    在上述的测试主机上的FS840提供的32*50GB个LUN上创建文件系统,然后RMAN恢复Oracle数据库,随后进行实际的业务测试。以下是Oracle数据库恢复时在FS840 Web UI上看到的接口IOPS的情况:
 
数据装载时FS840接口的IOPS
 
图2 数据装载时FS840接口的IOPS
 
8K 100%随机读性能曲线
 
图3 8K 100%随机读性能曲线
 
8K 100%随机读性能曲线
 
图4 1M 100%随机读性能曲线
 
8K 100%随机读性能曲线
 
图5 8K 随机读写(读写比7:3)性能曲线
 

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐