分层存储架构的选择明细

　　许多组织同时转向服务器和存储虚拟化来解决其数据增长和成本问题。目标是建立一个更加灵活、反应灵敏、成本合理的架构。
　　
　　对于小型网络，基于网络的虚拟设备可以运行得很好，但是其整合还是需要终端用户来完成。许多公司选择只做到这一步，即将存储阵列虚拟化到一个虚拟设备的背后。这里的一个关键问题是这些公司能够在何种程度上在所有存储领域中成功地采用这项策略。尤其是，例如，如果该虚拟设备的可用性低于连接在该虚拟设备背后的设备的时候，结果会是怎样？同时，如果由于和虚拟化阵列相关的费用限制，一个虚拟设备不能支持该应用所要求的响应时间，那么这个虚拟设备就不能被包括在虚拟化策略内。此外，在所支持的逻辑单元号上，这种虚拟设备经常有限制，需要安装更多的虚拟设备--增加了复杂性和开支。尤其是，跨设备的存储不能在一个逻辑池里面就能被虚拟化。
　　
　　在大型网络，出于架构考虑，用存储控制器来处理所有的数据完整性和数据迁移问题可能是有利的，而且该管理器具有在架构内外同时支持虚拟化阵列的能力。这种方式能够允许所安装的资产和更低成本的阵列连接上来。随着自动精简配置的采用(能够在逻辑上将存储过量分配给某一个应用，但是在物理上实际上只配置了当时所需要的存储)，这种方式变得更加具有吸引力。但是，这种方法还是有一些整合问题，包括建立这种架构和将现有数据和架构迁移到新的系统中会产生中断问题。
　　
　　为使分层存储架构方案进入虚拟化(或是一个虚拟化环境中的一个辅助性节点)，越来越多的厂商提供内置型分层存储架构解决方案，使用低成本SATA(串行接口)设备，例如，连同高性能的光纤通道驱动器。这只是一个很简单的方法，但是它确实能够整合不同的存储阵列。范围得到显著提升的簇集式控制器的发展使得这些方式更加有吸引力;但是，这种技术还只是刚刚出现。
　　
　　从技术整合的角度看，用户不可试图寻找万灵药(例如，跨数据中心的单一异构解决方案)。基于块和文件的存储还是非常分散的，进一步分化了存储策略。此外，用户还要专注于数据分类、政策、自动化，并且将那些能够减少迁移和配置问题的技术给整合起来。
　　　　
　　许多有兴趣解决SAN问题--如速度慢、存储增长超过控制、难以承受的迁移成本的公司开始转向分层存储架构并采取以下措施：
　　
　　●明确定义恢复点目标(RPO)和恢复时间目标(RTO)，并将这个作为数据放置的依据(相对于业务范围导向且没有明确目标的一级服务)；
　　
　　●同业务部门沟通这些要求，允许IT部门根据这些政策方针来进行存储分配；
　　
　　●简化层级，要求最严格的应用程序放在一级(根据服务层次)，其他的缺省地放在二级，并且根据记录管理和保留政策--按照法律规定和公司要求--迁移到三级存储；
　　
　　●虚拟化前端和后端资源，在存储阵列外提供一个服务层，并逐渐倚重低成本阵列来降低硬件成本和减少昂贵的存储软件许可证支出。虚拟化所有可能二级存储，尽量虚拟化一级存储；
　　
　　●存储管理软件和流程，减少现有的存储管理软件套件，如果可能，减少到一个套件;而且按应用程序分组，仔细测试虚拟化的可靠性和性能，在合理的时间范围内进行部署；
　　
　　在建立了一个单一的SAN环境之后尽可能快地实施分层存储架构策略。
　　
　　自然，这些策略还在发展中，而且还有一定的风险，即虚拟化复杂性，性能问题，可用行问题(例如，将一个一级存储阵列放在一个中等虚拟化设备的后面)。而且虽然这些方法看起来能够明显简化IT环境并减少硬件、软件和迁移成本，但是它们非常依赖于厂商(们)所提供的虚拟化技术。用户在管理这些风险的时候需要有极其谨慎的心态，实行保守计划，采取兆级管理策略--这些兆级管理策略不单单依赖于厂商提供的产品，而是将组织作为一个整体来抓住其流程。虽然有这些问题和潜在的锁定风险，50%的期望成本节约还是使得分层管理成为一个有吸引力的目标。

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。