硬件重构和软件定义：以灵活降低成本
2014-01-27 10:47阅读：
最近拜读 @狒哥，@盘骏-Lucifer 等专家的大作《数据中心 2013：硬件重构
&
软件定义》，内容全面、分析深刻，令人受益匪浅。特别是与平时工作所见所思结合起来，对有些观点和分析产生强烈共鸣，也从其中一个小的角度谈谈自己的理解。
1. “应用竖井”和“资源池”架构
作者在第一章中“透明性、层次化与可见性”节中，有如下的描述并附图：
简单地说,从构建者的角度出发,以 Google、百度、Facebook
为代表的互联网企
业与传统企业级厂商的区别在于,对待透明性和层次化的看法不同。前者反对透明性和层次化,强调(下层)可见,认为所谓的“竖井式”(silos)应用架构没什么不好...后者的观点则几乎相反。
我也有类似的感觉：在这一问题上存在似
乎截然不同的两种观点。但作者并没有继续展开下去，分析为什么会如此以及对未来的走势。应该说，作为数据中心基础设施和架构，本质上都是为应用服务的，都要满足应用对于底层资源的需求。但为什么大型互联网公司和传统企业会有不同做法呢？我觉得主要有以下原因：
（1）单一应用的规模大小不同。互联网应用的大规模集群系统，动辄数千甚至更多数量的服务器，使得每个“竖井”中实际上有一个自用的足够大的“资源池”；
（2）对应用的了解程度不同。互联网公司对每一类应用的运行特征、资源需求模式等都有更深入的了解，因此针对这些应用需求“量身定制”服务器、网络或存储，乃至机柜和数据中心，更有利于提高效率、降低成本。这也是为什么定制化、ODM在互联网方兴未艾的最根本原因。
（3）软硬件协同优化能力不同。互联网公司自己开发软件，使得他们能够在软件设计之初，就针对不同的硬件技术（例如，SSD）开展针对性的优化，因此与之匹配的硬件能够更有效的发挥应用系统的效率。
因此，互联网公司更愿意从应用出发去有针对性地优化基础架构，不仅包括OS、服务器、网络等，甚至还包括数据中心的Facility；而反观传统企业，单一系统规模小，对应用模型不清楚，所以无法很好适配单一需求，只好寄希望通过一个“资源池”内的动态分配来满足不同业务的需求。这两种不同做法，我相信在未来很长一段时间都会并行存在。
数据中心基础设施和系统架构是为上层应用服务的，以上两种观点及其背后的原因非常重要，无疑是不同企业在硬件重构或软件定义等方面发力不同的关键因素。
2. 互联网企业的硬件重构
那为什么互联网企业也开始做类似于RSA这种“硬件重构”呢？确实是因为“硬件资源池化是互联网企业与传统企业市场的共识”吗？对此我表示部分赞同。硬件重构和软件定义，是从不同角度使得底层资源的提供更加“灵活”，这是其根本目的，而“池化”仅仅是一个表象。
软件定义的灵活毋庸多言，硬件重构如何体现灵活，在2013年OCP
Summit大会上，Facebook VP、OCP主席Frank
Frankovsky的发言很有说服力：“如今硬件设计中的最大挑战，是试图预测软件的发展方向。软件可能变得非常快，遗憾的是，在物理环境中我们无法只敲击几下键盘就更改硬件。我们不得不计划材料、做设计、使用工具、带动制造和供应链的运作。因此在软件和硬件配置的变化速度之间，存在着严重的不匹配性。”
，因此，“We want to better match how the software is going to exercise
the hardware. We want to dis-aggregate the hardware components so
you can better take advantage of each
component.”。
个人觉得，类似于RSA这种硬件重构，与小型机的“硬分区”或者“硬件虚拟化”相比，即使在某些场景中使用的效果类似，但出发点和目标有本质的不同。前者强调硬件更灵活的适应某一类软件，后者强调用“硬件+软件（虚拟化或Firmware）”去同时承载不同软件。或者按照文中的术语，后者实际属于软件定义。顺便说一下，RSA架构的最小粒度仍然只能到compute
node的级别，原文中的“CPU池”似乎有误，倒是OCP的“Group Hug”
主板设计方案，有希望实现CPU的灵活配置。
3. 硬件重构和软件定义殊途同归
作者开篇的几段话，显然是经过深思熟虑的，明确点出了硬件重构与软件定义的共同诉求——以灵活降低成本：
硬件重构与软件定义,如同互联网企业和传统企业市场,涵盖范围不同但又相互交
叉。双方都至少有一个共同诉求,即解决规模不断扩张,业务快速变化的挑战,同时还 要有效控制成本。硬件重构与软件定义的应对之道,都是先
IT 资源池化,然后自动化, 以提高利用率和灵活性(弹性),满足规模和变化的要求,同时降低 CAPEX(Capital
Expenditure,资本性支出)和 OPEX(Operating
Expense,运营成本)。
我也完全同意文中“灵活性和效率有时相互制约”这个观点。实际上，作者在文中就先后说到了两种降低效率或增加成本的情况：
（1）随着应用的多样化,不可能有一个通用系统能够适宜各种场景,即“One size doesn't fit
all”……为特定的应用提供优化的系统，增加了基础设施的复杂性。
（2）如果将整个数据中心，或者仅仅一个机架，作为一个整体来看待，上面的层次化设计就形成了过多的冗余，增加了不必要的成本，反而降低了效率。
应该说，之所以出现这两种情况，就是因为前面所说的互联网企业和传统企业的应用特征不同，因此不同架构对于应用效率的影响也不同。无论硬件重构或是软件定义，都可以提升系统架构的灵活性，但效率问题必须用不同的方法解决。
举个例子来说，有人会觉得，有了基于虚拟化的资源动态分配的“资源池”后，就没有必要根据不同应用的资源需求来采购不同CPU、内存或硬盘等配置的物理服务器了，甚至不用花功夫去研究应用的资源需求特征，反正要多少都可以从“池”中动态分配。这种“看上去很美”的做法实际上可能会严重影响整个系统的效率和成本：
（1）这个“池”不是真的如水池般灵活，每台物理服务器节点都是一个不得不面对的边界，怎么保证这台物理服务器中的资源就恰好被正好分配完呢？
（2）怎么知道每个不同的应用，分配多少CPU、内存、硬盘和网络等资源就合适呢？
成功是没有捷径的。互联网企业用服务器虚拟化的不多，而是在前期规划阶段，对于应用特征分析、容量规划、服务器定制方面做了大量优化工作；传统企业在规划阶段做得少，就必须在“资源池”的运行维护阶段做大量优化工作，例如真正做到资源利用率的监控、资源能够灵活的分配和回收，以及根据前期实际运行情况，为后续资源池的物理服务器的配置调整等提供建议。V公司等只是提供了虚拟化软件和工具，具体的运维和优化工作必须由企业自己来做。
一旦资源池的运行有了反馈，针对特定应用的”烟囱”（虚拟机和配套资源的配置）和整个资源的“池化”被很好的结合起来，才能逐渐形成一个真正高效、灵活的资源池，这方面Amazon
EC2的不同虚拟机规格和物理服务器配置就是一个很好的例子。
====
最后再总结一下：应用的多样性决定了基础架构One size doesn't
fit
all，企业应针对自己的应用特征选择适合的技术架构，并通过硬件重构或软件定义等方法来提高灵活性，实现提高效率、降低成本的目标。
