openstack架构设计(一)

下图描述了最常见的Openstack集成服务和各服务之间如何交互的逻辑架构。

一. 计算架构

当设计和构建计算结点时，需要考虑处理器，内存、网络、和存储资源等信息。它也是openstack的核心部分。

1. 计算服务器体系加构描述

当设计计算资源沲时，考虑处理器数据，内存数据，网络的需求，每个hypervisor请求的存储。

（1）CPU的选择

• CPU是否支持虚拟化
• 在必要时使用NUMA技术，和使用CPU PINNG绑定某个应用。
• 使用超线程技术加快CPU的处理

（2）hypervisor选择

Openstack compute(nova) 针对不同的等级，支持很多的hypervisors,包括如下：

• KVM
• LXC
• QEMU
• VMware ESX/ESXI
• XEN
• Hyper-V
• Docker

（3）服务器硬件选择

服务器的密集度，比如服务器是几U的，占用多少空间。

资源能力：CPU多少核心，多少内存，多少存储等。

扩展能力：服务器最多能扩展到多少资源（为以后着想）

（4）Openstack允许在compute nodes上过量使用CPU和内存，这是牺牲实例的性能来换取实例的数量。compute服务认使用下列比例：

• CPU allocation ration: 16:1
• RAM allocation ration: 1.5:1

上面的比例意味着：一个物理核心默认可以分配 16个虚拟核心，比如，物理节点有12核心，那么调度器会看到192可用的虚拟核心。常规的定义4个核心，也就是说可以提供48个实例在一个物理节点上。 内存和CPU的分法类似。

所以在特定的使用案例中，必须选择适合自己的CPU和内存分配比例。

（5）实例的存储考量

针对实例的磁盘运行什么存储上面，这也是需要考虑的。提供临时的存储基本有三种方法：

• 不在计算节点上的存储---共享文件系统

     有以下优势：

1. 假如一个计算节点坏掉，实例比较好恢复。
2. 运行在专用的存储系统上，可能操作、维护更简单。
3. 可以和其它存储共享等。

     有以下劣势：

1. 针对在相同存储的实例，其它实例大量使用IO，可能会对本实例有影响。
2. 共享存储中间使用比如网络连接，可能会造成性能延迟。
3. 扩容时可能会影响网络的架构。

• 在计算节点上的存储----共享文件系统

     有以下优势：

1. 当需要使用附加的存储时，可以很方便的扩展外部存储。

    有以下劣势：

1. 对比非共享的存储，运行分布式文件系统可能导致部分数据丢失。
2. 由于在多个主机上，实例还原可能有点小复杂。
3. 使用网络（也可能是FC光纤）会造成性能延迟。
4. 丢失计算节点会降低所有主机的存储有效性。

• 在计算节点上的存储------非共享文件系统

有以下优势：

1. 高I/O的使用，不会影响其它计算结点。
2. 由于是本地直接使用存储，相对于使用共享存储而言性能会有所增加。
3. 别的计算节点坏，不会影响它。

有以下劣势：

1. 假如计算节点挂的在，那么在它上同跑的实例就挂了。
2. 从A节点往B节点迁移实例相对来说较为复杂和困难的。
3. 扩容不太好。

在选择存储时，可以从以下几个方面考虑

• 工作量是什么，就是运行什么应用的意思？
• 应用是否有IOPS的需求（指的特定）？
• 它们是读、写还是随机访问的比较多？
• 针对以后的扩容，预测的会有哪些方面扩容？
• 什么存储是当前企业使用的？它们是否和现在的能集成？
• 如何管理这些存储？

文件系统的选择：

假如想要使用共享存储的在线迁移的话，那么需要配置分布式文件系统：支持如下：

• NFS（default for Linux）
• Ceph
• GlusterFS
• MooseFS
• Lustre

(6) 网络连接

在生产环境中，推荐以下网络配置：

Install or OOB network: 部署软件到Openstack computer nodes使用，建议使用至少1GB的网络。

Internal or Management network: 在Openstack控制节点和计算节点之间通信使用，也可以作计算节点和iscsi 存储节点的iscsi协议之间的通信。建议使用1GB的网卡，且不要和其它网络之间进行路由。 且该接口建议使用HA冗余。

Tenant network: 该网络用于租户的各个实例之间进行通信的，建议至少1GB的网卡且做冗余 。

Storage network: 该网络用于Ceph前端或其它共享存储通信，该网络建议和其它网络之间进行隔离，建议使用10GB的网卡，且做冗余。

外部或者公共网络（可选）：用于和Internel进行通信。

（7）计算节点服务器日志

建议将日志导入到ELK中。拓扑如下：

二. 存储架构

首先明白短暂存储和持久存储的区别：

• 短暂存储---假如部署openstack compute service (nova),默认的用户没有访问任何的持久存储，磁盘分配给VMs是短暂的，意味上假如虚拟机终止的话数据也会丢失。
• 持久存储---不关虚拟机是否是运行状态，那么数据是永久有效的。

1. 对象存储

在openstack中对象存储是通过object storage service (swift)来实现的，用户通过REST API访问二进制对象，假如用户需要归档或者管理大的数据集的话，那么应该提供对象的存储服务。会带来以下好处：

• Openstack可以存储虚拟机的镜是在对象存储系统中，当然也可以存储在文件系统中。
• 可以和Openstack Identity 和 Openstack Dashboard进行集成一起工作。
• 通过异步最终一致性复制可以分布在多个数据中心。

2.  块存储

在openstack中执行块存储的是通过Block Storage service(cinder)来完成的，因为这些卷是持久的，它们可以从A实例分离，然后挂载到别的实例中去。

块存储支持多个形式的设备，比如还支持NFS，GlusterFS等。

3. 基于文件的存储

也支持NFS，CIFS，GlusterFS或HDFS协议。

存储类型的区别：

	Ephemeral storage	Block storage	Object storage	Shared File System storage
Application	Run operating system and scratch space	Add additonal persistent storage to a virtual machine	Store data, including VM images	Add additional persistent storage to a virtual machine
Access through …	A file system	A block device that can be partitioned, formatted, and mounted (such as , /dev/vdc)	The REST API	A Shared File Systems service share (either manila managed or an external one regisdtered in manila) that can be partitioned, formatted and mounted(such as /dev/vdc)
Accessible from…	Within a VM	Within a VM	Anywhere	Within a VM
Managed by…	Openstack Compute(nova)	OpenStack Block Storage(cinder)	Openstack Object Storage(swift)	OpenStack Shared File System Storage(manila)
Persists until	VM is terminated	Deleted by user	Deleted by user	Deleted by user
Sizing determined by …	Administrator configuration of size settings, know as flavors	User specification in initial request	Amount of available physical storage	User specification in initial request Requests for extension Available user-level quotes limitations applied by Administrator
Encryption configuration	Parameter in nova.conf	Admin establishing encryped volume type, then user selecting encrypted volume	Not yet available	Shared File Systems service does not apply any additional encryption above what the share’s back-end storage provides
Example of typical usage…	10GB first disk, 30 GB second disk	1TB disk	10s of TBs of dataset storage	Depends completely on the size of back-end storage specified when a share was being created. in case of thin provisioning it can be partial space reservat