Project Pacific first contact (rpm)

This is the final public update Jihai number of years, would like to talk about their first contact with VMware Pacific products to provide some reference configuration, interested friends can together to simulate shining in their own environment.

First we look at a few examples for demonstration:

This may be the daily operation of many application developers, it has been written with YAML file, create a container application at the same time, provides an entry for easy access to external users. This is not a surprising thing, in addition to the node running the vessel is no longer a bare metal server or virtual machine, but accounted for over ninety percent of the server virtualization market share of VMware vSphere Server (ESXi) it .

Before, I have been naive to the Tanzu and Project Pacific equate with friends from VMware big get - Gordon.Chen (where there should be flowers and applause ) exchange, is gradually began to understand Project Pacific, but also awareness to Tanzu is a great chess, but also let me see the grand vision of VMware. I believe that many "technical home", like me, in understanding a new thing when prefers hands-on, to feel by LAB Project Pacific brings innovation to this epoch-making product.

Below please follow in my footsteps, step by step, build up basic Supervisor cluster, feel it.

 The first step: Prepare at least three ESXi Server, Version 7.0

My environment, all the ESXi host all virtual machines deployed nested models, distribution 8vCPU, 32GB of memory, can be very successful completion of construction of Supervisor cluster.

One thing to note: in previous versions, ESXi will automatically install the system disk formatted into VMFS5, to provide virtual machine is allocated as a local storage use; but when I contacted ESXi7.0 found that this situation has changed, this disc can no longer use as a data storage, be sure to pay attention.

The second step: to complete the installation of vCenter Server Appliance 7.0.

这里也有几点需要注意的地方:

1. 7.0只有VCSA,没有在Windows Server上安装的vCenter Server版本;

2. 7.0不再有外置PSC,以增强型链接模式组成SSO域的这种部署方式,这一点如果部署过6.7的朋友一定不陌生,因为VMware把这个信息明确写在了安装过程的提示中;

3. 至少采用小型SMALL规模部署,建议在资源充足的情况下,以中等MEDIUM规模部署。

第三步:完成NSX Data Center 3.0安装

对于NSX-T3.0来说,没有什么特别需要注意的地方,完成这些基础架构的准备工作后,才能正式开始Supervisor群集的部署。

注:3.0在进行主机传输节点配置NSX的过程中,提供了一个进度条,这是非常友好的一次更新!!!(重要的事情也就说一遍)

此时,不妨通过之前的一篇分享,来看看NSX DC与容器集成的场景中,我们需要做的事情,可以发现两者的准备工作基本相似。

NSX DC能为容器云原生做些什么(1)

第四步:部署至少一台(建议两台)NSX-T的边界传输节点,组成一个边界群集。

第五步:将至少3台ESXi主机组成一个群集,开启DRS和HA功能;当然像NTP服务器同步设置、开启SSH服务这些基本的操作,我就不赘述了。

第六步:完成存储策略的设置。

在Project Pacific的世界中,容器镜像、临时存储等均通过虚拟机存储策略的定义,被放置在对应的数据存储中,如VMware vSAN超融合数据存储或者其他NFS、IPSAN这样的共享存储。

在我的环境中,我使用了一台CentOS操作系统的虚拟机部署了NFS服务器角色,提供至少500GB的存储空间给ESXi服务器使用,用于包括容器镜像、临时磁盘等和常规虚拟机在内的所有对象。

比如S5-NFS-01,我首先为他定义并分配了一个“WCP-CLuster-01-TAG”的标记,再创建一个WCP-Storage-Policy虚拟机存储策略,允许将相关的对象存储到包含这个标记的数据存储之上。

第七步:规划并实施网络。

在我的环境中,我通过软路由器规划了如下网络:

  • 172.16.18.0/24 用于ESXi服务器、vCenter Server、NSX DC Manager使用的可路由管理网络;

  • 172.16.17.0/24 用于容器API Master虚拟机和群集IP使用的可路由网络;

  • 172.16.19.0/24 南北向可路由网络,Tier0 SR上联地址为172.16.19.253/24

  • 172.16.0.0/21 用于容器内部网络使用的不可路由网络,在满足容器应用东西向可达的需求下,采用封闭网络,避免被外部直接访问,满足业务安全性的考量;

  • 10.96.0.0/24 用于容器服务使用的不可路由网络,理由同上;

  • 172.16.8.0/24 用于容器入口,提供外部访问应用的可路由网络,以负载均衡器VIP的形式存在;

  • 172.16.9.0/24 用于容器出口,以源网络地址转换的方式实现内部网络访问外部,如下载镜像等。

     

因此,整体的网络拓扑如上所示,在运行Supervisor群集创建向导的时候,各位可以看到这张拓扑图展现的整体网络结构。

第八步:通过DCLI方式,在vCenter中添加NSX-T的管理员账号,用于API通信

# dcli +i +show-unreleased-apis

# nsxd principalidentity create --username admin --password VMware1!VMware1!

第九步:一切就绪,开始运行Supervisor群集构建向导。

  • 通过vCenter,启用工作负载管理;

     

  • 选择兼容的群集,如WCP Cluster 01群集;

 

  • 根据实际需要,选择部署规模;

  • 定义API Master虚拟机(合计三台组成一个群集)的网络规划;

  • 选择Edge群集,所有的Tier1逻辑路由器均会自动连接到该Edge群集承载的Tier0逻辑路由器;

  • 定义Pod网络,内部网络,不需要被路由;

  • 定义输入Ingress CIDR,作为负载均衡器的VIP地址,需要被路由,作为容器入口;

  • 定义输出Egress CIDR,作为SNAT的地址,需要被路由,作为容器网络访问包括Internet在内的外部网络的入口;

  • 根据虚拟机存储策略的定义,指定各类存储路径;

     

  • 确认无误,开始WCP群集的自动创建。

  • 创建时间约1小时,期间可以看到vCenter自动下载并部署OVF,以及在NSX-T Manager上看到一系列逻辑组件的创建。

注:可能会出现一些错误,属于正常现象,耐心等待即可

  • 等待群集创建完成,期间必须满足IP地址的正常连通性。

对于Project Pacific来说,最小的管理单元被称为命名空间Namespace;

回想,在之前的服务器虚拟化运维场景中,管理员是通过VMX配置文件,为虚拟机分配硬件资源;也可以创建一个资源池,为某一个应用、租户分配包括CPU、内存在内的资源。

在Project Pacific的世界里,基础架构管理员也像对待虚拟机那样,为Namespace分配资源,比如最多可以使用多少内存、存储,可以创建多少POD等。

因此,在这种架构下,基础架构管理员或者IT运维人员,更关注于平台的性能、高可用性、可恢复性等方面;而开发人员更关注于代码、测试等。双方都在同一个平台,用自己最熟悉的方式共同助力业务的快速上线和稳定运行,是一个理想的协同工作模式。

当然,这仅仅只是我刚刚接触Project Pacific的一点感悟;其实除了Supervisor群集,Pacific的精髓是Guest群集,最近一段时间,我也在努力地学习和摸索中;上述的分享,只是告诉大家想要部署一个Supervisor群集需要执行哪些步骤。

对于一名有强迫症的工程师来说,看到上面的演示环境,是有一种成就感的。在未来的庚子年,我计划推出一些像Cloud Foundation、NSX Advance LoadBalancer(AVI)的分享;同时Project Pacific也会不定期分享一些阶段性的成果。

最后,也祝各位技术爱好者在即将到来的新年里,万事如意

发布了3 篇原创文章 · 获赞 20 · 访问量 4万+

Guess you like

Origin blog.csdn.net/z136370204/article/details/104108016