6g下載網
當前位置: 主頁 > 軟件教程 > 云計算 >

OpenStack可擴展性怎么設計?OpenStack可擴展性設計教程

時間: 2016-12-27 21:40 來源: 本站整理

分享到:

OpenStack可擴展性怎么設計?今天小編整理一篇OpenStack可擴展性設計教程的文章和大家分享,希望能給大家提供幫助。

雖然傳統應用需要更大的硬件來進行擴展(“垂直擴展”),但是基于云的應用通常需要更多的離散硬件(“水平擴展”)。 如果您的云成功,最終您必須添加資源以滿足日益增長的需求。

為了適應云模式,OpenStack本身設計為可水平擴展。 而不是切換到較大的服務器,您采購更多的服務器,只需安裝相同配置的服務。 理想情況下,您在消息總線上進行通信的功能相同的服務組(例如,計算節點或nova-api節點)之間進行橫向擴展和負載平衡。

起點

確定云的可擴展性和如何改進它是一個具有許多變量平衡的練習。 沒有一個解決方案滿足每個人的可擴展性目標。 但是,跟蹤一些指標是有幫助的。 由于您可以在OpenStack中定義虛擬硬件模板(稱為“flavors”),因此您可以根據所提供的風格開始做出擴展決策。 這些模板定義RAM中的內存大小,根磁盤大小,可用的臨時數據磁盤空間量以及啟動器的核心數。默認OpenStack模板如表所示:

OpenStack可擴展性怎么設計?OpenStack可擴展性設計教程

大多數的起點是你的云的核心數。 通過應用一些比率,您可以收集有關以下內容的信息:您希望運行的虛擬機(VM)數量((overcommit fraction×cores)/每個實例的虛擬核心數)需要多少存儲(flavor磁盤大小×實例數)您可以使用這些比率來確定需要多少額外的基礎架構來支持云。下面是使用比率收集預期虛擬機數量和所需存儲的可伸縮性信息的示例。 以下數字支持(200/2)×16 = 1600個VM實例,并且/ var / lib / nova / instances需要80 TB的存儲空間: 200物理內核。大多數實例的大小為m1.medium(兩個虛擬核心,50 GB的存儲)。默認CPU過載比率(nova.conf中的cpu_allocation_ratio)為16:1。 但是,您需要的核心數量不僅僅是估計API服務,數據庫服務器和隊列服務器可能遇到的負載。您還必須考慮云的使用模式。作為具體示例,將支持托管web托管平臺的云與針對每個代碼提交創建一個VM的開發項目的運行集成測試進行比較。在前者中,創建VM的繁重工作僅發生在幾個月,而后者在云控制器上施加不變的重負載。您必須考慮平均VM生命周期,因為更大的數字通常意味著云控制器上的負載更少。除了VM的創建和終止,您必須考慮訪問服務的用戶的影響 - 特別是在nova-api及其相關數據庫上。列出實例獲取大量信息,并且考慮到用戶運行此操作的頻率,具有大量用戶的云可以顯著增加負載。這可能會發生,即使沒有他們的知識,離開打開的OpenStack儀表板實例選項卡在瀏覽器中刷新VM列表每30秒。考慮這些因素后,您可以確定需要多少云控制器內核。一個典型的八核,8 GB的RAM服務器足以滿足多達一個機架的計算節點 - 考慮到上述警告。您還必須考慮用戶虛擬機性能的關鍵硬件規格,以及預算和性能需求,包括存儲性能(主軸/核心),內存可用性(RAM /內核),網絡帶寬(Gbps /內核)和總體CPU性能(CPU /內核)。

添加云控制器節點

