存储虚拟化

存储虚拟化

存储虚拟化

随着存储的需求呈螺旋式向上增长，公司内的存储服务器和阵列都无一例外地随之成倍增长。对于这种存储管理困境的一种解决办法便是存储虚拟化。存储虚拟化可以使管理程序员将不同的存储作为单个集合的资源来进行识别、配置和管理。存储虚拟化是存储整合的一个重要组成部分，它能减少管理问题，而且能够提高存储利用率，这样可以降低新增存储的费用。

权威机构S N I A（存储网络工业协会）给出的定义

“通过将存储系统/子系统的内部功能从应用程序、计算服务器、网络资源中进行抽象、隐藏或隔离，实现独立于应用程序、网络的存储与数据管理”。

存储虚拟化技术将底层存储设备进行抽象化统一管理，向服务器层屏蔽存储设备硬件的特殊性，而只保留其统一的逻辑特性，从而实现了存储系统的集中、统一、方便的管理。

与传统存储的比较

与传统存储相比，虚拟化存储的优点主要体现在：磁盘利用率高，传统存储技术的磁盘利用率一般只有30－70%，而采用虚拟化技术后的磁盘利用率高达70－90%；存储灵活，可以适应不同厂商、不同类别的异构存储平台，为存储资源管理提供了更好的灵活性；管理方便，提供了一个大容量存储系统集中管理的手段，避免了由于存储设备扩充所带来的管理方面的麻烦；性能更好，虚拟化存储系统可以很好地进行负载均衡，把每一次数据访问所需的带宽合理地分配到各个存储模块上，提高了系统的整体访问带宽。

分类

虚拟化存储有多种分类方法，从大的方面可以分为：根据在I/O路径中实现虚拟化的位置不同进行分类；根据控制路径和数据路径的不同进行分类。根据在I/O路径中实现虚拟化的位置不同，虚拟化存储可以分为主机的虚拟存储、网络的虚拟存储、存储设备的虚拟存储。根据控制路径和数据路径的不同，虚拟化存储分为对称虚拟化与不对称虚拟化。

优缺点

优点：

存储虚拟化也能够改进可用性。如果一个应用程序与某些特定的存储资源相联，那么任何对于这些资源的中断都将会降低该应用的可用性。通过存储虚拟化，应用程序就不会再与某个物理性的存储程序相联系了。

存储虚拟化可能帮助帮助存储容量扩增自动化。不需要手动的配置，存储虚拟化能够运用策略，分配更多的存储容量给所需的应用。存储虚拟化也可以允许存储资源在传送的过程上进行更改或者升级，这些操作都无需中断应用性能，减少了为修理和维护所需要的存储宕机时间。

缺点：

存储虚拟化的不利方面是额外增加的复杂性。存储层是存储环境新增的部分，随着虚拟产品打补丁和更新，必须进行管理和维护。同样，存储设备之间的互操作性和兼容性也会有所影响。在一些情况下，虚拟层可能会与存储系统的某些特性相干扰，比如远程复制。比如说，一个包含本地远程复制的存储阵列，当这个阵列被用在虚拟化环境时，也许就不能够再提供这种复制的服务。只有在实验室的试验和评估结果才能够显示出这种潜在的问题。

另一个问题就是一旦存储虚拟化实施后，重新恢复或是取消操作存在的困难。这并不是不可能，但是重新将应用与存储位置进行关联的过程很容易出错。专家们建议逐步实施局部的存储虚拟化，先在一个或几个应用中局部部署，然后再扩大至数据中心和整个公司内部。

三层模型

根据云存储系统的构成和特点，可将虚拟化存储的模型分为三层：物理设备虚拟化层、存储节点虚拟化层、存储区域网络虚拟化层。三层虚拟化存储模型大大降低了存储管理的复杂度，有效地封装了底层存储设备的复杂性和多样性，使系统具备了更好的扩展性和灵活性。用户只需将存储设备添加到存储池中并进行简单配置，就可以创建虚拟卷，而不必关注系统中单个设备的物理存储容量和存储介质的属性，从而实现统一的存储管理。

