大话存储系列20——数据存储与数据管理综述
2013-04-08 14:49
239 查看
存储系统又两大部分内容:数据存储 和 数据管理。
数据存储包括:存储控制器硬件、磁盘、适配器、网络传输通道、RAID管理、LUN管理等,这部分主要功能就是提供基本的裸数据存储服务;
数据管理包括:Tier、Snapshot、Clone等数据处理模块。
存储系统实时监控物理空间使用情况,一旦所有用户整体空间消耗达到临界值,则需要马上扩大物理容量。然而,对于空间使用率的监控方面,如果存储系统为NAS系统,提供的是一个基于文件协议的卷共享,则存储系统本身就可以很容易地监控存储空间的真实耗费情况,因为NAS系统是自己来维护文件与物理空间对应关系的。
但是如果存储系统提供的是一个基于Block协议访问的空间,比如FC或者iSCSI协议的LUN,则存储系统所监控到的这个LUN在物理磁盘上所占用的空间使用率很大程度上是伪造的,存储系统所检测到的占用率永远大于其实际占用率,其原因是因为存储系统自身一般不能感知到这个LUN中文件系统中的实际文件所占用的空间,只有客户端主机才能看到,一种极端的情况:如果在使用这个LUN的客户端主机上曾经将数据塞满这个LUN但是随后由删除掉了,那么存储系统所看到的这个LUN的使用率永远为100%,而实际上是0.
从技术角度讲,存储系统想要监控LUN之内的实际数据使用率也不是什么难题,只要能够感知其上的文件系统逻辑即可查到,我们将会在随后详细描述。。。
好吧,我们接下来看一下存储系统对LUN实际占用空间的检测,可以选择简单模式、复杂模式和完美模式三种,我们分别通过介绍着三种模式,体会一下存储系统对LUN的检测效果:
简单模式:系统记录一个High Water Mark(高水位线),目标LUN曾经接收到的写IO所对应的LBA地址最长(最远)的那个,利用这个HWM来判断目标LUN实际占用的空间。比如一开始存储系统创建了一个大小为1TB的LUN,但是由于Thin Provisioning模式,这个LUN刚被创建的时候事不占用存储系统的物理空间的,系统只是记录一下,假设第一个IO就是向这个LUN的最后一个LBA地址写入数据,那么存储系统就会去判断是否已经超过了当前已经使用的最大的LBA地址,那么系统就会再分配一段物理空间给这个LUN。
复杂模式:系统可以识别简单模式不能识别到的信息,要识别出当前LUN真正需要的物理空间,就需要记录更多的信息,比如LUN中哪些地址被写过,哪些尚未被写过,而记录这种信息的最佳手段就是Bitmap,Bitmap中的每个bit可以表示一个BLock(或称Page,比如4KB、16KB大小),如果需要写数据,就把对应的位置1,系统分配物理空间给这个LUN,更新LUN的Metadata,然后将数据写入对应的BLOCK。但是这样还不是完美的模式,因为这个LUN之上还有一层论及在做映射,也就是文件系统(或者其他程序自身管理的数据映射机制),总是文件系统里把这个LUN中的文件数据删除,但是对于存储系统来说,它根本感知不到文件逻辑,所以此时这些被删除的文件依然占用物理的空间。
1、Thin Provision/Over Allocation(瘦供)
可以翻译成 “超供”,更合适一点,具体见我自己整理的这篇博客吧:http://blog.csdn.net/changyanmanman/article/details/8395527
数据存储包括:存储控制器硬件、磁盘、适配器、网络传输通道、RAID管理、LUN管理等,这部分主要功能就是提供基本的裸数据存储服务;
数据管理包括:Tier、Snapshot、Clone等数据处理模块。
存储系统实时监控物理空间使用情况,一旦所有用户整体空间消耗达到临界值,则需要马上扩大物理容量。然而,对于空间使用率的监控方面,如果存储系统为NAS系统,提供的是一个基于文件协议的卷共享,则存储系统本身就可以很容易地监控存储空间的真实耗费情况,因为NAS系统是自己来维护文件与物理空间对应关系的。
但是如果存储系统提供的是一个基于Block协议访问的空间,比如FC或者iSCSI协议的LUN,则存储系统所监控到的这个LUN在物理磁盘上所占用的空间使用率很大程度上是伪造的,存储系统所检测到的占用率永远大于其实际占用率,其原因是因为存储系统自身一般不能感知到这个LUN中文件系统中的实际文件所占用的空间,只有客户端主机才能看到,一种极端的情况:如果在使用这个LUN的客户端主机上曾经将数据塞满这个LUN但是随后由删除掉了,那么存储系统所看到的这个LUN的使用率永远为100%,而实际上是0.
从技术角度讲,存储系统想要监控LUN之内的实际数据使用率也不是什么难题,只要能够感知其上的文件系统逻辑即可查到,我们将会在随后详细描述。。。
好吧,我们接下来看一下存储系统对LUN实际占用空间的检测,可以选择简单模式、复杂模式和完美模式三种,我们分别通过介绍着三种模式,体会一下存储系统对LUN的检测效果:
简单模式:系统记录一个High Water Mark(高水位线),目标LUN曾经接收到的写IO所对应的LBA地址最长(最远)的那个,利用这个HWM来判断目标LUN实际占用的空间。比如一开始存储系统创建了一个大小为1TB的LUN,但是由于Thin Provisioning模式,这个LUN刚被创建的时候事不占用存储系统的物理空间的,系统只是记录一下,假设第一个IO就是向这个LUN的最后一个LBA地址写入数据,那么存储系统就会去判断是否已经超过了当前已经使用的最大的LBA地址,那么系统就会再分配一段物理空间给这个LUN。
复杂模式:系统可以识别简单模式不能识别到的信息,要识别出当前LUN真正需要的物理空间,就需要记录更多的信息,比如LUN中哪些地址被写过,哪些尚未被写过,而记录这种信息的最佳手段就是Bitmap,Bitmap中的每个bit可以表示一个BLock(或称Page,比如4KB、16KB大小),如果需要写数据,就把对应的位置1,系统分配物理空间给这个LUN,更新LUN的Metadata,然后将数据写入对应的BLOCK。但是这样还不是完美的模式,因为这个LUN之上还有一层论及在做映射,也就是文件系统(或者其他程序自身管理的数据映射机制),总是文件系统里把这个LUN中的文件数据删除,但是对于存储系统来说,它根本感知不到文件逻辑,所以此时这些被删除的文件依然占用物理的空间。
1、Thin Provision/Over Allocation(瘦供)
可以翻译成 “超供”,更合适一点,具体见我自己整理的这篇博客吧:http://blog.csdn.net/changyanmanman/article/details/8395527
相关文章推荐
- 大话存储系列20——数据存储与数据管理综述
- Trove系列(五)—Trove的数据存储管理程序类型和版本管理功能介绍
- 数据迁移管理系统综述(在线近线离线分级存储)
- 海量视频监控数据存储和管理是大数据最重要的命题
- 大数据的存储和管理
- 13.2管理网络冗余与数据存储群集
- Android学习系列(20)--App数据格式之解析Json
- 图书管理系统使用List 存储数据
- Sharepoin学习笔记—架构系列-- Sharepoint的数据模型(DataModel)、数据管理(Data Management)与查询(Query System)
- 在 Oracle 中存储与管理大对象数据类型
- 一共81个,开源大数据处理工具汇总:查询引擎、流式计算、迭代计算、离线计算、键值存储、表格存储、文件存储、资源管理、日志收集系统、消息系统、分布式服务、集群管理、基础设施、搜索引擎、数据挖掘=监控
- FAQs: 我们可以在那里来为我的没有提升管理权限的应用程序存储用户数据?
- 浅入浅出Oracle Spatial GeoRaster 10g影像数据管理(2)——物理存储
- Hadoop系列之一:大数据存储及处理平台产生的背景
- [Numpy] 数组数据的存储和管理
- 北信源::终端安全管理::内网安全管理::补丁管理::移动存储管理::网络接入控制::安全u盘::数据恢复::vrv::数据修复
- 数据结构基础(20) --图的存储结构
- 电影管理器之XML存储电影信息数据
- Hadoop系列(7):数据存储之数据存储模型
- DPM磁盘管理(连接远端存储)(DPM配置管理系列三)