1.3 软件定义的必要性

正是因为有了上述挑战，无论是数据中心的管理员，还是应用系统的开发人员，或是最终用户，都意识到将数据中心的各个组成部分从硬件中抽象出来、集中协调与管理、统一提供服务的重要性。如图1-3所示，在传统的数据中心中，如果我们需要部署一套业务系统，例如文件及打印服务，就要为该业务划分存储空间，分配运行文件及打印服务的服务器，配置好服务器与存储的网络。

这需要多长时间呢？这可没准。不同的计算中心都有各自的管理流程，大多数情况下都要先向IT管理员提交一个请求，注明需要哪些资源。IT管理员拿到这个请求之后，会在现有的资源列表中寻找适合的服务器、存储、网络资源。假设运气很好，不需要额外采购就能满足文件服务器的要求，最快也需要1～2天的时间。如果碰到现有的资源数量和质量无法满足需求，那就继续等待吧，询价、采购、发货、配置上线……这么折腾下来，不经过十天半个月的等待，怕是根本没办法开始部署业务系统。对于一个文件及打印服务来说，等一下也无可厚非，实在不行可以把数据暂时存储在U盘里，再凑合使用旧的打印服务器。可是如果一家公司的核心业务系统紧急需要资源怎么办？2012年开始在国内炒得火热的双十一促销是各个电商平台的整体较量，对它们来说都是重头戏。可万事开头难，就在2012年11月11日这一天，淘宝和京东的后台系统从飞速变成了“龟速”。京东的CEO刘强东微博回应：紧急采购服务器扩容！先不说业务系统的设计是否支持这样迅速的扩容，单就IT资源的管理角度，如果这样的业务需要等上几天，那双十一大战是必然要落败了。公司高层领导当然可以省却许多繁琐的流程，但是服务器也不可能“飞”到京东的机房来，无论如何都已太慢。

从图1-3还可以看到，如果有6个业务系统，就需要6套服务器，这很合理。在生产环境的服务器上再部署、调试其他业务只会带来更多的麻烦，而且实际上，文件打印这些服务需要的计算能力很弱，数据库系统需要很大的内存和非常好的I/O能力，高性能计算需要强大的CPU。显而易见，为不同的业务采购不同配置的服务器是必需的，而且对于各项性能的要求几乎完全来自于估计，没有人会确切地知道是否需要256GB的内存而不是128GB。因此，IT管理员需要面对的就是千奇百怪的配置表和永远无法清楚描述的性能需求。因此IT管理员在采购硬件的时候自然而然会采取最安全的策略：尽量买最好的。这就出现了上文提到过的问题：服务器的利用率低得惊人。

高端的存储可以较好地实现存储资源池，并且理论上可以同时支持所有的应用。但是把EMC的高端存储用来支持打印服务器，似乎显得太奢侈了。实际情况下，这些业务系统会至少共享2～3种存储设备。每个子系统都使用各自的子网，但是一个网段分给了某项业务，即使并不会被用完，其他系统也不能再用了。

幸好虚拟化技术重新回到了人们的视野当中。在计算机发展的早期，虚拟化技术其实就已经出现了，当时是为了能够充分利用昂贵的计算机。数十年后，虚拟化技术再一次变成人们重点关注的对象，这依然跟提高资源的利用效率有密不可分的关系。而且这次虚拟化技术不仅在计算节点上被广泛应用，相同的概念也被很好地复制到了存储、网络、安全等与计算相关的方方面面。虚拟化的本质是将一种资源或能力以软件的形式从具体的设备中抽象出来，并作为服务提供给用户。当这种思想应用到计算节点，计算本身就是一种资源，被以软件的形式——各种虚拟机从物理机器中抽象出来——按需分配给用户使用。虚拟化思想应用于存储时，数据的保存和读写是一种资源，而对数据的备份、迁移、优化等控制功能是另一种资源，这些资源被各种软件抽象出来，通过编程接口（API）或用户界面提供给用户使用。网络的虚拟化也是这样，数据传输的能力作为一种资源，被网络虚拟化软件划分成互相隔离的虚拟网络，提供如OpenFlow这样的通用接口给用户使用。当主要的基础资源如计算、存储、网络被充分虚拟化之后，数据中心的逻辑结构将如图1-4所示。

