应用的发展推动了IT基础架构的发展，特别是承载着云计算与大数据应用规模化的数据中心的发展。
这些分布式应用有一个共同的特点，那就是它们比以往的应用需要更多的计算、存储和网络资源，而且需要更具灵活性和弹性的部署以及精细化的管理。
为了满足这些近乎苛刻的要求，仅仅增加硬件设备或在原有软件的基础上修修补补已经无济于事了。
与此同时，人们发现那些数据中心的资源（如服务器、磁盘、网络带宽）的平均利用率竟然不到10%。解决办法不是没有，可以将应用迁移，但是应用迁移实施起来困难重重，有些机器明明在99%的时间里是空闲的，却不得不为了那1%的突发性负荷而一直空转着。
如果说服务器只是有些浪费，还勉强能应付需要，那么存储就更让人头疼了。数据产生的速率越来越高，存储设备要么是不够用，要么是数量太多管不过来……
老夫先先整理一下所面临的挑战：
(1)节点（设备）太多
以服务器为例，如果只是把机器堆在机房（库房）里还好，可是试想给10000台机器配置好操作系统、配置好网络连接、登记在管理系统内、划分一部分给某个申请用户使用，或许还需要为该用户配置一部分软件……这看起来是实实在在的劳动密集型任务。想想谷歌公司，经常需要为新应用部署一个数千节点的GFS环境，它是不是需要一支训练有素、数量庞大的IT劳务大军？
(2)设备利用率太低
Mozilla数据中心的数据让人有些担心。据称，Mozilla数据中心服务器CPU的占用率为6%～10%。这也许与应用的类型有关，例如在提供分布式文件系统的机器上，CPU就很空闲，与之对应的是内存和I/O操作很多。如果这是个例，我们完全没有必要担心。但服务器利用率低下恰恰是一个普遍存在的问题。一个造价昂贵的数据中心，再加上数额巨大的电费，遗憾的是最后发现只有不到10%的资源得到了合理利用，剩下超过90%资源被用来制造热量。别忘了，通过空调系统、循环系统散热还需要花一大笔钱。
(3)应用（设备）间迁移太困难
硬件的升级换代还是那么快。在摩尔定律起作用的时代，硬件升级以设备主频提高为主。当主频不再增长之后我们可以预见，性价比更高的异构的硬件解决方案（如FPGA/ASIC）会成为设备升级的主流趋势。对于数据中心来说，每隔一段时间就更新硬件是必须的。困难的不是把服务器下架，交给回收商，而是把新的服务器上架，和以前一样来配置网络和存储，并把原有的应用恢复起来。新的操作系统可能有驱动的问题、网络和存储可能无法正常连接、应用在新环境中不能运行……这时工程师很可能不得不到现场调试，追查问题到底是出在硬件、软件上，还是哪个配置选项没有被选中。
(4)存储需求增长得太快
今年的数据还没有出来，但据IDC的预测，就在今年（2025年），全球数据领域的数据规模将增长至175ZB。即使根本不考虑存储这些数据所需要配备的空闲存储，这也意味着数据中心不得不在一年内增加50%左右的存储容量……
用不了几年，数据中心就会堆满了各种厂家、各种接口的存储设备。管理它们需要不同的管理软件，这些软件还常常互相不兼容。存储设备的更新比服务器更重要，因为所存储的数据可能是我们每个人的银行账号、余额、交易记录。旧的设备不能随便被换掉，新的设备还在每天涌进来。
问题绝不仅仅只有这么几个，但是，我们已经从中得到一些启示：
①软件定义的趋势不可阻挡；
②一切以服务为导向。
so，针对趋势和导向，也正是因为有了上述的挑战，虚拟化技术重新回到了人们的视野当中。
在计算机发展的早期（20世纪60年代），虚拟化技术其实就已经出现了，当时是为了能够充分利用昂贵的大型主机的计算资源。数年后，虚拟化技术再一次变成人们重点关注的对象，依然跟提高资源的利用率有密不可分的关系，而且这次虚拟化技术不仅在计算节点上被广泛应用，相同的概念还被很好地复制到了存储、网络、安全等与计算相关的方方面面。
虚拟化的本质是将一种资源或能力以软件的形式从具体的设备中抽象出来，并作为服务提供给用户。当这种思想应用于计算节点（计算资源），资源将以软件的形式（各种虚拟机从物理机器中抽象出来）按需分配给用户使用。
当虚拟化思想应用于存储时，数据的保存和读写是一种资源，而对数据的备份、迁移、优化等控制功能是另一种资源，这些资源将被各种软件抽象出来，通过API或用户界面提供给用户使用。
网络的虚拟化也是这样，数据传输的能力作为一种资源，被网络虚拟化软件划分成互相隔离的虚拟网络，提供诸如OpenFlow这样的通用接口给用户使用。
当服务器被软件虚拟化之后，计算能力就可以真正做到按需分配，而不是必须给每种服务按业务分配物理的机器。这里需要澄清一点：虚拟化有软件与硬件两大类，硬件虚拟化的复杂度过高、灵活度太差，虽然性能更优，但是市场毫不犹豫地选择了软件虚拟化。另外，硬件虚拟化究其本质是对软件虚拟化功能的固化。
过去的IT管理员当然也希望能够做到按需而不是按业务分配资源，但是没有图1所示的虚拟化隔离技术，没有人会愿意冒风险把可能互相影响的系统放在同一台服务器上。
而在软件虚拟化的场景下，虚拟机可以把在同一台物理设备上部署的多个应用、服务甚至异构的操作系统进行很好的隔离（容器计算技术在隔离上仍旧没有虚拟机技术成熟，但是这一问题的解决只是个时间问题）。
存储也通过软件被虚拟化了。用户不用再去关心买了什么磁盘阵列，每个阵列到底能够承载多少业务，因为他们看到的是一个统一管理的资源池，资源池中的存储按照容量、响应时间、吞吐能力、可靠性等指标被分成了若干个等级。系统管理员可以按需从各个资源池中分配和回收资源。虚拟的网络可以按需增减和配置，而不需要手动去配置网络设备和连线。能做到这一步，就能够解决以下问题。
①资源的利用率低下，不能充分利用硬件的能力。
②资源的分配缺乏弹性，不能根据运行情况调整部署。
③在提供基础设施服务时，必须考虑不同硬件的性能。
④当需要改变配置时，不得不重新连线和调整硬件配置。
需要特别注意的是，在虚拟化这一概念中，利用软件来抽象可用资源这一点尤为重要，因为只有这样才能实现资源与具体的硬件分离。这也是软件定义一切——软件定义数据中心、软件定义网络、软件定义存储这些技术与实践的由来。
主要的资源被虚拟化，这只是实现了软件定义的第一步，这是因为虚拟化在解决大量现有问题的同时，也带来了一些新的挑战。
虚拟化使资源管理的对象发生了变化：
首先，虚拟化使资源管理的对象发生了变化，变得更为复杂。传统的数据中心资源管理以硬件为核心，所有的系统和流程根据硬件的使用生命周期来制订。
当资源虚拟化之后，系统管理员不仅需要管理原有的硬件环境，还要管理虚拟对象，而虚拟对象的管理兼有软件和硬件管理的特性，也就是说系统的复杂性从一层变为两层。从用户的使用体验来说，虚拟对象更像硬件设备，例如服务器、磁盘、网络等；而从具体的实现形式、计费、收费来说，虚拟对象却是在软件的范畴里。为了适应这种改变，资源管理要能够将虚拟对象与硬件环境，甚至与更上层的业务结合起来，进行统一管理。
虚拟化使资源的划分更细致，这不仅带来了管理方式上的挑战，还让被管理对象的数量上升了至少一个数量级。原来一台服务器作为单独一个管理单位，而现在虚拟机变成了计算的基本管理单位。随着多核技术的发展，如今非常普通的一台物理服务器可以有2～4颗CPU，每颗CPU上有8～20个物理计算核心，每个物理计算核心借助超线程技术可以运行2个线程。在云环境中，每个线程等同于1个vCPU（即虚拟CPU），因此，一台物理服务器上往往可以轻松运行15～30个虚拟机实例。事实上，像OpenStack等框架允许以超量分配资源的方式对每一颗CPU按照1:16的方式进行虚拟化，即有24个物理计算核心的一台物理机，可以默认虚拟化成24×16=384个vCPU。可以想象，在这种超量分配的条件下，每台虚拟机能真正使用的底层计算资源是非常有限的，这也是云厂商在上云后可能会赚钱的底层逻辑。
存储的例子更加明显，传统的存储设备为物理机器提供服务。假设每台机器分配2个逻辑单元号(Logic Unit Number，LUN)作为块存储设备，如今在虚拟化之后需要分配的LUN数量也变成了原来的几十倍。不仅如此，因为存储虚拟化带来的资源集中管理释放了许多原来不能满足的存储需求，所以跨设备的存储资源分配也变成了现实，这使得存储资源的管理对象数量更加庞大。
网络因软件虚拟化而生成的数量呢？恐怕不用赘述了。想想为什么大家不能满足于VLAN，而要转向虚拟扩展局域网(Virtual Extensible LAN，VXLAN)吧。一个很重要的因素是VLAN Tag对虚拟网络有数量上的限制，4096个网络都已经不够用了。要管理数量巨大的虚拟对象，仅仅依靠一两张电子表格是完全应付不了的，甚至连传统的管理软件也无法满足要求。例如，某知名IT管理软件在浏览器页面的导航栏中有一项功能：以列表的方式列出所有服务器的摘要信息，该功能在被用于虚拟化环境时，由于虚拟服务器数量过多导致浏览器无法及时响应。
虚拟环境带来的又一个新挑战是安全：
虚拟环境带来的又一个新挑战是安全，这里既有新瓶装老酒的经典问题，也有虚拟化（含容器化，下同）所面临的特有的安全挑战。
应用无论是运行在虚拟机上还是运行在物理服务器上，都会面临同样的攻击，操作系统和应用程序的漏洞依然需要用传统的方式来解决。
好在应用如果在虚拟机上的运行崩溃了，并不会影响物理服务器上其他应用继续工作。从这点来看，虚拟化确实提高了应用的安全性。
虚拟化的一个重要特点是多用户、多租户共享资源。无论是计算、存储、网络，共享带来的好处都是显而易见的，但同时带来了可能互相影响的安全隐患。
例如，在同一台物理服务器上的虚拟机真的完全不会互相影响吗？AWS公有云服务商就遇见过某些用户运行计算量非常大的应用导致同一台物理机器上的其他虚拟机用户响应缓慢的情况。
容器计算则因潜在的安全、隔离隐患让很多企业顿足不前。存储的安全性就更关键了，假如你在一个虚拟存储卷上存储了公司的财务报表（有些条目可能会让你“吃”官司），即使已经想尽办法删除了数据，但你还是会担心并顾虑这个卷被分配给一个有能力恢复删除数据的人的可能性及相关代价。
对虚拟对象进行管理：
由此可见，仅仅将资源虚拟化只是解决问题的第一步，对虚拟对象的管理才是迫切需要完成的任务。
如图2所示，新的资源管理和安全并不只是着眼于物理设备，而是把重点放在管理虚拟对象上，使虚拟环境能够真正被系统管理员和用户所接受。
在这里，虚拟对象与物理实体对象之间的关系可以灵活定义：既可能是一台物理设备上拆分出的多个虚拟设备或服务，也可能是多台物理设备组合并构成一个虚拟的组件。谷歌Spanner中的全球数据中心就是由几个Universe来构成的。
当虚拟资源各就各位，管理员动动鼠标就能够安全分配、访问、回收任何计算、存储、网络资源时，数据中心就可以算得上是完全被软件接管了。
可是，这并不意味着软件定义的基础架构（如数据中心）已经能够发挥最大的作用了，因为资源虽然已经被虚拟化了，被纳入统一管理的资源池，可以随需进行调用，但什么时候需要什么样的资源还是要依靠人来判断，部署一项业务到底需要哪些资源还停留在参考、比对技术文档的层面。数据中心的资源确实已经由软件来定义如何发挥作用了，但是数据中心的运行流程还是没有根本的改变。以部署MySQL数据库为例，假如你需要2个计算节点、3个LUN和1个虚拟网络，知道了这些还远远不够，在一个安全有保证的虚拟化环境中，管理员要部署这样一个数据库实例，还需要完成图3所示的MySQL数据库部署流程。
不难发现，除了使用的资源已经被虚拟化外，这套流程并没有什么新意。仅仅部署一个MySQL数据库当然不是最终的目标，要提供一个能面对用户的应用还需要更多的组件加入进来。
假设我们需要部署一个移动应用的后台系统，其中包括一个MySQL数据库、Django框架和日志分析引擎，按照上面的流程，这个工作量至少是原来的3倍。如果我们需要为数以百计的移动应用部署后台系统，那么工作量之大会导致只有一条路可走——自动化。
既然资源都已经虚拟化并置于资源池中，管理员通过模板对虚拟资源进行标准化配置，进而将整个流程自动化就是顺理成章的事情了。管理员需要做的是经过实验定义出一套工作流程，并按照流程管理系统的规则将工作流程变成可重复执行的配置文件（如模板），在实际应用的时候配置几个简单的参数即可。经过改造（自动化）的MySQL数据库部署流程将变成图4所示自动化的工作流程。
在这个过程中，如果需要部署的流程并不需要特殊的参数，而是可以用预设值工作，甚至是真正的“一键部署”，那么这时软件定义的基础架构就可以显示出强大的优势了：不仅资源的利用可以做到按需分配，而且分配之后也能够自动配置成用户熟悉的服务。
如果你需要的是几台虚拟机，那么现在已经能够轻松做到了；如果你需要的是同时分配虚拟机、存储和网络，那么现在也能够做到了；如果你还需要把这些资源包装成一个数据库服务，那么现在也只需要动动手指就能完成了。
程序员们应该已经非常满足了，管理员也完全有理由沾沾自喜了。毕竟，之前要汗流浃背重复劳动几天的工作现在弹指间就全部搞定了。
可是对于那些要使用成熟应用(SaaS)的终端用户来说，这和以前没有什么区别。例如，等着CRM系统上线的客户并不会真正在意如何分配了资源(IaaS)、如何建立了数据库(PaaS)，唯一能让他们感到满意的是登录进入CRM系统(SaaS)后，就可以开始使用这个系统来管理客户关系。那么，怎么解决这个问题呢？
如何自动部署？
要解决这个问题，让应用真正能面对客户，有3种自动部署应用的方法，见图5。
在这个阶段，数据中心的资源已经不是只跟资源管理者有关系了，而是与用户的应用程序产生了交集。建立应用程序的运行环境，必须视应用本身的特性而定。
(1)第一种方法:
借鉴了自动部署数据库的流程，将其扩展到用户应用的部署，利用自动化的流程控制来配置用户程序。
(2)第二种方法:
是部署一套PaaS环境，将用户程序继承并运行在PaaS环境之上。
(3)第三种方法:
是让用户自己设计自动部署应用的方法，是否集成到数据中心的管理环境中则视情况而定。
每种方法都有其适用的场景，不能一概而论。但应用的自动部署这一步是数据中心基础架构面向用户的不可或缺的一步。如果说之前的虚拟化、资源管理、安全设置、自动化流程控制都是数据中心管理员关心的话题，那么自动部署应用这一步才是真正贴近用户，直接满足用户的业务需求。在成功部署应用之后，软件定义的基础架构（数据中心）才算是真正自下向上完整地建立起来了。
如图6所示，软件定义数据中心是一个从硬件到应用的完整框架。用户的需求永远是技术发展的原动力，软件定义数据中心也不例外。我们在前文中提到了以规模化数据中心为核心的基础架构在云计算与大数据的时代所面临的诸多挑战，传统数据中心的计算、存储、网络、安全、管理都无法应对日益变化的用户需求。在这种状况下，软件定义计算（或称计算虚拟化）作为一种成熟的技术，成为解决困局的突破口。随之而来的是软件定义存储和软件定义网络技术。在资源的虚拟化完成之后，虚拟环境中的安全与管理需求变成了又一个创新主题。在这之后，数据中心的自动化流程控制进一步释放了软件定义技术所蕴含的潜在威力，让管理员能够不踏足机房就能将成千上万的虚拟机配置成数据库、文件服务、活动目录等，甚至可以更进一步，自动部署成熟的用户程序，提供给用户使用。
软件定义数据中心是应用户需求而发展的，但并不是一蹴而就地满足用户初始的需求——“非不为也，实不能也”。软件定义数据中心是一个庞大的系统工程，基础如果不稳固，仓促提供服务会带来严重的后果。云计算服务就是个很好的例子。云计算服务的后端无疑需要强大的软件定义数据中心做支撑。有的“学习”AWS的企业本着“一手抓学习，一手抓运营”的精神，在技术并不成熟的情况下，过度强调运营的重要性，从而仓促提供云计算服务，但是计算的稳定性、存储的可靠性、网络的可用性都暴露出了许多问题，用户体验实在无法让人满意。
当然，并不是任何一个软件定义数据中心都需要完全如前文所述，搭建从硬件到应用的完整框架，也不是被称为软件定义数据中心的计算环境都具备前文所述的所有功能。一切还是应用说了算。例如，用户仅仅需要虚拟桌面服务，并不需要复杂的虚拟网络，那安全和自动控制流程就要进行特别加强；用户需要大规模可扩展的存储做数据分析，那软件定义存储将扮演更重要的角色，计算虚拟化就可以被弱化一些。一切以满足用户需求为前提，这是软件定义一切的发展动力和目标！
（文/Ricky - HPC高性能计算与存储专家、大数据专家、数据库专家及学者）
· END ·
扫一扫
224
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
