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