如何应对存储容量危机？

　　在企业数据爆炸式增长的年代，存储容量突然告罄是司空见惯的事。之所以发生这种事，有时是由于没有建立合理的容量监测机制，有时是由于存储容量的使用出现了不可预见的急剧增长造成的。但不管是什么原因，IT部门都有责任尽快提供更多的可用的存储容量。

　　要避免采用临时的应急解决办法，关键是要有一套规范的方法。当遇到存储容量危机时，管理层可能会要求管理人员迅速拿出解决办法，这时，管理人员要保持坚定的立场，调整自己的工作时间表，把全部精力投入到用正确的方式来解决问题的工作中。只有那样，才能避免以后的痛苦不堪。

　　并不是说“正确的方式”所花的时间总是比“错误的方式”多得多。下面是两个实际的容量危机案例，有一些解决问题的适当方式和经验。

　　案例一

　　被塞满的文件服务器

　　星期一上午9点半，某家公司的技术支持热线快被已经抓狂的用户打爆了，原因是用户无法把文档保存到网络上。公司马上派人检查后发现，那台企业文件服务器上的数据卷完全被塞满了。

　　麻烦的是，这台服务器没有任何空闲的磁盘插槽，所以，订购另一块磁盘并当即送来的方法是行不通的；而如果将整台服务器升级，谁也不知道什么时候能完成。但考虑到该公司所有重要的文件共享区都在该数据卷上，所以这个问题必须解决，而且是马上解决。

　　显然，这时应当采取的最简单的步骤是找出不该放在这个卷上的数据，然后将其删除，以赢得宝贵的时间。这类数据有可能是没人会马上需要的一份软件安装光盘或服务包，可这只能释放区区数百兆字节的空间，而这点儿空间一眨眼就会用完。

　　按照以往的经验，解决这个问题的最常见方法是在这台服务器上选择一个庞大的、不常使用的文件共享区，把它迁移到正好有一些存储空间的另一台服务器上——通常是应用服务器。最合适的迁移对象通常是用于营销部或财务部等较小部门的文件共享区，这些部门的用户比较少，但生成的数据很多。由于用户数量少，那么只要应付少数几个员工，重定向他们的驱动器映射即可。

　　当然，这仍是个拙劣的解决办法。不过，幸好还有一个相当容易的步骤：设置DFS（分布式文件系统），那样一旦几星期后新的文件服务器送来，就可以轻松地恢复原状了。

　　如果之前没有使用DFS，这种方法确实能帮上大忙。实际上，DFS可以建立一个虚拟文件共享命名空间（DFS根），里面含有透明的文件共享区映射（DFS链接）。从用户的角度来看，DFS根就像是一个正常的文件共享区，带有正常的文件夹。不过，那些文件夹把链接呈现给实际存储数据的文件共享区。所以，虽然用户可能浏览至example.com etworkdepartmentsmarketing，但实际上被重定向至appserver1marketing$，只是他们没有认识到这点罢了。

　　这对管理员来说很有帮助，因为他们不必通知用户，就很容易更改DFS链接所指的位置。因此，新的文件服务器送来后，当准备将数据重新转移到新服务器时，只要在下班时间转移数据，然后更新DFS链接，让它指向新的共享区。设置DFS还让文件服务器迁移的其余步骤更容易完成，而对用户的干扰极小。

　　案例二：

　　分配过度的SAN

　　又是一个星期一上午9点半（坏事通常都发生在这个时间段），某公司的部门主管和一家软件厂商的工程师正在升级公司业务依赖的一套关键任务应用软件，这套新版本耗用的存储空间比老版本高一倍，使容量净增500GB，而当天下午就需要存储空间，并且之前并没有人提醒要注意这点。

　　两年前，公司购置高端的存储区域网（SAN）时，根本没有想到有一天公司的数据会将8TB的存储空间塞得满满的。最初购买SAN只是为了存储一套新的文档影像系统，但后来又在上面建立了服务器虚拟化环境，并把大量物理服务器迁移到SAN里面。现在，剩下的闲置空间几乎连存储几个快照都不够了，更不用说存储软件升级需要的500GB了。虽然购买新的存储设备已经被列入了预算，但眼下却必须马上解决刚遇到的问题。

　　我们能想到的最佳办法是将一台公用服务器（utility server）的数据迁离SAN，转移到一台有足够DAS（直接连接存储）的旧服务器上，或者干脆把这台旧服务器交给软件厂商，而不是为对方提供SAN空间。但这些办法都不尽如人意。

　　在第一种情况下，需要迁移服务器中的数据，但以后一旦有了可用的SAN空间，还要把其迁回来。第二种情况下，我们面临的问题是：关键任务服务器将构建在过时的硬件上。

　　也许还有另一个办法。最初面对大型集中式存储设备时，人们常常忍不住为创建的头几个卷分配过度的存储空间。毕竟，两年前安装新的文档管理系统时，每一项指标都显示这个系统会“很庞大”，所以为它分配一个2TB大小的卷似乎再简单不过了。

　　不过时至今日，该文档管理系统只用了这个空间中的600GB，剩下1TB多的空间闲置未用。遗憾的是，缩小生产环境的NTFS卷却是风险很大的举动。更糟的是，没有足够的空间来创建一个更换卷，以便把这套应用软件的数据转移到替换卷上，并释放存储空间。

　　还有什么办法吗？如果SAN支持自动精简配置技术，它可以释放现有卷中还没有分配的空间，那样就可以将释放出的空间用于其他用途。

　　当然这可能也极其危险，因为即使试图使用释放的那部分存储空间，SAN其实也会用完存储空间，那麻烦就大了。不过，对一个庞大的、分配过度的卷进行自动精简配置处理，可以灵活地转移存储数据，暂时摆脱困境。只要在自动精简配置后不久添加存储资源，或者把分配过度的卷上的数据迁移到大小合适的卷上，然后停止自动精简配置，这种做法在紧要关头挺管用。

　　通盘考虑

　　显然，要同时避免以上两个问题，最好的办法还是建立合理的容量监测机制，并且能在迫切需要存储资源之前就做好增添存储资源的计划。但再完备的规划也预测不到所有事件。

　　当我们面临存储容量危机时，要花点时间考虑摆在面前的所有办法，而不是立即采用某人的主意。我们也许能够找到这样一种合理的解决办法：既有望带来用户需要的结果，又不至于给自己套上一副永远无法脱身的枷锁。

　　NetApp启动共享IT基础架构巡展

　　本报讯 近日，NetApp公司在北京启动了“迈向共享的IT基础架构”大中华区巡展。在巡展中，NetApp发布了新一代的存储平台、产品和技术，帮助用户顺利实现向灵活高效的共享IT基础架构（云计算的基础）过渡，并使IT成为业务的加速器。目前，越来越多的用户在重新审视他们的IT基础架构，并评估一些替代方案，以应对当前业务增长所带来的新的现实问题。NetApp 认为，企业的当务之急是从基于存储孤岛的基础架构迁移到更加高效灵活的共享IT基础架构，以应对当前迅速变化的业务要求，而此次发布的新产品和技术组合提供了可供用户选择的存储平台，可用于构建他们的共享IT基础架构，使IT更加灵活高效。此次NetApp推出的新产品和技术组合包括：NetApp Data ONTAP 8、FAS/V6200系列、 FAS/V3200 系列、固态硬盘（SSD）、SAS磁盘架以及OnCommand管理软件套件、FlexPod 模块化数据中心解决方案。据悉，此次巡展除北京外，还将在上海、成都、香港、深圳、台北、新竹六个城市举办。