iThome
太空,人類的終極邊疆……,這段臺詞,是許多科幻迷熟悉的Star Trek系列影集的片頭引言,如今,在伺服器虛擬化、雲端服務當道的時代,每一種基礎架構與上層應用都不能或缺的「網路」,卻成為終極邊疆。
為什麼我們這麼說?一方面是因為資料中心最普遍的GbE網路,已經越來越不夠用,具有更高頻寬的10GbE遲遲無法普及,直到最近才出現升級潮,一方面許多新推出的網路協定或架構,例如FCoE、Ethernet Fabric、軟體定義式網路(SDN)、網路功能虛擬化(NFV),希望讓企業網路環境能夠走向高度整合、簡化、效率,卻由於變革太過劇烈,始終無法吸引許多企業採用。
既有經驗不能完全適用,企業不懂如何管理虛擬環境下的網路
以企業端的IT基礎架構應用而言,各家IT大廠無不全力鼓吹軟體定義式的IT環境∕資料中心的概念,提出了超融合架構(Hyper-Converged Infrastructure),透過通用的x86伺服器設備,將運算、儲存與網路資源整合於一體,已成為大勢所趨。
不過,這股浪潮似乎僅止於前兩者,主要針對的IT架構都是非常龐大的環境,就像很多廠商喊出的口號「Web Scale IT」、「HyperScale Data center」。
相形之下,大多數企業對於虛擬化環境的應用,仍停留在運算和儲存資源的調度。雖然,許多公司懂得用vMotion或Live Migration的VM線上遷移功能的好處,甚至也知道去用DRS(Distributed Resource Scheduler)或PRO(Performance and Resource Optimization)的VM自動線上遷移,讓關鍵應用系統的運作持盈保泰,後來,隨著Virtual SAN、Virtual Volumes這類產品推出之後,也重掀企業關注儲存虛擬化的風潮,但對於網路的使用和管理,仍處於很原始的階段,甚至可以說是非常保守。
例如,伺服器虛擬化已經進入相當成熟的階段,隨著商用、開源Hypervisor多家爭鳴,企業、雲服務業者想要導入伺服器虛擬化技術,選擇很多,而且可說是易如反掌,想要自行搭配軟硬體,或採購廠商最佳化配置好的整櫃式套件,都相當方便。
儲存虛擬化在最近幾年以來,也有重大突破。過去只有專屬的儲存虛擬化軟體方案,後來則進入到軟體定義式儲存的階段,隨著VMware推出與本身虛擬化平臺密切整合的Virtual SAN,以及結合眾多系統廠商的多節點伺服器硬體之力,發布了融合vSphere、vCenter與VSAN的EVO:RAIL平臺之後,將相關的整合帶到新的里程碑。
相較之下,網路虛擬化或所謂的軟體定義式網路,功能發展與普及程度卻是進展最為緩慢的,相關技術還在不斷演進、競爭,企業對此的接受度與採用率,也一直無法提升。而且,就算是純粹以伺服器虛擬化環境而言,對於網路共用資源的能否有效管理與最佳配置,這樣的基本需求也一直被忽視。
伺服器虛擬化應用規模越來越大,網路不夠用了!
在資料中心環境當中,伺服器虛擬化的應用是日益普及,已經無庸置疑,對臺灣的企業而言也不例外,目前已經到達技術採用的爆發期。
根據iThome 2015年CIO大調查的結果顯示,企業採用VM私有雲的比例,從20.9提升到28.3%。而且,每家公司所擁有的VM平均數量,已經到達50.2臺,相較於2014年,成長率高達63.5%。同時,當前企業內部應用系統虛擬化的比例,也來到40.6%
若就軟體採購項目來看,伺服器虛擬化這一類產品仍名列前三大,僅次於Office與作業系統,但比例開始下滑。市占最高的伺服器虛擬化平臺是VMware vSphere,65.7%的臺灣企業都在用,其次是微軟Hyper-V,比例為25.2%,跟去年相比所差無幾,顯示市場有逐漸飽和的跡象。因此,整體而言,伺服器虛擬化的確是企業IT環境不可或缺的應用之一,建置這類平臺的需求確立了,也已經導入,接下來的問題是,我們懂得如何妥善運用它嗎?環境準備好了嗎?
值得注意的是,在虛擬化環境的系統需求當中,通常我們會注意到處理器、記憶體、硬碟或網路儲存空間這幾個條件,對於網路連線的資源夠用與否,卻是比較輕忽。
會有這樣的結果,單就伺服器端歷年來的規格演進來看,也可發現一些端倪。例如,新推出的伺服器平臺,往往強調可支援更多處理器與記憶體的配置,而且,每顆處理器內的運算核心數量越來越多、記憶體運作時脈也有與日俱增的趨勢,相較之下,預設提供的網路介面,卻大多還是以2個GbE埠的規格居多。
而隨著虛擬化應用的普及,伺服器所面對的內外I/O需求也越來越巨大,就算擁有強大的運算核心與充裕的記憶體資源,還是不能大意,因為伺服器端的對外網路頻寬一旦不足,還是會影響系統的整體運作效能。
當然,如果伺服器的硬體擴充性夠,用戶還是可以選購網卡、插上去使用,就能讓伺服器得到更多網路介面,但這麼一來,不只增加耗電量,在網路布線上也會變得很複雜,連帶地,對於伺服器所連接的交換器而言,也必須提供更多網路埠來對應,而導致需要建置更多臺交換器,但交換器數量一多,又衍生出管理這些網路設備的需求。
於是,很多人會開始考慮導入頻寬更大的10GbE網路,近年來,10GbE規格的網卡與網路設備的成本也日漸下滑,普及度也因此增加,但還是比較貴,尚無法取代GbE,一躍而成資料中心網路環境的主流配備。
但這個態勢的確正在轉變,許多新推出的伺服器除了預設搭配4個GbE埠,還可讓用戶選購其他組態,例如GbE埠、10GbE埠各2個,以及4個10GbE埠。
就網路設備的採購趨勢來看,其實也可看到10GbE網路的建置方興未艾。根據iThome 2015年CIO大調查的網通採購重點項目,有16.3%的臺灣企業投入10GbE網路環境的部署,今年排名提升到第六,相較之下,去年10GbE網路採購的重要性是第十,企業比例則是10%。此外,蟬聯第一名寶座的網路設備升級、第四名的網路效能分析,某種程度上,也跟企業資料中心網路效能需求持續增長的現象有關。
虛擬網路奠基在實體網路
透過虛擬化技術的幫忙,企業能夠將實體伺服器的運算、儲存與網路,變成一個資源池,讓多臺虛擬機器可以依據需求去配置這些資源,然後同時執行起來,達到一機多用的效果。但要能支撐更大的應用規模,伺服器所擁有的這些資源,也必須很充裕,以網路的存取來說,若伺服器端的網路介面可提供的頻寬不夠,連帶也將影響裡面執行的虛擬機器網路效能。
網路架構是虛擬化環境與雲端服務的重要基礎
若要支撐超大規模的資料中心應用,例如私有雲、公有雲的服務需求,單靠既有實體網路的架構,可能無法因應,也因此,將整個資料中心的網路基礎設施加以虛擬化的浪潮興起,這當中,不只是支應伺服器虛擬化環境的應用,也可以運用到Ethernet Fabric、軟體定義式網路(SDN)、網路功能虛擬化(NFV)等概念。
從實體網路環境,走向虛擬化環境的網路環境
實體交換器提供傳統的網路存取方式,下可連接多臺伺服器,上可連接到核心交換器,相關設備的部署,也都是獨立於伺服器之外,並且針對使用規模較為固定的網路環境。同時,為了持續提供網路服務,也需要保有一定的備援能力。
相較之下,伺服器虛擬化環境下的虛擬交換器,所提供的網路存取方式和實體交換器一樣,並且具有一般L2交換器的大部分功能,但虛擬交換器是在伺服器內模擬出來的,並不是獨立的一臺實體設備,我們可以把多臺虛擬機器配置的虛擬網卡接到同一臺虛擬交換器,然後再將實體伺服器的網路介面,指派給這臺虛擬交換器作為它的上行埠(uplink),而實體伺服器的網路介面對外,則接到實體的核心交換器。
在虛擬化環境當中,對於實體網路的穩定性與效率更加仰賴
資料中心走向虛擬化、軟體定義式架構已經是大勢所趨,IT人員、開發者會透過軟體來主導整體IT基礎架構的應用方式,但這並不代表硬體設備的穩定度與效能無關緊要,事實上,IT基礎架構虛擬化之後,每臺伺服器可能要同時承擔多臺VM的運作,因此對於運算、儲存、網路等不同性質的系統資源利用率,也會跟著提高。
簡而言之,硬體要能負荷得住,才能讓軟體的執行無後顧之憂,這個道理不只適用在現行的實體伺服器、個人電腦,對於伺服器虛擬化環境來說,因為本身要具有同時擔當多個應用系統工作負載的能耐,又要能動態地運用所有共享的整體系統資源,當然也不例外。
然而,在系統資源的管理上,處理器的核心數量、記憶體容量、儲存空間都有明確而具體的數值,可供IT人員評估,相較之下,實體網路本身就很抽象,相關資源的使用率也非常動態,不易被量化,因此,一旦發生效能不彰、管理不當、資源不足的情況,都不容易在第一時間發現,除非徹底斷線,或連網速度慢到太離譜。若在虛擬環境當中,這些網路問題,可能會因為有好幾層架構相疊,更加隱而不現,若想要找出關鍵點,難度也很高,因為,實際上,會影響網路效能的環節變得更多。
舉例來說,在既有的實體環境,若要觀察網路流量的變化,只需關注伺服器的網路介面,以及所連接的交換器、路由器,想進行封包側錄,都有既定的作法可供參考與進行,如果要借助免費或付費的網管軟體來監控,選擇也很多。
而在虛擬環境,網路傳輸不只是發生在上述地方,也有可能在同一臺伺服器裡面的不同VM之間,會影響連線效能的因素更多,可能牽涉到的範圍也比實體環境更廣、更深,可專門針對這樣特殊環境應用的網管軟體,相形之下,卻較少,負責這方面作業的人,不只要精通實體網路的管理,也要對虛擬化環境的特性夠了解,才能通盤考量。
總而言之,實體網路的良窳,仍然是整體系統效能的關鍵因素之一,也是支撐伺服器虛擬化、儲存虛擬化、網路虛擬化,以及各種雲端服務的重要基礎。
因為,若實體網路故障,虛擬化的網路連線可能也將跟著停擺,而導致上層的應用系統、IT服務無法運作,影響業務運作,因此能否快速恢復正常運作,很重要。假如它的架構太過複雜,讓人難以部署與維護,也會增加日常管理的負擔與費用,所以,應盡可能簡化,不要疊床架屋。
此外,它的運作方式必須要有效率,如果資料中心環境裡面,有許多網路連線與交換器連接埠處於閒置狀態,或利用率太低,也等於浪費了企業花大筆預算和人力所投入的網路基礎建設。
虛擬化環境為什麼會出現網路效能不彰的現象?
若以伺服器虛擬化環境來說,會影響整體運作效能的因素,跟伺服器本身是否擁有充裕的資源,有密切的關係。
一般人最容易察覺的部分,主要是處理器運算能力、記憶體配置、硬碟存取速度,而這些地方會發生效能瓶頸,往往跟VM本身的資源配置不足有關,例如,vCPU等待運算完成的時間太久,或是VM系統記憶體容量不足,而需透過磁碟置換(Disk Swap)產生虛擬記憶體來動態擴充,硬碟的部份,則有可能因為VM系統端的應用程式啟用了Log監控記錄功能,而增加了許多存取硬碟的工作。
而在虛擬化環境若出現網路連線效能的問題,主要原因是發生了封包遺失(Packet Loss)。根據RISC Networks這家IT效能分析服務公司的觀察,有超過4,600家公司,在虛擬交換器連接埠的環境當中,都遭遇了封包遺失,其中,有64%的公司表示,這種狀況,發生在伺服器虛擬化平臺的主機端接收來自虛擬交換器的封包時,同時,也有26%公司反應,在主機連到虛擬交換器的時候,遺失了封包。
對於這種現象,ExtraHop Networks公司稱為虛擬封包遺失(Virtual Packet Loss,VPL),通常會發生在負載沈重的虛擬環境裡面。起因是伺服器虛擬化平臺所在的實體主機,承擔了太多的虛擬機器──雖然在這樣效能超載(oversubscription)的主機上,虛擬機器還是看起來可以正常運作,但當中執行的應用系統,效能會很糟糕。
因為,此時,網路封包的接收會不斷地延遲,若時間拖得太久,發出封包的裝置會以為封包遺失,或者假設網路流量處於擁塞的狀態,於是降低傳送率。為了減緩這樣的流量堵塞情況,發送端會再試著重新傳送封包,但還是無法奏效,因為網路的流量仍無法動彈,看似封包遺失,但實際上封包並未遺失。
這種狀況會形成骨牌效應,導致吞吐量變慢、資料傳送時間延長,連帶地,應用程式的執行效能也跟著停滯。
麻煩的是,這種現象會間歇性發作,而非持續出現,而且,傳統的系統監控與管理工具受限既有的技術,可能難以偵測到。
上述狀況只是發生在執行伺服器虛擬化平臺的伺服器內部,在這之外,例如該臺主機的網路介面、連接的網路交換器等位置上,又會有其他因素會導致封包遺失。RISC Networks公司進一步歸納出下列幾個可能的要點:網路設備的上行埠(uplinks)、L3網路層的介面、伺服器端對外連線的網路埠,以及透過L2資料連結層,對5臺以上的主機執行封包轉送作業,而且這些主機的所在地,是未知的網路或不在企業管轄範圍內。
網路配置不當,VM連接SAN儲存發生封包遺失
當 伺服器虛擬化平臺的主機或虛擬機器存取SAN儲存網路時,如果流量超過交換器的負荷時,也會發生丟棄封包的狀況,此時,主機或虛擬機器需花一些時間判定是 否發生封包遺失的狀況,確認後會再重新傳送封包,但如此一來,又會占用到原本可用來存取網路儲存資源的頻寬。(如上圖)
若應用程式或系統想要將大量資料寫入SAN儲存網路時,最好能透過多個連線的方式進行,如果採取較少量的連線進行傳輸,可能會出現流量超載的狀況。
透過指令顯示ESXi主機的網路封包丟棄比例
在VMware vSphere的ESXi主機上,管理者可透過esxtop這支指令,了解目前這臺系統的網路狀態,其中兩個欄位──%DRPTX、%DRPRX,分別代表傳送過程的封包丟棄比例,以及接收過程的封包丟棄比例。
如何避免VPL?
前面提到的虛擬封包遺失狀況,我們一旦了解到,問題點主要是在執行伺服器虛擬化的主機本身,該如何避免?
以目前最多企業採用的vSphere為例,VMware在探討vSphere整體效能最佳實務的文件上,提到了幾個建議作法。
首先,是伺服器端需具備足夠的處理器資源,在實體環境上,若要處理的網路流量越大,就需要更多CPU運算資源協助,在虛擬化環境當中更是如此,如果伺服器端的處理器資源不足,可能就會影響系統整體的網路吞吐量,因此要時時注意處理器利用率。
其次,是伺服器的網路介面配置。由於vSphere可支援網路介面共享與專屬等兩種模式,適合的情境也有所不同。
在多臺虛擬機器共用單一實體網路埠的組態下,若其中有幾臺虛擬機器的網路流量較大,很可能會拖累其他臺虛擬機器的網路效能,此時可以將特定實體網路埠,指派給這些用量特別大或不能忍受延遲傳送的虛擬機器,將它們的網路I/O隔離開來,以免影響其他系統。
在同一臺伺服器裡面的兩臺虛擬機器,若要彼此連線,在網路介面的組態上,應設定連到同一臺虛擬交換器。若它們各自連到不同臺虛擬交換器,相關的流量會傳到伺服器之外的實體網路上,這將衍生非必要的處理器運算與網路存取的負擔。
熱門新聞
2024-12-08
2024-12-08
2024-11-29
2024-12-08