资源的可用性是原生的，是买来这些设备时就已经具备的。但是如何发挥其使用效果，却要靠创新的思路和方法。我们可以看到，当服务器虚拟化之后，计算能力就可以真正做到“按需分配”，而不是必须给每种服务配置物理的机器。过去的IT管理员当然也希望能够做到“按需”而不是“按业务”分配，但是没有虚拟化技术，没有人会愿意冒风险把可能互相影响的系统放在同一台服务器上。存储也被虚拟化了。用户不用再关心买了什么磁盘阵列，每个阵列到底能够承载多少业务，因为他们看到的将是一个统一管理的资源池，资源池中的存储按照容量、响应时间、吞吐能力、可靠性等指标被分成了若干个等级。系统管理员可以“按需”从各个资源池中分配和回收资源。虚拟的网络可以“按需”增减和配置，而不需要动手配置网络设备和连线。能做到这一步，至少就能够解决以下问题：

●资源的利用效率低下，不能充分利用硬件的能力。

●资源的分配缺乏弹性，不能根据运行情况调整投入。

●在提供基础设施服务时，必须考虑不同硬件的性能。

●需要改变配置时，不得不重新连线和做硬件配置的调整。

需要特别注意的是，在虚拟化这一概念中，利用软件来抽象可用的资源这一点尤为重要，因为这样才能实现资源与具体硬件的分离（Decouple），从而使进一步发展数据中心成为可能。这也是“软件定义数据中心”的由来。

当主要的资源都已经虚拟化，“软件定义”还并没有实现，这是因为虚拟化在解决大量现有问题的同时，也带来一些新的挑战。

首先，虚拟化让资源得以按需分配和回收，这使得资源的管理更加精细。不仅如此，管理的对象也发生了变化。传统的数据中心资源管理以硬件为核心，所有的系统和流程根据硬件使用的生命周期来制定。当资源虚拟化之后，系统管理员不仅需要管理原有的硬件环境，而且新增加了对虚拟对象的管理。虚拟对象的管理兼有软件和硬件的管理特性。从用户的使用体验来说，虚拟对象更像硬件设备，例如服务器、磁盘、专有的网络等；而从具体的实现形式和收费来说，虚拟对象却是在软件的范畴里。为了适应这种改变，资源管理要能够将虚拟对象与硬件环境甚至更上层的业务结合起来，统一管理。

虚拟化令资源的划分更加细致，不仅带来了管理方式上的挑战，被管理对象的数量也上升了至少一个数量级。原本一台服务器单独作为一个管理单位，现在虚拟机变成了计算的基本管理单位。随着多核技术的发展，如今非常普通的一台物理服务器可以有2个CPU，每个CPU上有8个物理计算核心（Core），每个计算核心借助超线程技术可以运行2个线程，因而也可以被认为是2个虚拟CPU。因此，一台物理服务器上往往可以轻松运行15～30个虚拟机实例。存储的例子更加明显。传统的存储设备为物理机器提供服务，假设每台机器分配2个LUN（逻辑单元号）作为块存储设备，如今虚拟化之后需要分配的LUN也变成原来的几十倍。不仅如此，因为存储虚拟化带来的资源的集中管理，释放了许多原来不能满足的存储需求，因此跨设备的存储资源分配也变成了现实。这使得存储资源的管理对象数量更加庞大了。网络的数量恐怕不用赘述了。想想看为什么大家不能满足于VLAN，而要转向VxLAN。一个很重要的因素是VLAN tag对虚拟网络有数量的限制，4096个网络都已经不够了（详见第4章）。要管理数量巨大的虚拟对象，仅仅依靠一两张电子表格是完全应付不了的，连传统的管理软件也无法满足要求。例如，某知名IT管理软件在导航栏里有一项功能，用列表的方式列出所有服务器的摘要信息。在虚拟化环境中试用时，由于虚拟服务器数量太多，导致浏览器无法响应，不得不“恳请”用户不要轻易使用。

