我们先来探讨一个问题吧：就绪一个私有云环境，需要多久的时间？这个问题，其实非常的宽泛，我们不妨就以VMware的产品来举例。
- 虚拟化几乎是所有企业IT的选择，而vSphere在X86市场的占比决定了私有云环境缺少不了服务器虚拟化的一席之地；
- 传统集中式存储的弊端已经成为阻碍业务快速上线的瓶颈，超融合技术越来越被用户所接受，VMware VSAN作为近年来Gartner魔力象限的领导者，是市场占有率第一的超融合解决方案；
- 随着国家出台网络安全相关的法律法规，NSX DataCenter因为可以提供东西向的细颗粒度防护，在护网行动之后，NSX相关的项目也在逐步增加。
为了更好地进行对比，我们就以就绪vSphere（ESXi和vCenter）、NSX DataCenter和vSAN作为私有云的基础架构进行分析与对比。无论是采用VCF还是普通项目实施的方式来落实一整套VMware SDDC的基础架构，都需要经历几个阶段：概念设计、逻辑设计和物理设计
其中，真正能以详细配置说明书形式提供工程师项目实施的，当属“物理设计”，这其中包括了诸如ESXi服务器的网络地址、群集配置、功能开启等细枝末节的设定。拿一个4节点基础架构服务器来举例，“物理设计”中一定包括了如下部分：
1. ESXi服务器的安装与网络基本配置；
2. vCenter服务器的安装与部署，以及数据中心、群集、功能、虚拟交换机的配置；
3. VSAN群集的配置，包括磁盘组、虚拟机存储策略等；
4. NSX DataCenter管理、控制平面的安装与部署.....
所有这些工作，需要工程师对VMware产品的安装、部署与配置比较了解，也至少需要2个工作日的时间（这是没有任何排障出现的情况），才能让私有云的基础架构基本就绪。
那如果采用VCF呢？可能这一切就只需要鼠标的几次点击罢了，在2-3个小时内，就能完成上述4节点私有云环境基础架构的就绪，这一切是不是来得太快了？
下面就用一个实际的嵌套环境LAB向各位演示什么叫VCF的一键就绪：
这其中涉及三种不同的方面：
第一，物理网络提前就绪，包括管理网络、vSAN网络、迁移网络以及承载VMware NSX逻辑网络的Underlay网络。
第二，ESXi服务器提前就绪，包括操作系统的安装、初始化和其它一些预配置。
第三，除Cloud Builder以外的其他组件，包括vCenter、NSX Manager等均自动部署并完成集成操作。
我们来看看具体是如何实现的。
ESXi服务器就绪准备：
完成ESXi服务器操作系统的安装；
完成ESXi服务器操作系统初始化配置，包括网络地址、域名解析等；
确保ESXi服务器的网络可达、DNS解析正确；
访问ESXi WEB控制台；
设置正确的NTP服务器，并设置为开机自动启动，随后手动开启NTP同步；
设置SSH服务开机自动启动，随后手动开启SSH服务；
为ESXi服务器添加域名；
在管理-安装和用户-身份验证页面，将ESXi主机加入域，成为成员服务器；
确认域成员身份；
同时验证DNS解析是否正确。
Cloud Builder服务器(虚拟机)完成部署：
以OVF方式部署Cloud Builder虚拟机；
该虚拟机角色将完成包括vCenter、NSX Manager、NSX Controllers等其它服务器的安装与部署。
为虚拟机定义显示名称等常规参数；
对于自建不采用VxRail的场景，选择vcf部署模式，反之选择vcf-vxrail；定义包括默认管理员admin在内的密码和网络配置；
确认各项参数无误，开始OVF模板的部署。
将“物理设计”转换成“Cloud Builder模板”：
VCF的精髓之一在于Cloud Builder将根据模板的定义，自动完成一系列组件的安装、部署与配置，下面我罗列几个点，如：
- 外置两台Platform Service Controller的部署（当前版本依旧采用vSphere6.7u3，尚未采用vSphere7.0，因此依旧保留增强型链接模式部署模型）；
- 一台vCenter服务器，以增强型链接模式加入到SSO域，并完成数据中心、群集、主机添加等一系列系统配置；
- 一台NSX for vSphere Manager服务器，与vCenter实现集成，并完成主机准备、VXLAN就绪、三台NSX Controllers虚拟机、传输区域等一系列系统配置；
- 一台SDDC Manager服务器，集中管理所有的这些“管理工作域”组件，包括ESXi、vCenter、NSX等；
- 三台vRealize Log Insight服务器，并自动组成群集，提供对vCenter、ESXi、NSX等组件日志的集中收集和智能处理，提供管理员可交互式稽查。
管理员需要将普通的物理设计，转换成Cloud Builder能够识别的方式（模板）；那如何来实现呢？等待Cloud Builder被正确以OVF方式部署，并开机正常运行；
访问VCF Cloud Builder界面，默认的用户名为admin；
严格按照checklist，检查VCF的物理环境等是否已经就绪；
下载EXCEL版本的配置文件模板。
下面将开始模板的填写工作，模板由6个Sheet组成，最后一个Sheet用于vSAN延展群集使用；因此管理员需要仔细填写前5个Sheet。
不同颜色背景代表不同的含义：
黄色格表示可以修改，
如果修改合规显示绿色，如果修改不合规会显示红色；
灰色和蓝色部分不可以自行修改。
比如将物理设计定义的服务器网络地址、主机名等以合规模板的格式进行填写，这个时间根据规模的不同，耗时会有所增减；在我的LAB环境中，这个阶段大约10分钟。
Cloud Builder根据模板定义完成各组件的自动化部署，实现一键式就绪：
回到Cloud Builder Web界面，上传并验证该配置文件；
等待所有验证的清单全部通过；
对于可能出现的Fail失败错误情况，根据提示修改EXCEL配置，如忘记添加了ESXi服务器许可；
修正错误后，继续验证；
如果没有错误或者手动确认忽略告警，执行下一步的自动安装部署操作；
执行Bring-up自动部署第一个管理工作域的步骤；
系统将根据EXCEL的配置，自动完成一台VCSA、两台PSC、一台NSXMGR、三台NSXCTRL、三台vRLI并组建群集、一台SDDCMGR的安装及集成工作，实现开箱即用的就绪私有云平台；
在后端可以看到，ESXi主机上开始部署相关的组件；
在vCenter显示完成部署后，访问vCenter，在外部PSC正确验证身份的情况下，可以看到整个管理工作域的架构和依次部署的其他组件；
由于Cloud Builder中，NSX纳管的主机节点，VTEP IP地址默认都是DHCP获取，在DHCP没有正确被配置的情况下（大部分场景均不采用DHCP方式分配VTEP IP地址），会出现错误；
访问vCenter控制台，进入NSX的网络与安全配置界面；重新配置VXLAN，创建一个IP地址池，并选择IP地址池分配的方式；
对于其他可能出现的错误，查看日志后，手动执行修复，并在Cloud Builder上执行retry操作；
等待VCF组件被正确部署，状态均为Success；
此时访问VCF的SDDC Manager，可以看到创建的管理工作域所有的运行状态；
在vCenter上也可以看到所有的组件均已经被正确创建并稳定运行。
至此，一个就绪的私有云基础架构（包括计算、网络和存储）已经就绪，我们将这个环境，叫做“管理工作域”，全部的就绪时间在3.5小时，助力业务的快速上线。有人会问，VCF一定要采用VMware VSAN么？能不能用外置存储代替呢？关于这类问题，我也做几个总结：
1. 只有通过Cloud Builder自动部署的，才能叫VCF，手动完成vSphere、VSAN和NSX的集成部署，不能算做VCF；
2. VCF至少需要包括vSphere、VSAN和NSX，但是也支持外置数据存储；
3. VCF至少需要4台服务器组成一个工作域，最多可纳管一个管理工作域和其它十四个工作域；工作域和群集并非一个概念，同一个工作域中可以有多个vSphere群集。
可以看到，在VMware Cloud Foundation的世界中，工程师的价值体现在规划、设计、局部的实施（模板）和排障；其中更为重要的是规划与设计，我相信这是未来的一种趋势~
至此，我们已经完成了第一个管理工作域的安装与部署，各位有兴趣的小伙伴，可以利用自己的LAB也来动手做一做（每台ESXi虚拟机分配32GB内存即可），未来我还将继续深入地学习VCF，届时在与各位分享经验与收获。