• 物理设备虚拟化层：

主要用来进行数据块级别的资源分配和管理，利用底层物理设备创建一个连续的逻辑地址空间，即存储池。根据物理设备的属性和用户的需求，存储池可以有多个不同的数据属性，例如读写特征、性能权重和可靠性等级。按需分配的存储设备作为一个逻辑卷管理器，可以从存储池中分配逻辑卷，动态地分配存储资源，并管理数据块的映射和转发。

• 存储节点虚拟化层：

可实现存储节点内部多个存储池之间的资源分配和管理，将一个或者多个按需分配的存储池整合为在存储节点范围内的统一的虚拟存储池。这个虚拟化层由存储节点虚拟模块在存储节点内部实现，对下管理按需分配的存储设备，对上支持存储区域网络虚拟化层。

• 存储区域网络虚拟化层：

可实现存储节点之间的资源分配和管理，集中地管理所有存储设备上的存储池，以组成一个统一的虚拟存储池。这个虚拟化层由虚拟存储管理模块在虚拟存储管理服务器上实现，以带外虚拟化方式管理虚拟存储系统的资源分配，为虚拟磁盘管理提供地址映射、查询等服务。

三种目前能够实现的存储虚拟化方法

存储虚拟化是物理存储的集合，也就是将多个网络存储设备集合成一个存储设备，这样就能简化存储管理。人们都在讨论实现存储虚拟化的最好方法，但是没有一种方法可以适用于任何环境。实际上，许多公司都是根据具体要求采用不同的架构方式。你需要比较各种方法，然后根据自身需要选择合适的存储虚拟化方法。下面简单地介绍带内、带外和独立路径存储虚拟化方法：

• 带内（In-band）/对称存储虚拟化技术

带内方法主要在主服务器和存储设备之间实现虚拟功能，是传统的产品和存储系统经常采用的方法。
特征：带内/对称存储虚拟化技术采用x86软件或专有硬件以及软件存储系统，看起来就像是始于存储设备，终于主服务器。这是最常见的存储虚拟化形式。
优点：无需代理主机，相关部署实例和超高速缓存能够帮助实现各项性能，同时保持灵活性。
注意事项：数据通道中可能会存在一些性能问题
寻找：能够扩大查找范围、实现互操作功能，且不会使系统变得复杂和不稳定，也不会增加系统成本。
实例：传统的存储系统、产品，如IBM SVC、FalconStor软件公司和 DataCore 软件公司的相关产品。

•  带外(Out-of-band)/非对称存储虚拟化技术

带外存储虚拟化设备安装在主机和存储之间的数据通道之外，因而主机中需要安装专门的软件。
特征：带外/非对称存储虚拟化技术可以减少带内存储所存在的性能问题。但是，带外存储需要依靠代理主机和元数据控制器访问存储设备，这样就使存储虚拟化变复杂了。
优点：扩展性能较好。
注意事项：逐渐被独立路径存储虚拟化技术取代。
寻找：在带内和独立路径技术之外，寻找稳定、适应能力强的供应商和解决方案。
实例：LSI StoreAge

• 分离路径存储虚拟化技术

分离路径存储虚拟化技术综合了带内和带外技术的优点：
特征：分离路径存储虚拟化技术在与软件绑定的开关或者产品中采用存储服务模块或者适应器。
优点：部署更加灵活，解决了数据通道问题。
注意事项：提供给你软件的供应商还处于成长阶段。
寻找：寻找稳定的供应商、能够共存的扩展方案，同时支持不同的软件和硬件。
实例：LSI StoreAge, Incipient公司的相关产品, EMC 公司的 Invista, Fujitsu VS9000

实施存储虚拟化后移除有困难吗