您可以通過添加節點來促進云的水平擴展。添加計算節點很簡單 - 它們很容易被現有安裝所拾取。但是,當您將集群設計為高可用性時,必須考慮一些重要的問題。回想一下,云控制器節點運行幾種不同的服務。您可以安裝僅在內部使用消息隊列進行通信的服務(nova-scheduler和nova-console)在新服務器上進行擴展。然而,其他整體部件需要更加小心。您應該負載平衡面向用戶的服務,如dashboard,nova-api或Object Storage代理。使用任何標準HTTP負載平衡方法(DNS輪循,硬件負載平衡器或軟件,如Pound或HAProxy)。儀表板的一個警告是VNC代理,它使用WebSocket協議 - L7負載均衡器可能會遇到的東西。另請參閱Horizo??n會話存儲。您可以配置一些服務,例如nova-api和glance-api,通過更改其配置文件中的標志來使用多個進程 - 允許它們在一個機器上的多個內核之間共享工作。

隔離你的云

當您希望為用戶提供不同的區域,以便為數據存儲,跨地震故障線路的冗余或低延遲API調用提供合法注意事項時,您需要隔離云。 使用以下OpenStack方法之一隔離云:單元,區域,可用區或主機聚合。每種方法提供不同的功能,并且可以最好地分成兩組:單元和區域,它隔離整個云并導致運行單獨的Compute部署。可用區和主機聚合,它們僅僅劃分一個Compute部署。下表包含了OpenStack隔離方法提供了OpenStack Compute當前提供的每個隔離方法的比較。

OpenStack可擴展性怎么設計?OpenStack可擴展性設計教程

單元和區域

OpenStack計算單元被設計為允許以分布式方式運行云,而不必使用更復雜的技術,或者侵入現有的nova安裝。云中的主機被劃分為稱為單元的組。單元格在樹中配置。頂層單元(“API單元”)有一個運行nova-api服務但沒有nova-compute服務的主機。每個子單元都運行在常規安裝中找到的所有其他典型的nova- *服務,除了nova-api服務。每個單元具有其自己的消息隊列和數據庫服務,并且還運行nova單元,其管理API單元和子單元之間的通信。這允許使用單個API服務器來控制對多個云安裝的訪問。除了主機的常規nova調度器選擇之外,引入第二級調度(單元選擇)提供了更大的靈活性來控制虛擬機在哪里運行。與具有單個API端點不同,每個安裝區域都有單獨的API端點,允許更為離散的分離。希望在網站上運行實例的用戶必須顯式選擇一個區域。然而,不需要運行新服務的額外復雜性。 OpenStack儀表板(horizon)可以配置為使用多個區域。這可以通過AVAILABLE_REGIONS參數配置。

可用區域和主機聚合

您可以使用可用區域,主機聚合或兩者來分區nova部署。可用區通過類似于主機聚合的方式實現和配置。但是要根據不同原因來使用它們。

可用區域

這使您能夠將OpenStack計算主機安排為邏輯組,并提供一種形式的物理隔離和冗余與其他可用區域,例如通過使用單獨的電源或網絡設備。您可以定義指定計算主機在每個服務器上本地駐留的可用區域。 可用性區域通常用于標識具有公共屬性的一組服務器。 例如,如果數據中心中的某些機架位于單獨的電源上,則可以將服務器放在這些機架中的自己的可用區域中。 可用區還可以幫助分離不同類別的硬件。當用戶提供資源時,他們可以指定他們希望從哪個可用區域構建其實例。 這允許云消費者確保其應用程序資源分布在不同的機器上,以在硬件故障的情況下實現高可用性。

主機聚合區域