虚拟环境带来的另一个挑战是安全。这里既有新瓶装老酒的经典问题，也有虚拟化特有的安全挑战。应用运行在虚拟机上和运行在物理服务器上都会面临同样的攻击，操作系统和应用程序的漏洞依然需要用传统的方式来解决。好在如果某个应用在虚拟机上崩溃了，不会影响物理服务器上其他应用继续工作。从这点来看，虚拟化确实提高了计算的安全性。虚拟化的一个重要特点是多用户可以共享资源，无论是计算、存储、网络，共享带来的好处显而易见，然而也带来了可能互相影响的安全隐患。例如，在同一台物理服务器上的虚拟机真的完全不会互相影响吗？早期，亚马逊的AWS就出现过某些用户运行计算量非常大的应用，而导致同一台物理机器上的其他虚拟机用户响应缓慢的情况。存储的安全性就更关键了。如果你在一个虚拟存储卷上存放了公司的财务报表，即使你已经想尽办法删除了数据，你还是会担心如果这个卷被分配给一个有能力恢复数据的人，就会存在安全隐患。

可见，仅仅将资源虚拟化，只是解决问题的第一步。对虚拟对象的管理是下一步要完成的任务。如图1-5所示，新的资源管理和安全并不是着眼于物理设备的，而是把重点放在管理虚拟对象上，使虚拟环境能够真正被系统管理员和用户所接受。

当虚拟资源各就各位，管理员动动鼠标就能够安全地分配、访问、回收任何计算、存储、网络资源的时候，数据中心就可以算得上是完全被软件接管了。可是这并不意味着软件定义数据中心已经能够发挥最大的作用。因为资源虽然已经虚拟化，纳入了统一管理的资源池，可以随需调用，但是什么时候需要什么样的资源还是要依靠人来判断，部署一项业务到底需要哪些资源还是停留在技术文档的层面。数据中心的资源确实已经由软件来定义如何发挥作用，但是数据中心的运行流程还没有发生根本改变。以部署MySQL数据库为例，需要2个计算节点、3个LUN和1个虚拟网络。知道了这些还远远不够，在一个安全有保证的虚拟化环境中，管理员要部署这样一个数据库实例需要完成以下流程：

不难发现，除了使用的资源已经被虚拟化，这套流程并没有任何新意。当然，是否有新意并不重要，重要的是好用、能解决问题。看起来这样的流程并不复杂。那让我们再考虑一下，仅仅部署一个MySQL数据库常常不是最终的目标，要提供一个能面向用户的应用，还需要更多的组件加入进来。假设我们需要部署一个移动应用的后台系统，包括一个MySQL数据库、Django框架、日志分析引擎，按照上面的流程，工作量就至少是原来的3倍。如果我们需要为不同的用户部署1000个移动应用的后台系统呢？

回过头来想想，既然资源都已经虚拟化并且置于资源池中，管理员对虚拟资源理应有更大的控制权，那么在部署虚拟机的时候，自然可以在模板中留下一些辅助配置的“后门”。不仅仅是虚拟机，存储和网络虚拟化提供的接口也提供了类似的配置功能。既然可以用“后门”间接控制虚拟资源被分配后的配置，那将整个流程自动化就是顺理成章的事情了。管理员需要做的是经过实验，事先定义一套工作流程，按照流程管理系统的规则将工作流程变成可重复执行的配置文件，在实际应用的时候配置几个简单的参数即可。经过自动改造的MySQL部署流程将变成：

在这个过程中，如果需要部署的流程并不需要特殊的参数，而是可以用预设值工作，甚至可以做到真正的“一键部署”，那么软件定义数据中心就可以显示出强大的优势了。不仅仅资源的利用可以做到按需分配，分配之后如何配置成用户熟悉的服务也将能够自动完成。

