这些天以来,关于固态盘/闪存的钱景、争议接连不断,似乎所有人将所有的热情都投入其中。所谓旁观者清,当局者迷,看看ESG怎么看待这一现象。
很多时候,我们做事都是想当然,因为好像就应该这么做,却从来没有去认真考虑过,这样做是否有意义。这些天以来,关于闪存的钱景、争议接连不断,似乎人们将所有的热情都投入其中。但是我却不敢肯定,等一切尘埃落定,结局是否一定会让生活更美好。
诚然,闪存或固态硬盘可以使基础设施的"某一元件"速度更快。究其原因,是因为"这个元件"的辅助组件在机械磁盘上解决了I/O问题,加上闪存/固态硬盘本身就是内存,其存储速度本来就比磁盘快。当然,我并不是说速度更快的产品就不好,而是在特定环境下,它未必能够如人们所愿,达到预期效果。
为什么我们需要这些元件运行更快呢?归根结底,就是我们希望应用运行更快,也就是说,我们真正需要的是,用者(可能是人、服务器、进程等等)能够访问(控制或显示)与正在运行的应用相关的数据。
从这一点来讲,我们最需要关心的利害关系,应该是请求端(用户)与数据之间的联系。而处在这个过程中的其他东西就是基础架构,而基础架构又由大量的元件构成。因此,提高其中一些元件的运行速度可以说是一件好事,但是,除非你能让所有的元件都提速,否则,这个基础架构永远都不可能完美或达到最优化状态。
因而,我的论点就是,在这个细分领域里,闪存/固态硬盘的出现再平常不过,可以算是一个组件的自然而然的升级。但是,对于用户及其数据之间的主要关系-全面提升和自动优化性能(和可用性),闪存/固态硬盘并不能完全与之划等号。这一点可能只是一个小小的缺陷,但是我可以说,这绝不是问题的全部。因此,不应该在合理的商业机遇以外,营造这种虚假的繁荣。
就拿处理器来说吧。更大、更快的处理器就一定能够满足需求吗?不尽然。即使处理器价格走低,我们有能力购买超级大型处理器用在基础架构内的每个元件上,这样就能确保整体基础架构动态优化用户和数据之间的性能/可用性吗?答案是否定的。然而这并不是说处理器不好,需要对其敬而远之,只是问题的关键在于,从一个视角出发来解决所有的系统问题根本就不切实际。很多厂商都宣称,速度更快的处理器和VMware能够让用户摆脱大量元件的束缚,真的如此吗?但是如果/当我们这样做时,就会面临各种之前根本不存在的新难题- 如I/O,以及伴随数据中心变更同时出现的所有运行负担。
如果贵公司拥有超过100TB的文件数据,并且数据量每年以50%以上的速度增长,那么,我们的研究认为,你们平均可以支持一个单关键应用和39个文件服务设备。而你拥有39个文件服务设备的原因如下:A、就是那样,没有常理可言;B、你需要这些来满足性能/负载均衡;C、容量需求使然;D、同A。使用这些数据的这个应用可能与39台服务器相关,也许,是为了支持多个用户。为服务器1添加闪存/固态硬盘或许能使该服务器中的数据运行更快。但是这对其它38台文件服务器以及应用服务器而言,则根本不起作用,也无法通过网络的重新配置来对其进行使用。如果碰巧闪存或固态硬盘中存在数据,那么就会使文件服务器中的数据得到更快的访问速度。
我认为,将闪存添加进文件服务器1/阵列/ 某项新的小发明会生成更多需要完成的负载。因为现在你必须移动并迁移数据和系统来充分利用新的次元件,你每次做出更改的同时,也将面临新的系统问题。很多企业,为了实现容量优化或负载均衡不停地进行数据/系统迁移,而这也是IT操作中永无止境的战术上的梦魇。闪存掩盖了系统中的某一项迁移需求,这样从表面看来,显得风平浪静,好像这种做法非常明智,但是,这也只能维持一段时间而已。事实上,使用闪存可能会得不偿失,所带来的负载可能远多于它所带来的价值。
因此,由于没有人可以真正地优化当前的整体环境,而从这一实践中唯一的收获就是,人们对可能带来问题的次元件进行系统升级(将其添加至每一个文件服务器)。以存储I/O为例,然后相应地手动调整/更改其余的网络和服务器基础架构。
在当今世界,寄希望于系统应用更高性能的次元件,来解决最终问题,显得不切实际也不合理。即使企业能够采取这种举措,在静态环境中手动优化IT环境所带来的附加运营负担,也会导致企业对大批高端人力资源的需求。况且,我们的环境一直处于动态、不断变化、且数据无休止增长的状态,因此,我认为这一方案并不可行。
因此,无论何时何地,我们需要的都是一种能够自动/动态优化目前和未来用户/数据关系连接性能/可用性的方式。唯一可行的方法,是使管理(实现可用性和路由- 以及应用优先性/策略)和性能集中化。我们需要收集所有元件的有关信息并创建更好的控制和缓存系统。中央闪存与实际应用/基础架构智能的结合同内含系统的运行有点类似,也类似于VMware。问题是,即使VMware能够使数据中心成功运行长达一个世纪的时间,它们也只是控制单个元件的傀儡,对于这些元件之间的优化流程控制,则是鞭长莫及。
好了,言尽于此,有关固态盘/闪存的更多想法,请见下回分解。 |