私有云架构

私有云拓扑架构图

2021年10月,我购买了 HPE ProLiant DL360 Gen9服务器 来实现完整的云计算模拟,规划是采用一台二手服务器:

  • 通过 KVM嵌套虚拟化 运行大量的一级KVM虚拟机,一级KVM虚拟机作为运行 OpenStack Atlas 的物理机,部署一个完整的OpenStack集群

    • 物理服务器运行 Cockpit服务器统一管理平台 可以集成 Stratis - Linux存储系统 存储,以及 oVirt Atlas ,所以在第一层虚拟化上,可以不用自己手工部署 KVM Atlas ,而是集成到 oVirt

    • 通过oVirt来管理第一层虚拟机,虚拟机开启嵌套虚拟化,这样可以同时学习oVirt的管理,体验不同于OpenStack的轻量级虚拟化管理平台

      • oVirt支持 Gluster Atlas 管理,可以方便在底层部署 GlusterFS

  • 在一级虚拟机中运行 Kubernetes Atlas 模拟裸机的K8S集群

  • 在OpenStack中部署运行大量二级虚拟机,按需运行,模拟云计算的弹性以及计费和监控

  • OpenStack中的二级虚拟机内部再部署一个 Kubernetes Atlas 集群,模拟云计算之上的K8S集群,结合 HashiCorp 的 Terraform 来实现全链路的自动化部署

  • 附加:在DL360物理服务器上运行一个精简的Docker容器来做日常开发学习

../../_images/real_cloud.png

多层次虚拟化服务器分布

zcloud服务器部署多层虚拟化虚拟机分配

虚拟化层

主机IP

主机名

cpu

内存(G)

磁盘(G)

NUMA

说明

1

192.168.6.23

x-k3s-n-3

4

4

128 SD

0

Jetson Nano 访问HP DL360 Gen9带外管理

1

192.168.6.51

z-o7k-m-1

4

8

0

OpenStack 管控 1

1

192.168.6.52

z-o7k-m-2

4

8

0

OpenStack 管控 2

1

192.168.6.53

z-o7k-m-3

4

8

0

OpenStack 管控 3

1

192.168.6.61

z-o7k-n-1

2

4

1

OpenStack Nova 1

1

192.168.6.62

z-o7k-n-2

2

4

1

OpenStack Nova 2

1

192.168.6.63

z-o7k-n-3

2

4

1

OpenStack Nova 3

1

192.168.6.64

z-o7k-n-4

2

4

1

OpenStack Nova 4

1

192.168.6.65

z-o7k-n-5

2

4

1

OpenStack Nova 5

1

192.168.6.66

z-o7k-n-6

2

4

1

OpenStack Nova 6

1

192.168.6.67

z-o7k-n-7

2

4

1

OpenStack Nova 7

1

192.168.6.68

z-o7k-n-8

2

4

1

OpenStack Nova 8

1

192.168.6.69

z-o7k-n-9

2

4

1

OpenStack Nova 9

1

192.168.6.70

z-o7k-n-10

2

4

1

OpenStack Nova 10

1

192.168.6.101

z-k8s-m-1

2

4

0

K8s 管控 1

1

192.168.6.102

z-k8s-m-2

2

4

0

K8s 管控 2

1

192.168.6.103

z-k8s-m-3

2

4

0

K8s 管控 3

1

192.168.6.111

z-k8s-n-1

2

4

1

K8s node 1

1

192.168.6.112

z-k8s-n-2

2

4

1

K8s node 2

1

192.168.6.113

z-k8s-n-3

2

4

1

K8s node 3

1

192.168.6.114

z-k8s-n-4

2

4

1

K8s node 4

1

192.168.6.115

z-k8s-n-5

2

4

1

K8s node 5

1

192.168.6.121

z-okd-m-1

2

4

1

OKD(OpenShift) 管控 1

1

192.168.6.122

z-okd-m-2

2

4

1

OKD(OpenShift) 管控 2

1

192.168.6.123

z-okd-m-3

2

4

1

OKD(OpenShift) 管控 3

1

192.168.6.131

z-okd-n-1

2

4

1

OKD(OpenShift) node 1

1

192.168.6.132

z-okd-n-2

2

4

1

OKD(OpenShift) node 2

1

192.168.6.133

z-okd-n-3

2

4

1

OKD(OpenShift) node 3

1

192.168.6.134

z-okd-n-4

2

4

1

OKD(OpenShift) node 4

1

192.168.6.135

z-okd-n-5

2

4

1

OKD(OpenShift) node 5

0

192.168.6.199

acloud

4

16

0

Lenovo ThinkPad X220

0

192.168.6.200

zcloud

48

64

512SSD

HP DL360 Gen9

0

192.168.6.200

wpad

WPAD服务

0

192.168.6.200

proxy

Proxy服务

1

192.168.6.201

z-b-store-1

2

4