這使您能夠將OpenStack Compute部署分區為邏輯組,以實現負載均衡和實例分配。您可以使用主機聚合來進一步分區可用性區域。例如,您可以使用主機聚合將可用區分區為共享公用資源(如存儲和網絡)或具有特殊屬性(如可信計算硬件)的主機組。主機聚合的常見用途是提供用于與nova-scheduler一起使用的信息。例如,您可以使用主機聚合對一組共享特定風格或圖像的主機進行分組。這種情況的一般情況是在flavor的extra_specs元數據中的聚合元數據和匹配鍵值對中設置鍵值對。過濾器調度程序中的AggregateInstanceExtraSpecsFilter將強制僅在聚合中的主機上調度實例,這些聚合將相同的鍵定義為相同的值。這種一般概念的高級使用允許不同的風味類型以不同的CPU和RAM分配比率運行,使得高強度計算負載和低強度開發和測試系統可以共享同一云而不會使高利用系統挨餓或浪費低利用率系統的資源。這通過在您的主機聚合中設置元數據并在您的flavor類型中匹配extra_specs。第一步是將聚合元數據鍵cpu_allocation_ratio和ram_allocation_ratio設置為浮點值。在計劃聚合中的主機時,過濾器調度程序AggregateCoreFilter和AggregateRamFilter將使用nova.conf中的全局默認值,而不使用這些值。使用此功能時請務必謹慎,因為每個主機可以在多個聚合中,但每個資源只應有一個分配比例。你應該避免將主機放在為同一資源定義不同值的多個聚合中。這是方程的前半部分。要獲取保證特定比率的模板類型,您必須將模板類型中的extra_specs設置為您要在聚合中匹配的鍵值對。例如,如果將extra_specs cpu_allocation_ratio定義為“1.0”,那么該類型的實例將僅在元數據鍵cpu_allocation_ratio也定義為“1.0”的情況下在聚合中運行。在實踐中,最好定義一個附加的鍵值對在聚合元數據中匹配而不是直接匹配cpu_allocation_ratio或core_allocation_ratio。這允許更好的抽象。例如,通過定義密鑰過量落實并設置值“高”,“中”或“低”,您可以調整聚合中的數字分配比率,而不需要更改與它們相關的所有模板類型。

可擴展的硬件

雖然已經存在一些資源來幫助部署和安裝OpenStack,但確保您提前規劃部署是非常重要的。 本指南假定您至少為OpenStack云預留了一個機架,但也提供了何時和什么擴展的建議。

硬件采購

“云”被描述為一個易變的環境,其中可以隨意創建和終止服務器。雖然這可能是真的,但這并不意味著您的服務器必須是易失性的。確保云的硬件穩定和配置正確意味著您的云環境保持正常運行。基本上,努力創建一個穩定的硬件環境,使您可以托管一個云,用戶可以認為是不穩定和易變的。 OpenStack可以部署在與OpenStack兼容的Linux發行版支持的任何硬件上。硬件不必是一致的,但它至少應該具有相同類型的CPU來支持實例遷移。推薦用于OpenStack的典型硬件是大多數硬件供應商庫存的標準價值產品。將采購劃分為諸如“計算”,“對象存儲”和“云控制器”的構建塊,并根據需要請求盡可能多的這些塊。或者,如果您無法支出更多,如果您有現有的服務器,只要它們滿足您的性能要求和虛擬化技術,他們很可能能夠支持OpenStack。

容量規劃

OpenStack旨在以直接的方式增加大小。 考慮到我們在本章中提到的考慮 - 特別是在云控制器的規模 - 應該可以根據需要采購額外的計算或對象存儲節點。 新節點不需要是與現有節點相同的規范,甚至是供應商。對于計算節點,nova-scheduler將處理與核心計數和RAM量有關的大小差異; 但是,您應該考慮用戶體驗隨著不同的CPU速度而變化。 當添加對象存儲節點時,應指定反映節點能力的權重。監控資源使用和用戶增長將使您知道何時采購。 日志和監視詳細介紹了一些有用的指標。

老化測試

服務器硬件故障的機會在其使用壽命的開始和結束時很高。 因此,通過適當的老化測試可以避免在生產期間處理硬件故障,以嘗試觸發早期故障。 一般原則是強調硬件的極限。 老化測試的示例包括運行CPU或磁盤基準測試幾天。

OpenStack可擴展性設計教程的文章和大家分享結束,感謝閱讀!

(責任編輯:大衛)

分享到:

------分隔線----------------------------
? 35选7福利彩票