云落誰家？OpenStack基于場景的架構設計實踐 ( 簡體 字) |
| 作者：占海,張繼勇 | 類別：1. -> 程式設計 -> 雲計算 |
| 譯者： |
| 出版社：電子工業出版社 |  3dWoo書號： 43528
詢問書籍請說出此書號！【缺書】
NT售價： 295 元 |
| 出版日：3/1/2016 |
| 頁數：224 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787121276491 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：前 言
一、本書的初衷、讀者定位及解決的問題
本書將OpenStack應用場景歸為下面幾類：
1．通用型應用場景；
2．計算密集型應用場景；
3．高負載存儲型應用場景；
4．高吞吐網絡型應用場景；
5．混合云應用場景；
6．跨地域多點型應用場景；
7．大規模可擴展型應用場景；
8．其他應用場景。
其實，它們之間并沒有那么嚴格的界限，比如用戶的場景是高性能計算，那么它不僅是計算密集型，也需要很大的存儲吞吐量。我們嘗試盡可能地簡化，便于用戶根據自身的業務做出選擇。
本書是寫給打算架設OpenStack 基礎設施即服務云的設計師和架構師們的，以及OpenStack的咨詢顧問、售前顧問。本書不是講解OpenStack的代碼設計及其體系結構的，也不是講解如何部署和故障排查的，也不是講如何優化、運維的。
正如各個技術媒體、市場分析所言，OpenStack本身并不是一個產品，甚至整個基礎設施即服務云都不能作為產品來看待，加上OpenStack下面的一些子項目的成熟度較低，作為最終用戶部署OpenStack就有了很大的難度，如針對自身的業務模式，該如何選擇OpenStack組件？是否選擇眾多的OpenStack供應商？硬件基礎設施該選擇哪些？監控、計費如何解決？是否需要二次開發定制？安全性如何？運維是否和原來的服務托管有本質的不同？
如果上述這些問題正是你現在考慮的，那么本書很適合你，書中根據常見的IT場景，給出了相應的解決方案。如果本書的場景并不完全吻合你的需求，你也可以通過這些場景稍加變化，就可以設計出最適合自己的OpenStack解決方案。
二、OpenStack市場現狀
根據最近的Forrest市場報告，很欣慰地看到OpenStack已經準備好企業級服務了，已經有世界級大公司成功應用于生產環境，如迪斯尼、寶馬、沃爾瑪等。但OpenStack也有一個失敗的“領地”，那就是新興的互聯網廠商們都沒有選擇它，如netflix、Airbnb等。
在公有云的“領地”，其實也不太樂觀，比如惠普退出了其基于OpenStack的產品，收購Encalyptus后，開始專注于為客戶提供融合架構的私有云服務。在基于OpenStack的發行版廠商中，最早做OpenStack解決方案的Nubla公司于2015年5月宣布破產。雖然有一些公司因為各種原因，沒有將OpenStack推向市場，或是商業模式，或是管理，但是仍然有一些公司在前行著，比如Mirantis。
讓我們將目光轉回到國內，基于OpenStack做私有云服務的廠商基本上算是全軍覆沒了，關于他們失敗的總結，其實就是不理解開源生態系統，這里筆者就不多做討論了，有興趣的讀者可以關注筆者的博客。基于OpenStack做公有云市場，比如易云捷訊、UnitedStack等。易云捷訊利用其與國內傳統ERP提供商用友的關系，試圖在中小型企業的企業資源規劃、人力資源管理等應用提供基礎設施平臺。
OpenStack的熱潮正在退去，這從國內的社區就可以看出端倪。我們知道國內喜歡跟風，正如2000年左右的Linux一樣，但都是三分鐘的熱度。很多人已經轉向最近更火的Docker、Mesos等項目，這樣反而對OpenStack在國內的發展更加有利，因為少了那些“煽風點火”的人，多了一些沉著的態度。OpenStack真正進入企業界，才剛剛開始。隨著新的項目，如Murano，Ironic，Manila等不斷地完善和發布，OpenStack正在被不斷地刷新，比如Murano的出現，解決了傳統企業軟件部署的問題。
就在最近，作為全球技術創新的領跑者Google，也正式加入了OpenStack陣營，相信OpenStack會有更加美好的明天，能夠為企業和互聯網提供優秀的基礎設施平臺。
三、閱讀本書所需要的知識儲備
閱讀本書，要求你對如下知識點至少有所了解：
Linux 操作系統的操作；
云計算，尤其是基礎設施即服務的相關架構；
TCP/IP網絡協議，對SDN最好有所了解；
虛擬化相關；
企業級系統的設計；
存儲知識，如SAN、NAS、分布式文件系統等；
高可用集群。
四、本書的方法論
云的魅力在于它可以干任何事，無論健壯性還是靈活性，都是相當好的。是的，云具有很高的靈活性，且幾乎可以做任何事，但是想要充分發揮云的威力，定義好云將如何使用是非常重要的，否則創建和測試的使用案例意義就不復存在了。這里講述的是那些設計最適合、用戶最關注的云架構背后的思考過程。
用例選擇規劃看起來是反直覺的，比如使用Amazon的服務，從注冊到使用也就是花5分鐘的時間而已。難道Amazon真的不關心用戶的計劃？錯了，Amazon的產品管理部門花了大量的時間去研究吸引他們典型用戶的究竟是什么，也在琢磨著交付更好的服務。對于企業來說，計劃的流程沒有什么不同，只是不會去規劃外部的付費用戶罷了。舉例來說，用戶僅僅是內部的應用程序開發者或者是Web門戶。下面所列的目標，在考慮創建用例時用得到。
總體業務目標
開發務必清晰定義，符合業務目標和需求；
增加項目的支持，積極和業務相關人員、客戶以及最終用戶保持溝通。
技術
協調OpenStack架構中各個項目，努力通過社區獲得更多的支持；
為自動化設計一套好的流程，可大大提高開發和部署的效率；
使用恰當的工具可提高開發的效率；
創建更好的、更多的測試指標和測試工具，以支持開發的持續集成、測試流程和自動化。
組織
選用好多消息工具和良好的管理支持團隊；
增強文化氛圍，如對于開源的理解、云架構、敏捷開發、持續開發/測試/集成等。總而言之，涉及開發的所有環節都需要。
下面舉例來進行說明，假想一個業務目標是使用云來構建某公司的電子商務站點。此目標意味著應用程序將要支持每秒成千上萬的會話，各種負載以及大量復雜和瞬息萬變的數據。通過識別如每秒并發事務、數據庫的大小等關鍵指標，相信構建出一個基于假設的測試方法是可行的。
基于用戶場景開發功能。基于用戶場景開發功能可輕松開發測試用例，即可在項目的整個過程中有個預期。假如組織沒有準備好一個應用，或者沒有準備好一個用于開發用戶需求的應用，那么就需要創建需求，以構建合適的測試工具和開發可用的指標。一旦指標確認，即使遇到需求變更，也可以輕松面對快速變化，而且無須過度擔心提前具體需求。將此類使用創新的方法配置系統，不能因為需求的變化而每次都重新設計。
云的局限特性集。建立需求是發掘用戶痛點，而不是重新創建OpenStack已經有的工具集。認為建立OpenStack只有一種好辦法，那只能弄巧成拙。在開發一個平臺時，通過限制集中帶來的慢速是非常重要的，因為它會導致需求轉變為處理工具本身，所以請不要重新創建一整套的工具。想成功部署云，與技術產品負責人一起建立關鍵功能十分重要。
1. 為云準備好應用程序
盡管云被設計出來是讓事情變得更簡單，但是要意識到“使用云”不僅僅是建立一個實例，然后將應用丟進去這么簡單，這一點是非常重要的。這種一夜之間平地起高樓的事情是不會發生的，要明白在云和過去的基于服務器硬件環境，以及虛擬化環境是有著本質上的區別的。
在過去的環境中，還有那些過去的企業級應用，服務器和應用的運行都是被當作“寵物”看待的，它們被精心地照看和愛護，甚至每臺服務器都有自己的名字，如“甘道夫”或“哆啦A夢”，一旦它們“生病”了，則需要人去“護理”，直到“恢復健康”。所有的這些設計表明應用是不可以停止的。
在云的環境中，打個比方，服務器更像是牛群中的某一頭牛。它們太多了，成千上萬，命名的方式可能是類似“NY-1138-Q”的編號，如果它們中的一個出問題了，管理員會直接拋棄它，再重新安裝和啟動一個即可。遺留的應用還沒有準備好運行在此云環境中，所以很自然地會遭遇停運，丟失數據，甚至更加糟糕。
在為云設計應用時，還有另外一些原因需要注意。一些是防御性的，例如一些應用并不能準確地確定在什么地方，或什么樣的硬件去啟動，所以它們需要靈活性，即使做不到，至少應該保持適應性更強。另外一些則是主動性的，例如使用云的一個優點是具有高擴展性，所以應用需要被設計得能夠使用這些優點。當然云還有更多的優點，也得一并考慮。
2. 確定哪些應用程序是可在云中運行的
尋找適合于在云中運行的應用，還是有幾種方法可以考慮的。
結構：那些大型的、單層次的、“鐵板一塊”的舊應用是非常典型不適合云環境的。將負載分割為多個實例會獲得高效，所以部分系統失效不會特別影響其他部分的系統，或者說隨應用的需要而橫向擴展。
依賴：如果應用程序依賴特別的硬件，比如特別的芯片或者類似指 紋識別等外設，是不適合云計算的。除非使用特別的方式來實現。同樣，如果應用依賴于操作系統或一組程序庫不能用于云環境，或者無法在虛擬化環境中運行，這就真的成了問題了。
連通性：自包含的應用或它們所依賴的資源在云的環境無法實現，將無法運行。也許在一些情況下，通過自定義網絡解決了這些問題，但是運行是否良好，還得看選擇云的環境。
耐久性和彈性：盡管有服務水平協議（SLA）的存在，但還是會有一些壞的事情發生：服務器宕機、網絡連接發生紊亂、多個租戶無法訪問服務等。應用程序必須足夠穩固，以應對上述情況的發生。
3. 設計云
這里有一些原則性忠告，在為一個應用設計云的時候請時刻銘記。
做一個悲觀主義者：承擔一切失敗，基于目標選擇手段。善待那些將系統“搞壞”的程序。
將雞蛋放在多個籃子里：考慮多個供應商，基于地理分區不同的數據中心，多可用的Zones以容納本地存在的隱患。可移植性的設計。
考慮效率：低效的設計將不可擴展。高效的設計可以無須花費多少錢就可以輕松擴展。去掉那些不需要的組件或容量。
保持偏執：深度設計防御，通過構建在每一層和每個組件之間的安全，確保零差錯。不信任任何人。
但是也不要太偏執：不是所有的應用都需要“鉆石級”的解決方案。為不同的服務水平協議、不同的服務層和安全級別等，分別設計不同的架構。
管理數據：數據通常是最靈活的，也最復雜的一塊，尤其是在云中或云集成的架構中。要在分析和傳送數據方面付出更多的努力。
放手：自動化可以增加一致性、質量以及減少響應時間。
分離和征服：盡可能分區和并行的分層。盡可能確保組件足夠小且可移植。在層之間使用負載均衡。
保持彈性：隨著增加的資源，確保結果是增加的性能和擴展。減少資源負面影響。
保持動態：激活動態配置變化，如自動擴展、失效恢復、資源發現等，以適應變化的環境、錯誤的發生以及負載的變化。
貼近原則：通過移動高度密切的組件和相似數據靠近以減少延遲。
保持松散：松耦合，服務接口，分離關注度高的點，抽象并定義好的應用程序接口，交付靈活。
注意開銷：自動擴展、數據傳輸、虛擬軟件許可證、保留的實例等，均會快速增加每月的使用支出。密切監測使用情況。 |
內容簡介：本書總共有8 章的內容，將OpenStack 的應用場景分為了幾類，每章介紹了不同的場景。第1 章介紹了通用型應用場景；第2~4 章分別介紹了計算密集型、高負載存儲型、高吞吐網絡型應用場景；第5 章介紹了混合云應用場景；第6 章介紹了跨地域多點型應用場景；第7 章介紹了大規模可擴展型應用場景；第8 章介紹了一些其他的應用場景。
本書是寫給打算架構設計OpenStack 基礎設施即服務云的設計師和架構師們的，以及OpenStack 的咨詢顧問、售前顧問。如果你正在考慮如何部署OpenStack，正在考慮如何選擇OpenStack 組件、如何選擇硬件基礎設施、如何解決監控和計費的問題、如何進行架構設計才最具安全性等問題，那么你可以通過本書在各個類型的云架構場景中找到想要的答案。 |
目錄：第1章 通用型應用場景 1
1.1 場景描述 1
1.2 需求分析 2
1.3 技術架構設計 4
1.3.1 規劃計算資源 5
1.3.2 規劃網絡資源 7
1.3.3 規劃存儲資源 9
1.3.4 軟件選擇 11
1.3.5 性能 14
1.3.6 可用性 17
1.3.7 安全性 18
1.4 運營服務設計 20
1.4.1 技術支持和維護 21
1.4.2 監控 21
1.4.3 宕機時間 21
1.4.4 容量規劃 22
1.5 架構實體選型建議 23
1.5.1 選擇存儲硬件 26
1.5.2 選擇網絡硬件 29
1.5.3 軟件選擇 30
1.5.4 針對性能敏感的負載 34
1.6 典型案例實踐 35
第2章 計算密集型應用場景 39
2.1 場景描述 39
2.2 需求分析 40
2.3 技術架構設計 41
2.3.1 擴展計劃 43
2.3.2 CPU和內存 43
2.3.3 額外的硬件 45
2.3.4 量力而行 45
2.4 運營服務設計 48
2.4.1 支持和維護 49
2.4.2 監控 50
2.4.3 計劃內和計劃外服務器宕機時間 50
2.4.4 容量計劃 50
2.5 架構實體選型建議 51
2.5.1 存儲硬件選擇 53
2.5.2 選擇網絡硬件 55
2.5.3 軟件選擇 56
2.6 典型案例實踐 60
第3章 高負載存儲型應用場景 65
3.1 場景描述 65
3.2 需求分析 66
3.3 技術架構設計 68
3.4 運營服務設計 69
3.4.1 管理效率 70
3.4.2 應用的可知性 71
3.4.3 容錯和可用性 71
3.4.4 擴展存儲服務 73
3.5 架構實體選型建議 75
3.5.1 計算（服務器）硬件選擇 77
3.5.2 網絡硬件選擇 79
3.5.3 軟件選擇 79
3.6 典型案例實踐 83
3.6.1 帶數據處理服務的計算分析 85
3.6.2 帶數據庫服務的高性能數據庫 86
第4章 高吞吐網絡型應用場景 89
4.1 場景描述 89
4.2 需求分析 91
4.2.1 高可用問題 92
4.2.2 風險 93
4.2.3 安全性 94
4.3 技術架構設計 94
4.3.1 二層架構的局限性 96
4.3.2 三層架構的優勢 97
4.3.3 三層架構的局限性 98
4.3.4 網絡建議的總結 98
4.3.5 額外的考慮因素 99
4.4 運營服務設計 102
4.5 架構實體選型建議 104
4.5.1 對設計的影響 105
4.5.2 可調聯網組件 108
4.6 典型案例實踐 109
4.6.1 負載均衡 111
4.6.2 覆蓋網絡 111
4.6.3 性能調優 111
4.6.4 網絡功能 112
4.6.5 云存儲 113
第5章 混合云應用場景 115
5.1 場景描述 115
5.2 需求分析 116
5.2.1 法律需求 117
5.2.2 負載考慮 118
5.2.3 工具考量 119
5.2.4 網絡考慮 120
5.2.5 風險規避和管理考慮 120
5.3 技術架構設計 121
5.3.1 容量計劃 122
5.3.2 安全性 123
5.3.3 量力而行 123
5.3.4 性能 124
5.3.5 組件 125
5.3.6 特殊因素 125
5.4 運營服務設計 126
5.4.1 敏捷性 126
5.4.2 應用準備 127
5.4.3 升級 127
5.4.4 網絡操作中心 127
5.4.5 可維護性 128
5.5 架構實體選型建議 128
5.5.1 鏡像移植 129
5.5.2 上層服務 130
5.5.3 網絡服務 131
5.5.4 數據 131
5.6 典型案例實踐 132
5.6.1 突破到一個不是OpenStack的公有云 133
5.6.2 高可用/災難恢復 134
第6章 跨地域多點型應用場景 137
6.1 場景描述 137
6.2 需求分析 138
6.2.1 負載特性 138
6.2.2 鏡像和模板在跨不同站點時要保持一致性 139
6.2.3 高可用 139
6.2.4 應用準備 140
6.2.5 成本 140
6.2.6 站點失效和恢復 141
6.2.7 合規性和地理位置 141
6.2.8 審計 141
6.2.9 職責分工 142
6.2.10 站點之間的認證 142
6.3 技術架構設計 142
6.3.1 量力而行 144
6.3.2 性能 144
6.3.3 安全性 145
6.3.4 OpenStack組件 146
6.4 運營服務設計 146
6.4.1 許可 147
6.4.2 記錄日志和監測 147
6.4.3 升級 148
6.4.4 配額管理 149
6.4.5 規則管理 149
6.4.6 文檔 150
6.5 架構實體選型建議 150
6.5.1 OpenStack服務架構 151
6.5.2 存儲 152
6.5.3 網絡 152
6.5.4 依賴 153
6.6 典型案例實踐 153
6.6.1 地理冗余負載均衡 155
6.6.2 本地服務 157
第7章 大規模可擴展型應用場景 159
7.1 場景描述 159
7.2 需求分析 160
7.2.1 用戶需求 161
7.2.2 運營者的需求 162
7.3 技術架構設計 163
7.3.1 基礎設施隔離 163
7.3.2 主機聚合 165
7.3.3 可用域 165
7.3.4 隔離的例子 166
7.4 運營服務設計 167
7.4.1 最前沿 167
7.4.2 增長和容量計劃 168
7.4.3 技能和培訓 169
7.5 架構實體選型建議 169
7.5.1 選擇存儲硬件 171
7.5.2 選擇網絡硬件 173
7.5.3 軟件選擇 175
第8章 其他應用場景 179
8.1 多虛擬機管理器 180
8.2 虛擬桌面基礎設施（VDI） 185
8.3 特殊網絡應用示例 187
8.4 軟件定義網絡 188
8.5 OpenStack上的OpenStack 190
參考資料 193
名詞解釋 196
OpenStack社區介紹 200
后記 204 |
| 序： |
