1.1 神龍架構的特色服務器
阿里雲官方文檔對於神龍架構的描述以下:
保留了普通雲服務器的資源彈性,並因嵌套虛擬化技術讓彈性裸金屬服務器保留了物理機的體驗。架構
1.2 理解上的難點性能
同時擁有云服務器的資源彈性和保留了物理機體驗的特色容易讓用戶在須要深刻了解神龍架構時產生一個疑問:神龍架構究竟是虛的仍是實的,若是虛實融合又怎麼來理解什麼是虛實融合?經過什麼手段作到的?阿里雲
1.3 本文重點說明的問題雲計算
結合以上神龍架構的特色和理解上的難點,本文詳細的對於神龍架構進行研究分析,說明神龍架構是如何作到同時擁有云服務器的資源彈性和保留了物理機體驗的目標的。spa
2.1 以搬磚爲例說明虛擬化技術的特色blog
把物理機變成虛擬機的這個技術,就是「虛擬化」。好比我家裏裝修有100塊磚須要搬運,鄰居家也在裝修一樣有100塊磚須要搬運,咱們各請了50個搬運工,當工人到達時發現鄰居家的主人在睡覺,所以他家的50個工人只能等他睡醒再搬磚,我家請的50個工人則能夠直接幫我開始搬磚,狀況以下圖所示:資源
正好兩家的工人來自於同一個公司因而包工頭過來看了一下,發現鄰居家的工人在空閒狀態以爲效率很低。因而決定既然鄰居家的工人目前空閒因而一塊兒來幫我家搬磚。和我商量費用並不增長,工人增長50個,我天然很是開心,以爲多給了我家50個工人。因而鄰居家的工人也過來開始幫我家搬磚以下圖所示,咱們稱這個100個工人爲計算節點:文檔
包工頭內心在想一個事情,他立刻須要去其餘工地,如今100個工人都在幫我家搬磚,所以進度很快,可是鄰居萬一睡醒了也要開始搬磚怎麼辦,因而他抽了一個工人甲出來看着鄰居家動靜,一旦鄰居家醒了須要開始搬磚,則把暫時幫我家搬磚的工人還給他而且工人數量至少50個。get
因而甲離開了搬磚行動,專門看着鄰居家主人防止他忽然醒過來,幫我家搬磚的工人數目前爲99個。這個負責關心鄰居家主人睡覺狀況並負責後續把工人還給他的甲,咱們稱他爲管理節點。
鄰居家主人睡醒了,甲因而當即從我家將50個工人安排到鄰居家開始搬磚,同時和我商量,由於以前我家搬磚的勞動力多了一倍,所以1000塊磚被搬了只剩50塊了,而鄰居家的磚仍是1000塊,所以除了鄰居僱傭的50個工人外可否我家只留5個工人,我本身僱傭的45個工人也幫鄰居家搬磚,我欣然贊成,所以兩家搬磚的工人數再一次改變如圖所示:
這個整個過程即爲彈性計算的本質,前提便是虛擬化,若是缺乏了虛擬化技術,表明我和鄰居家僱傭的工人來自於兩個公司,沒有人來統籌決定每家搬磚的工人數,所以即便鄰居在睡覺,他僱傭的工人空閒着也沒法過來幫我搬磚,可以作到搬磚的工人靈活調配的前提就是將兩家人家僱傭的工人進行統籌考慮再進行分配。對於用戶的好處在於,我和鄰居家都有1000塊磚要搬,可是搬磚的時間不一樣,我在搬磚的時候他在睡覺而他睡醒須要搬磚的時候我家的磚已經快搬完了,一樣100個工人的勞動力在不一樣的時間段裏被咱們用到了極致。
2.2 虛擬化技術的瓶頸
從以上搬磚的例子中能夠發現,由於工人甲負責協調我和鄰居家搬磚的工人安排所以他自己再也不負責搬磚,也就是100個勞動力中抽調了1個工人的勞動力來作管理工做,實際搬磚的勞動力爲99個。按照原來僱傭的勞動力,我家僱傭了50個工人,鄰居家僱傭了50個工人,總的勞動力爲100人,所以實際搬磚的勞動力少了1個,但由於我和鄰居家搬磚時間的錯開而且以咱們的感覺都享受到了遠大於50個工人的勞動力(實際我家99個,鄰居醒來後他家爲94個)所以知足咱們的需求,也就並不太在乎100個工人中有1個來做爲協調咱們兩家工人數的管理人員。隱患在於若是我家磚搬完了,鄰居家的搬磚工人上升到99個,他發現須要再快一點,要求100個工人搬磚,這時候我和鄰居將同時發現勞動力由於有人去作管理工做而少了一個,咱們兩家總共花了100個工人的錢,卻總共只能享受到99個工人的勞動力。
事實上這1個管理人員確實是整個體系中沒法解決的瓶頸,表明只要採用虛擬化和彈性計算,就表明100個勞動力必須選擇1個管理人員,實際上只能有99個勞動力進行搬磚。反映到雲計算上就是隻要物理服務器採用虛擬化技術,就必須配置管理節點,所以單臺物理服務器所提供的計算力在原來的基礎上須要打折扣,形成物理服務器基礎上採用虛擬化技術後生成的雲服務器的計算性能必然比物理服務器要差。雖然用戶由於雲服務器集羣的彈性計算功能未必能感覺到。
這個瓶頸原來在雲服務提供商中都存在,彷佛成爲了必然,由於以爲沒有辦法解決因須要管理節點而形成的總計算力損失所以也沒有云服務商去討論深究這個問題。而阿里雲神龍架構即破天荒的在這個瓶頸問題上開始動刀子,想作到的目標就是既然100個工人搬磚,就要所有搬磚,但同時也須要有手段來管理和控制我家和鄰居家不一樣時間搬磚的工人數。
本文做者:朱祺
本文爲阿里雲內容,未經容許不得轉載。