如果你需要的是几台虚拟机，现在已经能够轻松做到了；如果你需要的是同时分配虚拟机、存储和网络，现在也能够做到了；如果你还需要把这些资源包装成一个数据库服务，现在也只需要动动手指就能完成。程序员们应该已经非常满足，管理员也完全有理由沾沾自喜了。毕竟，之前要汗流浃背重复劳动几天的工作，现在弹指间就可以全部搞定。可是对于那些要使用成熟应用的终端用户来说，这和以前没有什么区别。例如，等待CRM（Customer Relation Management）系统上线的用户，并不真正在意如何分配资源，如何建立数据库，唯一能让他们感到满意的是能够登录CRM系统，开始使用这个系统管理用户信息。

要解决这个问题，让应用真正能面向用户，可以有几种方法。在这个阶段，数据中心的资源已经不是单纯跟资源管理者有关系了，而是与用户的应用程序产生了交集。相应的，无论我们采用哪一种方法去建立应用程序的运行环境，也都必须视应用本身的特性而定。如表1-1所示，第一种方法是发展了自动部署数据库的流程，将这套流程扩展到部署用户的应用，同样还是利用自动化的流程控制来配置用户程序。第二种是部署一套PaaS（Platform as a Service）的环境，将用户程序运行在PaaS之上。第三种看起来更简单，让用户自己设计自动部署的方法，是否集成到数据中心的管理环境中则视情况而定。

表1-1 运行环境自动部署方法比较

各种方法都有其适用的场景，并不能一概而论，这是数据中心的基础架构面向用户的关键一步。如果说之前的虚拟化、资源管理、安全设置、自动化流程控制都还是数据中心的管理员关心的话题，那部署应用这一步已经实实在在把花了钱、买了这些服务的用户拉进来了。在成功部署了应用之后，软件定义数据中心才算是真正自底向上地建立了起来。

如图1-6所示，软件定义数据中心是一个从硬件到应用的完整框架。用户的需求永远是技术发展的原动力，软件定义数据中心也不例外。我们在上文中提到了数据中心在云与大数据的年代面临的诸多挑战，传统数据中心的计算、存储、网络、安全、管理都已无法应对日益变化的用户需求。在这种四面楚歌的状况下，软件定义计算（或称计算虚拟化）作为一种既成熟又新颖的技术，成为了解决困局的突破口。随之而来的是软件定义存储和网络技术。在资源的虚拟化已经完成之后，虚拟环境中的安全与管理需求变成了第二波创新的主题。在这之后，数据中心的自动化流程控制进一步释放了软件定义技术的潜在威力，让管理员不踏足机房就能够如同指挥千军万马一般调配成千上万的虚拟机配置数据库、文件服务、活动目录等服务，甚至可以更进一步，自动部署成熟的用户程序提供给用户使用。

软件定义数据中心是应用户需求而发展的，但并不是一蹴而就地满足了用户的初始需求。“非不为也，实不能也”。软件定义数据中心是一项庞大的系统工程，基础如果不稳固，仓促地提供服务只会带来严重的后果。云计算服务就是个很好的例子。云计算服务的后端无疑需要强大的软件定义数据中心做支撑。国内有数家学习亚马逊的企业，本着“一手抓学习，一手抓运营”的精神，在技术并不成熟的情况下，“勇敢”地向大家提供云计算服务，但是计算的稳定性、存储的可靠性、网络的可用性都暴露出了许多问题，用户体验实在无法让人满意。

当然，并不是任何一个软件定义数据中心都需要完全如上文所述，搭建从硬件到用户的完整框架，也不是所有可以称为软件定义数据中心的计算环境都具备上文所述的所有功能。一切还是应用说了算。例如，用户可能仅仅需要虚拟桌面服务并不需要复杂的虚拟网络，但是安全和自动控制流程要特别加强；用户需要大规模可扩展的存储做数据分析，那软件定义存储将扮演更重要的角色，计算虚拟化就可以弱化一些。一切以满足用户需求为前提是软件定义数据中心发展的动力，也是目标。