经过近乎爆炸性的发展，今天的存储技术无论从架构理念还是技术实现，与几年前相比都大为丰富。然而，与其他“初步繁荣”的领域一样，在花样繁多的理念背后，其实也隐藏着一些不够成熟完善的技术手段。只不过这些不足和缺憾从来不会出现在天花乱坠的“方案建议书”中，只有当用户真正使用之后才会有所体会。
螃蟹不可以生吃
曾有某个大型铁路部门，在系统改扩建时拟对核心业务实现容灾，而恰逢某知名厂商隆重推出首款支持远程数据镜像的中端存储产品。于是两者一拍即合，国内首个基于中端存储设备的实时容灾就此诞生。
在确定方案框架后，用户还曾经谨慎的测试了该存储设备在模拟应用中的性能表现，并依此最终确定了产品配置指标。但是工程进入实施阶段之后，意料之外的问题还是出现了。
首先是数据镜像过程消耗了太多的设备处理能力，而控制器又无法进一步扩展，造成用户应用得到的性能只有测试时的三分之一。然后是镜像机制不完整，该设备不支持异步镜像，因此对远程链路的质量和效率要求非常之高，以至于维护通讯链路的成本大幅度增加，基本抵消了用中端产品替换高端产品所节约的投资。最终的结果可想而知――用户虽然在总体投入上稍微有所节省，但得到的系统性能却大打折扣。
更令用户顿足捶胸的是，仅数月之后，市场上就涌现出一批设计更合理、技术更完善、价格也更低廉的容灾产品。这个刚刚上马还处在试运行阶段的产品立时成了“过时设备”，被无奈的列入到整改清单中。
合理而巧妙的利用新技术诚然是获得最优性价比的重要手段，但上面这个真实的事例告诉我们，尝试新技术的同时也必然会伴随风险。作为直接承担风险责任的最终用户，即便有勇气做第一个吃螃蟹的人，也应该尽量设法搞清楚“螃蟹”的成熟度，尤其是针对存储系统。
孔雀开屏的后面
作为全系统的核心基础，存储系统对整体架构的影响可谓“牵一发而动全身”，因此对存储系统的建设一定要全面考量不可偏颇。
当年虚拟存储方兴未艾的时候，某专业虚拟存储厂商曾经兴致勃勃的召开技术演示会，向若干金融电信业的IT负责人推荐。大屏幕上“带内虚拟”、“带外虚拟”、“自动资源分配”、“透明扩展”、“透明迁移”等诸多概念绚丽起舞，台下却有几位老先生眉头紧蹙。
会议行将结束的时候，一些颇有经验的用户终于发问了。
“我理解，这虚拟存储其实就是把我们现有的存储设备都统一由你的设备来治理，然后主机再统一使用由你的设备提供的资源。对吗？”
“正是。这样您可以……”
“这样你的设备岂不是个很大的单一故障点？我为什么要把所有数据都集中到这个相对脆弱的设备上？”
“我们的设备提供有热备容错功能，而且‘把所有鸡蛋放在一个篮子里’也更方便治理和使用。”
“为了保障系统稳定和安全，我们在前端主机和后端存储设备上的投资非常大，现有你的虚拟存储仅是价值十几万的设备，却嵌入在整个系统的中心，这有点不合适吧？我承认虚拟存储的各种好处，但是相对我系统中现有的‘鸡蛋’，你提供的这个‘篮子’似乎脆弱了点。”
虚拟存储技术本身的是非对错自有公论，但这些用户能够不被新技术华丽的外表迷惑，敏锐的看到潜在问题，这种实事求是的态度确实值得学习。
梨子的滋味需要尝
大型系统中，各种软硬件配合关系繁多，安装调试工作也很复杂。虽然很多设备和软件厂商都会尽量提供一些“兼容性列表”和其他指导性文档，但仍然可能有很小的技术细节跳出来妨碍整体系统正常运行。所以复杂系统的方案确立最好能够以实际测试为基础，而不是依照厂商承诺纸上谈兵。对那些没有同行业应用案例的项目，更是应该“先尝后买”。
不久前，某石油公司的一套集群系统，就因为过于乐观的相信厂商承诺，而陷入实施安装的泥潭。
这个系统原本采用传统的DAS存储方式，用于处理部分勘探数据。由于近来油价高起全球业务量骤增，该系统的工作负载也随之增加，解决后端存储瓶颈成为首要问题。
经过历时一年的调研，用户收集了来自几乎每一个关联厂商的产品介绍和方案建议。打印出来的卷宗堆积如山，其中的内容囊括了硬件存储设备、SAN/NAS架构、虚拟存储、集群文件系统、数据备份……等各个方面。
反复推敲之后，用户最终选定以“SAN+集群文件系统+4层交换”作为整体方案架构，以各领域信誉较高的厂商为产品供给商，并选用其中端产品。粗看起来，似乎这样的方案并无风险，但假如了解到具体的规模之后，恐怕就不会那么轻松了。
按这样的规划，将有至少3套满配置容量的中端存储设备和64台主机，同时接入一个至少128端口的SAN；64台主机访问存储设备的链路没有冗余；集群文件系统将在64台主机间共享所有存储空间；多台4层交换将联合工作，在64台主机间均衡负载。这其中很多方面都可称“规模庞大”，远远超出了一般技术人员的经验范围。具体到用户选定的产品，更是有很多搭配创了国内首例。如此复杂的工程，其实施难度可想而知。
事实上，该系统的安装调试工作经历了半年时间，最终用户不得不修改最初的方案设计结构，将这个大的SAN一分为三，才勉强让系统上线运行，最初规划的负载均衡和资源共享当然也就无从谈起了。
试想用户当初若能拿出一部分调研时间来搭建测试系统，也许结果会令人满足许多。
量变到质变
系统越大就越复杂，当复杂达到一定程度时，就需要有新的技术手段和机制出现，否则系统将无法工作，这是IT从业者完全理解的浅显道理。只不过这量变到质变的界限到底在哪里，却时常是考验认知和经验的难题。
时下全国都在预备实施“平安工程”，即公安和城管部门在城市各公共场所安放摄像头并实时监控，以提高打击犯罪和维护社会治安的效率。
从技术上看，平安工程所涉及的技术手段似乎与传统安全监控系统并无二至，都是由摄像头、DVR、数据网络、中心服务器等部分组成，只不过前端摄像头和DVR多些、网络分布广些、后端数据量大些。事实上，很多集成商最初提供给用户的方案建议，就是基于传统安防系统的版本，只在设备的配置数量上略做修改而已。殊不知这样的方案与平安工程的实际需求差之十万八千里之遥，根本不可能得以贯彻实施。
传统楼宇或工厂的监控系统，完全采用集中式治理机制。假如哪栋现代化大厦的每一层都有一个监控室，那一定是个天大的笑话。但是平安工程所要求的网络结构恰恰就是分散式的，假如习惯性的用集中模式提出解决方案，不仅在技术手段上会遭遇众多难题，而且从功能效果上也与平安工程的主旨背道而驰。
换句话说，就算集成商亏了血本搭建超级网络，有本事让全市数十万摄像头采集的视频全都汇聚到中心监控室，公安部门利用这个系统进行工作的场景也一定非常滑稽――中心控制室内上万名干警精神抖擞的盯着各自的监视屏幕，一旦发现情况，马上联系距离事发地点最近的派出所。由于派出所反倒无法接收视频信息，发现情况的干警不得不在电话里具体描述当事人的体貌特征。搞不好“万人监控室”会很吵杂，手机彩信还能排上用场。
上述几个存储技术理念与实际情况的冲突，都是为了提醒用户留意：技术理念大多看上去很美，但是否与您的需求吻合，就要靠实践去检验了。
