有不等于好？惠普3PAR自动精简配置应用详解

HP 3PAR的瘦身(Thin Provisioning，自动精简配置)技术的颗粒度是有史以来最低的，以16KB为单位，其它的技术则需要从1MB到17GB不等的颗粒度，所以3PAR在以小数据块为主的核心T1应用中能够发挥更加显著的瘦身作用。同时用ASIC芯片的好处不仅是offload(卸载)了CPU，而且在IO“击中”ASIC芯片的时候，就完成了瘦身，因此实现了实时的瘦身和回收。也就是说当OS做delete或者drop的时候，只要使用适当的命令，空间立即就被释放掉了，同时没有任何实际的IO发生。

归根到底，虚卷(Virtual Volume)相对于实卷(Physical Volume)的好处在于，若干应用的使用空间可以共享同一个Pool(池)，就是俗称的所谓“用一张10人的桌子同时请了100人吃饭”，所以最大化了空间资源的利用率，避免了频繁的磁盘扩容。同时对于开发和测试类的工作很有帮助，例如一个新的应用在测试的期间用比较小的数据集和小范围的客户群，那么它的实际空间消耗就仅限于那么一点，当逐步扩大数据量和用户范围的时候，开销自然的变大，当真正的上线之时，达到最大或者说最合适的“尺寸”，这些都不需要再手工进行调整了。而关于每个VV或者CPG(Common Provisioning Group)的provisioning(分配)的细节可以用showvv/showcpg看到，从而产生详细的报表，在多租户的环境中，这个报表可以作为收费的依据。

不适合ThP(Thin Provisioning的缩写)的场景也有很多，比如满了(使用率80%以上)的文件系统，因为用户数众多，从高级别统计的意义上讲，有人删除文件，也有人不断的创建新文件，始终保持着FS的高占用率，那么就没有必要使用ThP;有些类型的应用持续的写新的空间，比如log(日志)和swap(交换文件)，那么空间的回收可能性接近于零;数据库没有运行在“auto-extend(自动扩展)”的模式，也就是说DB会时不时的拿一块空间过来，全部写上标记，把这块空间据为己有然后慢慢使用，这种“占有欲很强”的应用不适合用ThP。

TPVV适合的场景是大空间使用量的环境，从256MB到几十GB，太小的空间消耗就没必要用ThP了;大量的snap空间需要意味着快照所占的空间甚至会超过TPVV本身，当快照的空间达到或者超过TPVV的80%时，就不要用ThP了;使用加密卷时，即使写16K的零，加密算法也会导致内容的变化从而使ThP失效;ThP需要设置和变更策略，需要持续的监控空间使用和观察报警，对于习惯了“撒手不管”型的客户来说，这也是一种负担，不过可能也是购买驻场服务的机会。

TPVV的最小尺寸是256MB/1GB(P10000 V系列)，最大尺寸是16TB，只能增长，不能收缩，在使用TPVV的同时，应当相应配合地在主机上设置Quota(配额)。任何一个TPVV都从属于一个CPG，CPG的定义包含了：磁盘类型、转速、RAID、容量扩展单位、chunklet所在“圈位”、可靠性。之所以会有不同的CPG，是因为需要有：不同的RAID保护 / 不同的磁盘类型 / 把TPVV绑定在某些node(控制器节点)上 / 把TPVV限制在一小部分磁盘上从而避免相互的影响提高可靠性 / 完全同样属性的CPG可以起不同的名字，从而区隔不同的应用、部门、或者顺应某种管理的需要，收费时针对CPG而不是VV的报表更加实际和有针对性。当CPG所剩的空间小于“扩展单位”的75%时，CPG就会自动扩展了，但CPG的扩展幅度是比较大的，因为这些扩展单位必须“全局条带化”到所有底层磁盘上，CPG的扩展单位可以随时在线调整，当设成0的时候，CPG就不再自动扩展了，最小和缺省的扩展单位跟node数量有关，而最大扩展单位是2TB-256MB。

“扩展单位”只会影响新的LD而不会影响现存的LD，要想取到一个理想的扩展单位值，必须考虑到：扩展单位应当尽可能小，避免预留太大的空间，这对SSD尤其关键，因为SSD的空间宝贵而量小;同时扩展单位又必须“够大”从而能够将新增的LD全局条带化到所有底层磁盘上，例如8GB扩展单位用256MB的chunklet和RAID1保护会用到64个chunklet也就是64块物理盘，假如共有480块盘(RAID1保护和256MB chunklet)，那么理想的扩展单位是60GB，假如共有480块盘(RAID1保护和1GB chunklet)，那么理想的“扩展单位”是240GB。小结：CPG应当尽可能使用所有同类型磁盘(FC、NL、SSD)已达到“全局条带化”，当新的磁盘加入时用DO来均衡负载，扩展单位尽可能把它的chunklet 1、2、3... 逐个遍历所有底层磁盘。

