真的是浅见，以后随着认识的加深，可能会更新该文。
SDDC概述
人家聊SDN、SDS等，VMware干脆跟大家聊SDDC(Software-Defined Data Center)，即软件定义数据中心。
SDDC是VMware大约三年前提出的概念，认为是云计算的终极形态，并提出数据中心可以通过三个步骤来实现软件
定义，这三个步骤分别为Abstract、Pool、Automate，即首先将物理资源进行抽象，然后将抽象后的逻辑资源池化，
最后将资源池按需自动化部署、编排。
那为什么要软件来定义数据中心捏？都知道吧，软件相比硬件更具有灵活性，并且是用户主要的交互界面，比如韦哥
我现在直接在浏览器编辑框里码字，我只感觉我在跟软件打交道，我只在乎软件好不好用，而往往不在乎硬件如何处
理并显示到屏幕上这些问题。速度慢？怪谁啊，买不起配置高的本本，穷倒霉呗。因此，软件定义意味着我们可以通
过对软件的操作来实现资源的隔离、划分等，而很少需要去碰底下的物理资源，省时省力赚更多￥。
那我就想了，假如我现在面对一个全新的数据中心，我该如何去进行软件定义，把这些物理的逻辑的资源都管理得服
服帖帖捏？Google的那些牛(人)就曾写过一本书《The
datacenter as a computer》，意思是需要一个数据中心的操作
系统，韦哥我去年在公司也曾提出个这个概念，但因各种(不能告诉你的)原因无力推行。后来又继续对这个问题进行
了一些思考，可能不一定考虑得很周到，但毕竟是韦哥自己琢磨出来的，并把这些玩意都还分了层，主要有四层，你
看看，如下图所示：
接下来我们从下往上逐层分析一下：
1. 物理基础设施
物理资源包括CPU、内存、网卡、硬盘、交换机、路由器、服务器、机架等。
对于一个数据中心的物理连线，我觉得需要在购买物理资源前就已经规划好，考虑好可扩展性等，具体怎么做这里就
不展开了，韦哥也没有这个经验。因此，如果要进行物理集群的扩展，找一个熟悉机房环境的人，按着连线规划图就
可以把服务器进行正确的连接。连接之后，就极少需要人工干预了，因此就要涉及到一个服务器检测系统，一个资源
管理系统，一个服务器配置管理系统。
首先我们要收集这些物理信息，比如某台服务器位于哪个机架，每块网卡分别连到哪台交换机，服务器的CPU型号，
内存大小，内置硬盘个数及大小等。其中有些信息如位于哪个机架需要在连接服务器后或之前按规划的接法手动录
入，其它一些信息如CPU型号等，通过远程管理卡(现在的服务器一般都带有进行带外管理的管理卡)的自动发现功
能，只要服务器连接好通上电，就会被检测系统检测到并收集其信息，然后发送给具备一定智能的资源管理系统，资
源管理系统具有这些物理信息后，生成或更新整个数据中心的物理拓扑图，管理员通过拓扑图可对数据中心的物理部
署情况一目了然。资源管理系统如果发现新增加的服务器是接到OpenStack集群所在的VLAN中，并根据其它一些信
息判断该服务器的角色，即是要作为存储节点还是计算节点，如cinder-volume还是nova-compute，然后将消息发送
给配置管理系统，驱动配置管理系统去进行服务器的自动化安装配置该类型的节点，安装完毕自动加入到集群中。
2. 虚拟化层
包括对CPU、内存、网卡、存储的虚拟化，是物理资源抽象成逻辑资源并得以池化的基础。CPU虚拟化技术例
如VT-x(Intel)、AMD-V(AMD)，内存虚拟化技术如影子页表以及后来的EPT(Intel)和NPT(AMD)，网卡虚拟化技术
如SR-IOV和VMDQ等，存储虚拟化技术如VT-d和AMD
IOMMU，具体可参考韦哥之前翻译的白皮书。这些虚拟化技术
包括硬件辅助的和软件实现的，而这些技术的使用整合在一起就是一个Hypervisor，例如KVM、Xen、ESXi，Hyper-V、
VirtualBox等。有了以上这些东西以后，就做到了资源的虚拟化，也算是实现了计算的软件定义，还需要一些
策略设计和方案来实现软件定义网络、软件定义存储、软件定义安全、软件定义高可用性等。其中比较有名的软件定
义网络实现有OpenStack的neutron、VMware的NSX，软件定义存储有OpenStack的cinder和swift、VMware的VSAN等。
在第一层自动化配置后，一般这个虚拟化层和第三层资源管理平台就完成了部署，随后第三层的资源管理平台便可对其
虚拟化后的资源进行管理调度。
3. 资源管理平台
第三层的资源管理是利用已有的各种不同虚拟化管理平台进行管理，如用vCenter进行vSphere集群的管理， 用
OpenStack Horizon进行OpenStack集群的管理，用XenCenter进行XenServer集群的管理等等。在上面的图中，
DCOS(Datacenter operating system)的范围涵盖了物理层和虚拟化层，功能主要是对物理资源的管理划分和自动
扩展并进行虚拟化，第三层则根据不同的虚拟化平台技术对外暴露不同的服务接口，即这些物理的逻辑的资源在
第三层就开始分化了，比如调用OpenStack的API对应到的是OpenStack集群，调用vSphere API对应到的是vSphere
集群，两个集群之间没有任何关系。如果把DCOS的范围扩展到第三层，则由DCOS暴露出统一的API，应用服务层
看到的是统一的API，而不知道底下到底是OpenStack还是vSphere的集群。这个统一的API层类似于libvirt的API，
OpenStack和vSphere的API就像是libvirt的各种driver。
4. 访问接口层
取决于DCOS的实现，由DCOS暴露出统一的API，或者不同的虚拟化平台都对外提供了服务API，如vSphere API，
OpenStack API， XenAPI等，应用服务或云平台客户可以通过这些API管理自己的虚拟资源，如开关虚拟机等。
PS:
在写此文时，看了下Piston的产品CloudOS，他们可真是早把韦哥我的这点想法都实现了，他们的官网上有这么说：
Our vision is to make deploying the services that developers needas simple as downloading an app
to your
smartphone.
CloudBoot is Piston’s hardware provisioning and orchestration framework. CloudBoot takes hyper-converged
servers from bare metal to a highly-available cloud infrastructure in roughly 10 minutes. Using a single
configuration
policy, CloudBoot enables auto-discovery and configuration of the servers, profiling of the hardware,
and booting of
Iocane Linux. When the need arises to add more capacity to the cloud, scaling out is simple:
attach servers to the network,
and CloudBoot automatically adds them to the cloud with zero downtime
or impact to running services
or workloads.