512HDD

0(0 1)

virtio-blk直接访问HDD(存储备份基础服务)

1

192.168.6.202

z-b-store-2

2

4

512HDD

0(2 3)

virtio-blk直接访问HDD(存储备份基础服务)

1

192.168.6.203

z-b-store-3

2

4

512HDD

0(4 5)

virtio-blk直接访问HDD(存储备份基础服务)

1

192.168.6.204

z-b-data-1

4

16

1024NVMe

0(24 25 26 27)

iommu NVMe(数据基础服务)

1

192.168.6.204

etcd

基础etcd服务

1

192.168.6.205

z-b-data-2

4

16

1024NVMe

0(28 29 30 31)

iommu NVMe(数据基础服务)

1

192.168.6.205

etcd

基础etcd服务

1

192.168.6.206

z-b-data-3

4

16

1024NVMe

0(32 33 34 35)

iommu NVMe(数据基础服务)

1

192.168.6.206

etcd

基础etcd服务

1

192.168.6.211

z-b-cache-1

2

8

0(6 7)

近端访问 z-data(缓存基础服务)

1

192.168.6.212

z-b-cache-2

2

8

0(8 9)

近端访问 z-data(缓存基础服务)

1

192.168.6.213

z-b-cache-3

2

8

0(10 11)

近端访问 z-data(缓存基础服务)

1

192.168.6.221

z-b-mon-1

2

4

基础监控

1

192.168.6.222

z-b-mon-2

2

4

基础监控

1

192.168.6.231

z-numa

4

4

6

0 1

测试功能-numa

1

192.168.6.232

z-iommu

2

4

6

1

测试功能-iommu(fedora35)

1

192.168.6.233

z-vgpu

1

2

6

1

测试功能-vgpu(fedora35)

1

192.168.6.234

z-udev

1

2

6

1

编译(ubuntu20)

1

192.168.6.235

z-kdev

1

2

6

1

内核测试(fedora35)

1

192.168.6.239

z-codeready

2

2

6

OpenShift开发环境CodeReady

1

192.168.6.240

z-devstack

2

2

6

OpenStack开发环境DevStack

1

192.168.6.241

z-centos6

1

2

6

模版

1

192.168.6.242

z-centos7

1

2

6

模版

1

192.168.6.243

z-centos8

1

2

6

模版

1

192.168.6.244

z-fedora35

1

2

6

模版

1

192.168.6.245

z-ubuntu18

1

2

6

模版

1

192.168.6.246

z-ubuntu20

1

2

6

模版(ubuntu 20.04)

1

192.168.6.247

z-ubuntu20-rbd

2

4

7

模版(ubuntu 20.04)Ceph存储

1

192.168.6.249

z-centos9-rbd

2

4

7

模版(CentOS 9 Stream)Ceph存储

1

192.168.6.250

z-centos8-rbd

2

4

7

模版(CentOS 8)Ceph存储

1

192.168.6.251

z-centos7-rbd

2

4

7

模版(CentOS 7)Ceph存储

1

192.168.6.252

z-vdev

2

4

6

1

fedora35(vgpu 8G)

1

192.168.6.253

z-dev

2

4

6

0

fedora35

0

192.168.6.254

dl360-ilo

HP DL360 Gen9带外管理

注解

保留 192.168.6.21 ~ 192.168.6.50 作为DHCP段IP,用于验证PXE以及无线网络段动态IP地址分配

主机命名规则

  • 物理主机: 单字段命名

  • 物理主机集群(树莓派): 主机名分为 3 段,以 - 作为分隔符

    • 第一个字段 表示服务器层次

      • pi 树莓派

    • 第二字段 表示服务器节点身份

      • master 管控服务器

      • worker 工作节点服务器

    • 第三字段 表示节点序号数字

  • 单用途虚拟机: 主机名分为 2 段,以 - 作为分隔符

    • 第一个字段 表示服务器层次(见下文),目前只有 z

    • 第二个字段 表示用途 ,如 dev numa

  • 虚拟集群: 主机名分为 4 段,以 - 作为分隔符

    • 第一个字段 表示服务器层次, z 表示在 HPE ProLiant DL360 Gen9服务器 物理服务器( zcloud )上部署的第一层虚拟化; a 表示 第二层 虚拟化,主要是在OpenStack之上运行虚拟机,模拟大规模 OpenStack Atlas 集群 (你也可以将这个字段理解为数据中心,今后部署多地冗灾体系)

    • 第二字段 表示集群 ,目前主要在第一层虚拟化部署集群:

      • b : base 基础服务

      • o7k : OpenStack (模仿Kubernetes缩略方法,将中间7个字母简写为 7 ,所以 OpenStack 缩写成 o7k)

      • k8s : Kubernetes

      • o7t : OpenShift

    • 第三字段 表示节点身份:

    • 第四字段 表示节点序号数字

网络规划