报警的设置：TPVV使用率的限制和报警、CPG“扩展单位”的限制和报警、已使用物理盘空间报警、未使用物理盘空间报警。

当达到TPVV使用率的限制时，停止写入并返回SCSI错误。当达到CPG使用率的限制时，结果同前，但是影响更严重，因为所有VV都受影响。当达到所谓“系统级限制”时，所有VV开始“乱写”——随意写入任何CPG。当物理空间耗尽时，没法再写，必须扩盘。

Thin Conversion(精简转化)要求数据迁移的Target 3PAR必须配置有ThP许可，同时所有目标TPVV上打开“零检测”。HP保证至少“50% Get Thin Guarantee”。Thin Persistence(持续精简)其实就是在线实时的空间回收，它要求必须配有Thin Conversion许可，在使用Veritas Storage Foundation、VMWare vSphere、Oracle ASRU和其它类似软件时，同样需要这个软件来回收空间。Thin Copy Reclamation可以在删除快照时回收空间，不管快照空间是来自于Full VV还是TPVV都可以回收，还到CPG里给其它VV再使用，它需要ThP许可。

在Unix和Linux中用dd、在Windows中用sdelete，就可以对已删除的空间写零，零检测把连续的16K“还回去”用于TPVV的再使用，把连续的128MB“还回去”到CPG用于所有VV的再使用，用“compactcpg”就可以把128MB“还回去”到整个系统的大Pool中用于其它的CPG。在3.1.1(3PAR InForm OS版本)里，系统自动运行反碎片例程，per-VV basis，把16K的空间收集起来组成一个连续的128MB。3.1.1之前，回收只作用于TPVV，从3.1.1开始，回收同样作用于快照(read/write)，同样针对每个快照要做出设置打开零检测。

受到VxVM管理的VxFS文件系统通过API的集成，可以在文件系统删除或者收缩时自动回收空间，而不需要运行“写零”的工具。回收由VxVM的“vdisk reclaim”命令触发。这个集成工具包含在Thin Persistence许可中。

Oracle数据库同样需要回收功能：删除表空间或者数据库、收缩表空间、数据重新分布到新盘和老盘、老盘空间释放等等场景。3PAR和Oracle共同开发了Oracle ASM Storage Reclamation Utility，凡是在Oracle Automatic Storage Management环境中删除的数据块都可以回收。ASRU是一个脚本，用一个命令把ASM磁盘“收缩”掉，同时3PAR把连续的16KB零空间释放回阵列，这个在线实时工具同样需要Thin Persistence许可。

OS和文件系统有适合ThP和不适合ThP之分，DB必须设置为autoextend而且不能预写空间，Exchange的邮箱删除或者迁移后，邮箱数据库收缩和回收只能离线操作，除非创建一个新的邮箱数据库删掉老的。

VMware自己有ThP，3PAR也提供了ThP，建议同时使用，这要求管理员必须能够汇总和看懂两个不同来源的报警和限制并关联起来，但其好处是毋庸置疑的。建议使用1-2TB大的虚卷作为datastore。创建虚机时VMDK的创建有几种选项，从3.5开始缺省用Thick Provison Lazy Zeroed，这是适合传统ThP的;但是在追求性能的环境中，VMware建议使用Thick Provision Eage Zeroed，这就不适合传统ThP了，但是对于EZT，Thin Persistence照样可以完美的实现瘦身的功能。vSphere 5.0 + 3.1.1在删除虚机时自动回收空间;vSphere5.0 + 2.3.1 MU2(含以上)同样可以实现，只是需要在vSphere里装上3PAR Management Plug-in for VAAI 2.2;更老版本的vSphere则需要3PAR Management Plug-in for VAAI 1.1。

跨阵列迁移瘦身时，用基于文件的迁移工具，如在Unix/Linux的“resync”，Windows的“Quest”，或者备份恢复的方式，就可以成功瘦身。块级迁移工具如LVM或者SVC则是块-块对拷，可能不能瘦身，除非实卷上有连续的零空间。同个阵列内部的实虚转换是借助Full Copy完成的，但是完成后必须重新映射卷到主机。Peer Motion，源阵列OS版本不低于2.2.4，目标阵列不低于3.1.1，目标阵列必须配置Peer Motion和ThP许可。