如果在存储架构上的其中一层应用了存储虚拟化，那么移除或“退出”虚拟层有困难吗？要采取什么措施来提高成功率或减小放弃虚拟层的破坏性？

存储虚拟化对于公司是一个重要的的决定。对你所做的一定要谨慎，因为去掉虚拟化并不容易。一旦你部署了虚拟化环境，从存储到服务器以及物理存储之间是完全抽象的，IT存储管理员不知道存储是来源于哪里。几年来你可能要依赖存储虚拟化厂商的产品，因此，仔细挑选一个厂商是绝对重要的。

你可以退出存储虚拟化，但这是一个头疼的问题。你需要在某个地方备份你的数据，移除虚拟层，然后把数据备份到物理存储设备上。

应用

虚拟化存储在各种行业中已经开始了大规模应用。

这些应用包括：

数据中心：应用虚拟化技术提供计算和存储服务中心、网络管理中心、灾难恢复中心、IT资源租赁中心等服务。

电信行业：随着产业的发展，电信行业面临两方面的挑战，一方面降低IT架构的成本，另一方面提高IT架构的可用性。虚拟化技术正是解决这一问题有效办法。

银行证券保险行业：利用虚拟化进行容灾，采取“两地三中心”方案，即生产中心、同城灾备中心、异地灾备中心。同城灾备中心负责一般性灾难的防范，异地灾备中心用来防范大范围的灾难。利用虚拟化技术，可以在统一的虚拟化基础架构中，实现跨数据中心的虚拟化管理。

政府信息系统：政府数据存储系统的建设正受到前所未有的重视。系统利用先进的存储虚拟化技术，建立统一、标准、共享的数据资源存储平台，能够有效地管理庞大、繁多、复杂的数据及相关的设备，提高资源利用率，并建立起全面的数据安全保障体系。

HBase一次慢查询请求的问题排查与解决过程

作者: 大圆那些事 | 文章可以转载，请以超链接形式标明文章原始出处和作者信息

网址: http://www.cnblogs.com/panfeng412/archive/2013/06/08/hbase-slow-query-troubleshooting.html

最近HBase集群遇到过一次慢查询请求的问题，下面是对这一问题的具体描述及排查解决过程。

1. 发现问题

项目中有一张HBase表，每天凌晨以后会集中批量导入一批数据，导入数据量很大，在千万到亿的量级，然后白天为用户提供查询服务。某天突然发现，该表按照各个region（共计256个）分别仅scan少数几条数据时，部分region的查询请求的响应时间很慢，长达10秒甚至几十秒不等。

2. 排查问题

首先，通过查看HBase自带的region server监控界面上，看到这张表的每个region下面只有1~3个StoreFile，排除了由于StoreFile过多导致查询响应慢的情况。

接着排查，发现这张表的TTL为5天，因此会有大量过期数据存在。同时，由于这张表每天早上会导入一批数据（其中上周3.22那天集中导入了7亿多条记录），而集群的major compact周期配置是7天，虽然到今天为止3.22号的数据已经过期了，但是还没有经过major compact触发清除过期的数据，因此，存在大量过期但尚未被清除的数据，导致即使按照各个region分别仅scan少数几条数据，仍需要过滤掉一大批过期的数据（从监控看到当时的Block Cache访问量比平时高了一倍左右，如下图所示），才能扫到实际有用的数据，所以查询响应时间很慢。

3. 解决问题

针对这一问题，有以下两种解决方法：

1）每天早上导入数据后，强制触发一次major compact操作（见HBaseAdmin的majorCompct方法，异步执行），使得表中每个region中的过期数据可以被及时清除掉。

2）由于集群的major compact周期为7天，而表的TTL为5天，因此可以将major compact周期调小（配置参数为hbase.hregion.majorcompaction，单位为毫秒；同时，hbase.offpeak.start.hour可以设置major compact启动的小时，例如，设置为1，可保证在1点后触发），从集群级别保证major compact尽早触发执行。