OpenStack原理框架及在大型公有云可用性分析
一、元件框架
OpenStack專案是一個開源的雲端計算平臺，旨在實現很簡單,大規模可伸縮,功能豐富。來自世界各地雲端計算開發人員和技術人員共同建立OpenStack專案。OpenStack通過一組相關的服務提供一個基礎設施即服務(IaaS)解決方案。每個服務提供了一個應用程式程式設計介面(API),促進了這種整合。根據您的需要,你可以安裝部分或全部服務。下表描述了構成OpenStack架構的OpenStack服務:
| Service | Code Name | Description |
| Identity Service | Keystone | User Management |
| Compute Service | Nova | Virtual Machine Management |
| Image Service | Glance | Manages Virtual image like kernel image or disk image |
| Dashboard | Horizon | Provides GUI console via Web browser |
| Object Storage | Swift | Provides Cloud Storage |
| Block Storage | Cinder | Storage Management for Virtual Machine |
| Network Service | Neutron | Virtual Networking Management |
| Orchestration Service | Heat | Provides Orchestration function for Virtual Machine |
| Metering Service | Ceilometer | Provides the function of Usage measurement for accounting |
| Database Service | Trove | Database resource Management |
| Data Processing Service | Sahara | Provides Data Processing function |
| Bare Metal Provisioning | Ironic | Provides Bare Metal Provisioning function |
| Messaging Service | Zaqar | Provides Messaging Service function |
| Shared File System | Manila | Provides File Sharing Service |
| DNS Service | Designate | Provides DNS Server Service |
| Key Manager Service | Barbican | Provides Key Management Service |
下面的圖顯示了OpenStack服務之間的關係:
為了設計、部署和配置OpenStack，管理員必須理解明白OpenStack的邏輯架構。正如OpenStack概念架構圖顯示，OpenStack包含一些獨立的部分，稱作OpenStack服務。所有服務授權認證都是通過Identity服務。單個服務通過公共APIs與其他服務進行互動，特權管理員使用者命令除外。在內部,OpenStack服務是由幾個程序組成。所有服務至少有一個API程序，用來監聽API請求，預處理它們並傳遞它們到其他服務。除了Identity服務外,其他服務實際工作是由不同的程序完成。對於一個服務之間的程序通訊，使用AMQP訊息塊。這些服務狀態儲存在一個數據庫中。當部署和配置你的OpenStack雲，你可以選擇不同的訊息佇列服務和資料庫服務，如RabbitMQ、MySQL、MariaDB和SQLite。下面的圖顯示了大多數通用的OpenStack雲：
二、在大型公有云可用性分析
1、
專案內通訊機制：
專案內通訊一般使用RPC.call、RPC.cast進行通訊：
RPC.call請求
對於RPC.call請求，藉助官方一張經典的圖來描述：
以nova-compute服務呼叫nova-network服務分配網路為例：
1. nova-compute服務向訊息佇列服務的compute.node佇列傳送RPC請求，並等待請求的最終回覆。
2. nova-network服務通過nova exchange（topic exchange）從compute.node佇列中獲取訊息並作出相應的處理。
3. nova-network服務訊息處理完了之後，向reply_XXX佇列傳送一條回覆訊息
4. nova-compute服務通過reply_XXX exchange（direct exchange）接受從nova-network傳送的RPC訊息。
RPC.cast請求
對於RPC.cast請求，同樣藉助官方一張經典的圖來描述：
以nova-conductor服務呼叫nova-compute服務build_and_run_instance為例：
1. nova-conductor服務向訊息佇列服務的compute佇列傳送RPC請求，請求結束，不需要等待請求的最終回覆。
2. nova-compute服務通過nova exchange（topic exchange）從compute佇列中獲取訊息並作出相應的處理。
在openstack專案中，一般情況下，RPC server端傳送一個請求到訊息佇列，一般只有一個消費者（及時有多個消費者）接受並處理這條訊息，還有一種型別的RPC.cast請求，也稱為fanout_cast請求，fanout_cast傳送的是廣播請求，所有對應的consumer都能接收到。
排程器（Nova-schduler）策略
1、獲取全量資源檢視
2、使用多級filter進行篩選，剔除不需要的宿主機
3、對宿主機進行權重計算，涉及多個緯度
4、按照權重對宿主機進行排序
5、按照優先順序高低依次嘗試資源扣減，提交修改事務，直到成功。
這裡引用官方的經典圖來展示篩選過程。
可用性分析：
大規模公有云需求：
結合現在的工作經驗總結大規模公有云的需求如下：
1、宿主機規模較大，單個區域數W臺，即全域性資源檢視較大。並且渴望全域性最有的排程策略。
2、雲端計算需求爆發式增長，潮汐式海量併發購買，每小時 數萬臺 VM 購買請求，峰值每分鐘上千臺VM 購買請求。
3、使用者期望儘可能快的交付。
openstack用於公有云的問題：
先看一組業界openstack較大規模的效能測試資料：
https://www.cnblogs.com/allcloud/p/5567083.html
文中提到，宿主機規模為400，虛擬機器建立時間最長10分鐘，併發請求最高可以為500。更大規模的測試系統已經變得極不穩定，甚至不可用。
參照業界其他測試，這也確實接近openstack極限效能了
參照前面的架構介紹，分析：
1、專案內通訊依賴基於mq帶有返回的rpc呼叫，會在每個會話中建立臨時的返回佇列。在高併發場景下，會維護大量臨時會話佇列、連線，對系統造成較大的壓力，成為瓶頸。
2、全域性資源檢視的獲取為全量，並且大規模公有云較上面的測試規模增長兩個數量級，所以排程效能成為極大挑戰。
總和上面兩點，可以看出openstack用於大規模公有云，還需要解決需要問題的挑戰才行。