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