《架构设计中的存储设计系统架构设计.doc》由会员分享，可在线阅读，更多相关《架构设计中的存储设计系统架构设计.doc（6页珍藏版）》请在三一文库上搜索。
1、架构设计中的存储设计系统架构设计在大部分企业中，网络' 安全' 运行监控和应用往往已经安排了各种专职岗位，但对于实际保存企业最重要资产一一数据的存储工作往往被其他岗位兼任。数据存储的现实状况根据Gartner Group xx的数据显示，我们或许能得到答案。大部分企 业每2年数据量翻倍，对于Web 2.0之后催生的大量新应用，速度要更快。以 电信运营' 能源、流媒体增值服务等行业为代表的一批大型企业已经进入PB 时代。在企业IT运营投资中，存储的费用有 望在未来4年中有望从4%增加到 17%o用于数据管理和费用往往是存储平台投资的5-7倍。从上面的数据我们不难看出，虽然
2、现在有很多半概念化的热点技术（例 如：云' S0A、Web/En-terprise 2.0）,但存储确是我们要实 实在在面对的 问题，很多企业的CT0会在IT投入和实际效能之间作出如下权衡：首先，对于同一个业务应用，如果设计具有扩展能力的高可用方案意味着更多的投入。其次，存储架构是否可以满足企业现有（包括未来一段时间）应用、运行基础设施的需要，是否要设计成“积木”方式，以利于当前存储系统 不堪负载时可以通过购买或扩容线性的满足新的存储需求。第三，无论限于企业自己业务部门的需要还是合作伙伴、行业' 法规的 安全要求，如果在保护数据安全的前提下牺牲满足业务必要的性能，这同样不 可取
3、。因此，存储需要有自己的架构体系和设计思路，而且设计中面临的最大问题与我们设计一个应用系统类似一一 “变化”，尤其对很 多企业而 言，数据还没有类似服务那样，被总线集中在一起，大部分数据还是分布在不 同服务器的本地存储里，因此如何设计企业的存储架构要考虑多个因素：不 断增加的数据容量；不同网络段的吞吐能力；数据访问性能指标。而且对于 很多跨地域的企业，这个指标还应该包括物理位置的纬度。例如：下面是一个在北京、上海、深圳三地都有异地容灾的企 业，为了 确保实际灾难恢复能力，实际运行的数据中心只有一个，另外两个“温”节点 通过双向复制与运行节点（“热”节点）保持同步，那么对于位于山东' 浙
4、江的分支机构其访问时就会因运行节点' 接入网络的不同存在差异性，相 应的我们在制定访问时间指标时也要有所 差异化的考虑。例如，投资成本' 业 务系统的特点（比如：响应时间要求、分布式事务中需要协调的数据项 作方系统。）、遗留系统以及外部合鉴于上述原因，同时考虑到数据（结构化、非结构化、半结构化、关 系' 流信息）对于企业业务的重要性，如果不能在企业发展的特定 阶段对存 储作出一个全面的规划，那么它很可能成为企业IT环境发展的障碍。存储架构分析从使用角度来看，主流的存储技术包括DAS NAS和SAN三者 在易用性、 访问透明性' 冗余和扩展能力方面差异很大，而且投
5、资成本也随着应用规模、 数据容量、可靠性方面有很大差异，而且大部分企业中往往是多种技术产品并存的局面。不过从逻辑架构看，我们可以分成分布式存储、集中式存储和混合存储三种逻辑架构,而且在具 体环境中可以依据图2所示结构化的步骤实施。其中，图2中上面灰 色区域为存储架构部分，下面为存储架构与具体应 用、服务结合的部分。定义存储需求该部分主要关注三个指标：可用性' 容量、访问性能。虽然这 些指标都是 可以量化的，但关键在评估这个量非常不容易，比如：如 何评估准备加入存储体 系某个应用实际的数据量，设计中需要至少考虑下列因素：首先，逻辑数据量在不同数据库' 数据仓库产品中都会在物理容量
6、上放 大，这个需要基于企业或类似系统作对比，而不能仅仅按照开发组提出的那个“缩水”的版本划分存储还包括操作系统自身容量、应用软件容量' 业务数据容 量' 报文和过录文件的容量；根据可用性、冗余份数的要求，容量信息还需要成 倍增加。其次，在基本确定容量之后，我们应该对数据进行分类：操作系统环境数 据' 应用软件数据、用户数据，例如：因为用户加人需要的LDAP存储' 用户数据库信息' 用户客户端需要保存和使用的数据选择存储技术我们一般会选择DAS NAS SAN或三者的混合方案。由于各个存储技术在不同的场景下有比较明显的实用性差异,因此具体实施中可以考虑混合
7、型方式。这样，对于频繁使用的局域网处理可以在网内解决，而大容量 历史长线数据可以保存在SAN的阵列或带库中（现阶段，由于价格因素，带库的 使用量趋于减少）。此外，考虑到容灾的问题，还可以选择：数据复制（例如：图1中，三 个中心通过结队双向复制的方式，完成数据的异地容灾）、RAID （主要用于防止因本地硬件故障导致的问题）。然后，可以从逻辑 上按照企 业实际网络情况' 访问需要、数据分布情况设计集中式、分布式或混合型的逻辑 布局总的来说，将存储作为独立的架构考虑，即是由于业务发展用户应用的需 要，同时也是梳理企业IT环境，以及实施SOA、Web/Enterprise 2.0等大规 模平台应用的基础。与应用架构一样，存储架构本身也有其标准的迭代流程， 也是从需求出发的。虽然我们的意图是将存储设计成一个对应用和服务完全透 明的体系，但由于网 络' 物理位置的各种限制，达到这个目标并不容易，因此 如何采用统一的标准化存储接入设备、访问协议就成了架构的中心环节，很大 程度上它可以随着应用、服务、操作系统的变化，在配置层面协调存储 资源,而不是每次新上项目的时候，都先设计一个“权宜之计",然后再冒着数据完整性、一致性、安全性的风险把它“迁移”到整体存 储体系中。内容仅供参考