我所使用的 HPE ProLiant DL360 Gen9服务器 有2个4口网卡:

  • 服务器主板板载 4口 Broadcom BCM5719千兆网卡

  • FlexibleLOM Bay 4口 Intel I350千兆网卡 - 支持 SR-IOV

由于独立的 4口 Intel I350千兆网卡 支持 SR-IOV ,所以我规划:

  • 每个Intel I350 ( igb ) 支持 7个 SR-IOV 的 VF,共计可以实现 32 网卡 ( 4x8 ) ,分配到 Kubernetes AtlasOpenStack Atlas :

    • 2块 Intel I350 ( igb ) 用于 z-k8s 集群(Kubernetes): k8s运行节点(VM) z-k8s-n-1z-k8s-n-4 ,每个node分配4个 sr-iov cni ,其余节点 z-k8s-n-5z-k8s-n-10 则使用常规 virtio-net ; 通过标签区别节点能力 (此外 NVIDIA vGPU 也只分配2个node,以验证k8s调度)

    • 2块 Intel I350 ( igb ) 用于 z-o7k 集群(OpenStack): 同样也分配4个node

绝大多数虚拟机的网络都连接在 br0 上,通过内部交换机实现互联 ( 后续学习 Open vSwitch (OVS) ),以内核虚拟交换机实现高速互联:

  • 所有虚拟机都通过 br0 访问 Ceph Atlas 基础数据层,数据通路走内核,不经过外部交换机

  • 少量外部物理硬件(如 Raspberry Pi Cluster 以及我用笔记本模拟都KVM节点),通过 Cisco 网络 交换机访问 br0 连接的虚拟机,如 Ceph Atlas 虚拟化集群

私有云域名规划

私有云是我在一台 HPE ProLiant DL360 Gen9服务器 物理服务器( zcloud ) 上部署的云计算环境,我将这个环境作为 staging 环境来运行,所以域名设置为 staging.huatai.me

虚拟化的层级部署

数据存储层(data)

zcloud 底层虚拟化上,我采用完全手工方式构建最基础的存储数据的虚拟机:

第一层虚拟化

第一层虚拟化的虚拟机也采用手工方式部署,部署用于构建集群的虚拟机都采用 数据存储层Ceph Atlas RBD ,不使用任何本地磁盘: 虚拟机计算节点可以任意迁移。

第二层虚拟化

Kubernetes私有云

从集群稳定性和扩展性来说,推荐采用 扩展etcd节点高可用集群 部署模式:

  • kubernetes的管控组件和etcd分别部署在不同服务器,单节点故障影响从1/3降低到1/6

  • 运维管理简化,拓扑清晰

  • etcd和apiserver都是管控平面非常消耗资源的组件,通过分离etcd部署提升了管控平面整体性能

但是,我的私有云由于资源限制,只有3台物理服务器,所以我采用了一种混合虚拟化和容器的部署架构:

  • 管控平面服务器(kubernetes master)运行在KVM虚拟机(每个物理服务器上运行一个虚拟机)

    • 共计3台KVM虚拟机,对外提供apiserver服务(直接通过 Libvirt虚拟机管理器 运行KVM虚拟机,简单清晰)

    • 物理网络连接Kubernetes worker节点,管理运行在物理节点上的worker nodes

    • 可以节约服务器占用,同时KVM虚拟机可以平滑迁移

  • etcd服务器运行在物理主机上

    • etcd是整个kubernetes集群的数据存储,不仅需要保障数据安全性,而且要保证读写性能

注解

最初我考虑采用OpenStack来运行Kubernetes管控服务器,但是OpenStack构建和运行复杂,Kubernetes依赖OpenStack则过于沉重,一旦出现OpenStack异常会导致整个Kubernetes不可用。

基础服务部署着重于稳定和简洁,依赖越少越好:并不是所有基础设施都适合云化(OpenStack)或者云原生(Kubernetes),特别是BootStrap的基础服务,使用物理裸机来运行反而更稳定更不容易出错。

  • Kubernetes的worker nodes直接部署在3台物理服务器上

    • 裸物理服务器运行Docker容器,可以充分发挥物理硬件性能

    • Ceph (Ceph Atlas) 直接运行在物理服务器,提供OpenStack对象存储和Kubernetes卷存储,最大化存储性能

    • Gluster (Gluster Atlas)直接运行在物理服务器,提供oVirt(oVirt Atlas)的虚拟化存储以及虚拟机和Kubernetes的NFS文件存储、数据归档

    • 网络直通,最大化网络性能

注解

整个似有网络仅使用 3台物理服务器 。如果你缺少服务器资源,也可以采用KVM虚拟机来实践部署,即采用完全的OpenStack集群(单机或多机都可以),在OpenStack之上运行Kubernetes。

OpenStack私有云

OpenStack和Kubernetes共同部署在3台物理服务器上,底层的基础服务是共享的: