UCS 刀片

  革命性的、前沿的、尖端的等,這些都是用來形容IT領域中很多產品的詞彙,但是後來們這些產品卻變成了無用的、普通的、不稀奇的。事實上,真正革命性的產品很少見。儘管如此,思科UCS(統一計算系統)卻能符合這個要求。

  爲了能夠完全理解思科的這一全新技術,你需要摒棄原來形成的對刀片式服務器和刀片機箱(chassis)的觀念。請重新整理你那些關於KVM、控制檯訪問、網絡和存儲接口的概念。你要改變服務器數據中心即被存儲陣列和網絡包圍的服務器島嶼的這種思想。思科的優點是從一開始就使用基於刀片式的服務器平臺,而且是最大限度地利用刀片式服務器。

  簡而言之,思科UCS是圍繞着刀片機箱這一熟悉的概念而建立的,UCS對刀片機箱進行了重構,使之有更強的管理能力和更好的擴展性。這篇總結文章側重於UCS實質性的細節,以及筆者近期訪問思科San Jose測試實驗室時操作這個系統的親身體驗。

  思科UCS的組成模塊

  一個Cisco UCS機箱提供八個刀片(一半寬度)插槽,每塊刀片配備兩個英特爾Nehalem處理器,最多可以容納96GB的DIMM(8GB)內存;兩個SAS驅動插槽,一個LSI Logic SAS RAID控制器,以及一個刀片背板(backplane)連接。另外,每塊刀片還配備了一個Cisco集中網絡適配器(CNA)。這個CNA實質上是系統的心臟,即UCS區別於傳統刀片式系統的組成部分。

  CNA是一個夾層板(mezzanine board),它直接跟機箱的網絡結構相連,板子上裝有QLogic 4Gb光纖HBA通道和一個Intel 10Gb以太網接口。連接刀片的一端是兩個10Gb的NIC和兩個4Gb FC接口,並在另一端有兩個10Gb的連接連到背板上。最初發布的版本不支持每個刀片上有多片CNA,或許那時一個CNA真的就足夠了。不過,CNA對於整個UCS系統運行來說是必須的,因爲它通過兩個10Gb的通道進行存儲和網絡活動,這使得blade與傳統I/O之間有着本質的區別。這是通過使用以太網光纖通道(FCoE)來實現的。因此,系統除了刀片其餘的部分都是以太網,系統使用結構互聯(Fabric Interconnect,FI)來處理FC網絡流量。

  那麼在機箱中我們擁有了一些配備CNA的刀片。在同一個機箱中我們還有兩個四口的10Gb光纖接口卡,以及兩個FI來驅動所有的東西。技術上稱FI爲交換機是不準確的,因爲機箱的功能更像是一個裝載刀片的遠程線路卡。在機箱內部沒有交換髮生;對於刀片來說它們只是簡單的背板,跟FI有直接的連接。物理上,FI的外形跟Cisco Nexus 5000交換機是一樣的,但是FI有更大的功率和存儲空間來處理FCoE 跟 FC之間的大量數據。它們提供了二十個10Gb的端口,每個端口支持一個擴展卡。

  這些擴展卡有不同的類型,或支持四個4Gb的FC端口和四個10Gb的以太網端口,或支持六個10Gb的以太網端口,或者支持八個4Gb的FC端口。這是每個FI中除了那二十個10Gb端口以外的硬件。還有三個銅做的管理和簇端口,也有期望的串行控制檯接口。FI全權負責UCS方案的管理和業務流程,能夠同時運行CLI和GUI界面,不需要任何基於外部服務器的組件。

   思科UCS連接各部分

  可能你的腦子中已經想出了連接的大概情況。UCS的配置基準應該有兩個FI,分別運行在主動/被動模式,所有的網絡通訊也是以主動/被動模式在兩個FI和每個機箱之間運行。(想想一個帶多餘主機的Cisco Catalyst 6509交換機機箱,即使其中一個主機待機,它上面的以太網口還是可以用的。兩個FI也以同樣的方式工作)。它們通過一對1Gb的以太網口互相連接,自身還擁有跟更大CNA連接的帶外管理端口。刀片式服務器機箱通過機箱中每個FEX(結構擴展)上的兩個或者四個10Gb電纜跟FI連接在一起,每個FI都有一套FEX連接。就是這樣,一個完全配置好的、上行線路爲80Gb的機箱有四條電源線和八根SFP+電纜從機箱裏面出來,除此之外沒有別的東西。可以想象,一個完整的UCS機箱能夠裝載56個blade,只用56根數據電纜驅動,如果只用4個10Gb連接,那麼每個機箱只需要28根線。

  從那裏,FI對用一些10Gb的上行線跟LAN連接在一起,FI上面剩餘的結構用來連接機箱。一對FI能夠用連接到數據中心LAN的兩個10Gb上行線驅動18個機箱,每個機箱40Gb,還允許用一個八口的FC擴展卡跟SAN進行4Gb的FC連接。

  UCS配置的基礎是DME(數據管理引擎),它是一個基於內存的關係數據庫,控制着方案的所有方面。他是通過一個開放的XML API程序自身驅動的。所有的東西都是圍繞這個API進行,利用此API可以非常容易的編寫跟顯示器連接的腳本或者執行UCS的任何一個功能。實際上,GUI和CLI都是圍繞XML配置的基本shell,所以GUI和CLI分別能夠做什麼和不能夠做什麼並沒有實質上的區別,甚至外部的腳本也一樣。UCS是一個令人驚奇的、開源的、方便使用的系統。由於這個原則,備份整個UCS配置也變得簡單了:整個配置可以通過SCP、FTP、SFTP或者 TFTP協議發送到一個服務器上,儘管這一操作不能通過GUI 或者 CLI來安排。

  UCS初次安裝大約需要一分鐘。第一個FI上面的帶外管理接口通過控制檯能夠獲得一個IP地址,通過同樣的子網絡獲得一個簇的IP地址。你所需要做的只是命名這個簇,設置管理員密碼就可以了。第二個FI將會監測第一級設置,然後請求一個IP地址加入到系統中。接着,點擊簇上面的瀏覽器會連接到Java GUI上,這時你就可以對UCS進行配置了。

  這個方便的示意圖展示了單個機箱跟一對結構互聯FI的直接關係。儘管在圖中被顯示爲外部設備,但是結構擴展器(Fabric Extender)實際上在機箱自身的內部。

 

把思科UCS建立起來

  第一步是在FI上面定義端口。他們既可以做上行連接端口連接到LAN又可以做服務器端口連接到機箱。右擊每個FI的可視標識,然後選擇合適的功能來配置這些端口。這比較簡單,但是有點麻煩,因爲你不能同時選擇一組端口,你必須一個一個的定義。一旦你定義了端口,機箱就會自動被連接,幾分鐘後所有機箱內的刀片都會顯示出來,等待你給他們分配任務。

  此時事情變得有意思了。在對刀片進行任何的配置之前,你必須定義各種池(pool)和全局設置。這些池涉及光纖通道的WWNN(World Wide Node Name)和WWPN (World Wide Port Name)分配、以太網MAC的池分配、UUID分配以及刀片上面BMC接口的IP管理池。這些都是開放的,你可以給UUID, WWNN, WWPN和MAC分配任何你想喜歡的地址範圍。實際上,他們太開放了,以至於如果不小心的話,你可能會重複使用這些地址,給自己帶來麻煩。然而,配置池非常簡單,你只需要指定一個起始地址和放在池裏面的地址數量。不過請確保把這些地址搞清楚,不要弄錯,因爲過後你不能修改設置好的池;你只能用相鄰的地址範圍再設置另外一個池。

  上圖是一個機箱的錯誤提醒,顯示了一個刀片被突然拉動之後刀片上面的錯誤標記。下圖是一個結構互聯的示意圖,顯示了連接的端口和系統狀態。

  你還需要考慮固件的修改。你可以把所有刀片器件幾個不同的固件版本都裝載在FI上,然後把這些版本進行自定義,保證特定的刀片爲其每個器件運行特定版本的固件,從FC HBA一直到blade自身的bios設置。因爲UCS非常新,所以只有幾個可以選擇的修訂版本,可以通過FTP, SFTP, TFTP, 和 SCP來把他們裝載到FI上。一旦裝載到了FI上,固件就會按要求加載到每個刀片中。你還能設置預先定義系統的啓動順序—比如,先從CD-ROM啓動,然後是本地磁盤,再然後是FC LUN,以及PXE(預先啓動執行環境)。這些都可以按要求分配到每個服務器實例,如果需要的話還可以只包括一個元素。

  你還可以給刀片定義VLAN,以及哪個VLAN應該是本地(native)的。假設每個服務器都會連接那些10Gb的接口,但是本地VLAN分配意味着那不是一個不能變通的要求。在實際工作中,很可能每個blade都會連接電纜,所以上面那個假設成立。然而,FI不會跟VTP(VLAN連接協議)配合的很好,所以VLAN的定義需要手動進行,而不是源自交換局域網其餘的部分。如果你需要給你的服務器定義很多VLAN,那麼請準備好,你需要進行很多次點擊和輸入。思科希望在後面發佈的版本中修正這個問題。

  雖然互聯結構(Fabric Interconnects)不跟網絡的其他部分對話VTP,但是你可以定義跟更大的局域網匹配的VLAN.

  還有一些其他的零碎事情,比如擦除策略(scrub policies)等。這個策略是爲了決定當服務從帶本地磁盤的物理刀片抽出的時候應該採取什麼行動——換言之,本地磁盤是應該被擦除呢還是可以置之不理。不幸的是,這個“擦除”不是真正的擦除——它只是毀掉分區表,卻沒有覆蓋磁盤。

  一旦已經建立好你的池,你就可以開始把你的刀片建設成實際的服務器了。建設服務器的選擇很簡單:刀片要麼從SAN或者PXE啓動,要麼從本地磁盤啓動。存儲管理不在UCS的範圍之內,所以讓我們假設你有一個器件存儲管理程序,你需要給最初的UCS安裝分配很多LUN.那麼你可以通過UCS GUI列出一個簡單的WWNN 和 WWPN分配列表,並立即把這個列表轉出到CSV,這樣可以把這個信息非常簡單的傳遞到存儲配置的管理員手中。很方便吧。

  我好像扯遠了——我們還沒有建立一個服務器呢。

 

思科UCS服務配置

  服務器的構建是在服務配置文件中定義的,這些文件本身是從服務配置模板中獲得的。服務配置模板允許你定義特定的服務器實例,並自動提供一個或多個服務器。一旦您創建了一個全局配置文件,您可以把這個配置文件複製到許多需要完成任務的服務器中去。結構配置文件確定每個刀片組件的固件修訂版本;以及可供選擇的WWNN,WW PN和MAC池;確定你可能已經定義好的啓動順序;甚至啓動方法——通過SAN啓動,通過本地啓動,或者通過你擁有的其他方法啓動。這一切組織起來出奇的簡單。

  上面的圖顯示了所有配置服務的分配狀態,以及哪些配置服務被分配到哪些物理刀片上。下圖的清單顯示了一個WWNN 池以及哪些服務配置正在使用的哪些池地址。這個列表可以非常方便的導出爲一個CSV格式文件。

  你還可以訪問你早期建立的以太網和FC端口指示,比如eth0、eth1、fc0和fc1——這些要跟每個FI對應起來,因此在每個刀片上面產生了一定的冗餘。我就在這裏遇到過一些錯誤,舉個例子,分配的端口清楚的被定義爲Fabric A,但是當模板應用到一個服務器時, Fabric A中不知怎麼又冒出了一個Fabric B,這就需要手動來校正。他們向我保證他們正在積極的修改這個錯誤。在這個宏偉的格局中,這只是個小問題,而且強調一下,這是1.0版本。

  有兩種形式的服務配置模板:原始型和升級型。每個模板都有其優缺點,不幸的是兩種模式之間不能互相切換;如果你一開始用的是原始模式,那麼以後不能進行升級。

  原始型模板用來建立一次性的服務配置,最初的模板沒有附件。而升級型的模板是跟這些服務配置形影相隨的,所以在升級型模板中改變設置就會引起所有相關服務配置的改動。這是一把雙刃劍,因爲它可以使服務配置管理變的簡單,只要重新啓動就會完成這些配置的修改——而幾乎不會出現警告。可是當你點擊保存的時候,會引起20個刀片都重新啓動,雖然這個啓動跟改變模板啓動順序步驟那樣無傷大雅。如果有一個選擇可以錯開所有的重新啓動,或者可以對其進行時間安排,或者兩種選擇都有就好了。思科已經知曉這個問題,並且正在着手研究解決方案。

  原始型配置沒有這個問題,但是一旦建立後,如果需要修改的話,那麼你必須一個一個手動修改,一個服務器一個服務器的來。不幸的是,這裏沒有兩全其美的解決方案。

  無論如何,你可以建立一個服務配置,定義刀片應該在器件上運行什麼固件;把什麼樣的WWNN, WWPN, 和MAC地址分配給刀片上的各種端口;把什麼樣的管理IP地址分配給BMC;啓動刀片的順序;以及從哪裏啓動刀片——本地磁盤還是SAN LUN.然後你可以把這個配置分配給特定的刀片,或者你可以把所有的刀片彙集在一起組成池,然後把配置分配給這個池,讓UCS來選擇刀片。然後,奇蹟發生了。

 

思科UCSPXE的魔法

  在UCS進行處理之前,每個刀片裏面什麼配置都沒有。根據每個服務器服務配置,一個刀片必須能夠符合任何數量的特定要求,從固件的修訂版本開始。Cisco通過PXE用某種127.0.0.0網絡PXE magic程序啓動刀片,以及用PXE推動基於Linux的配置代理,完成從什麼都沒有的刀片到完全配置好的刀片的轉變。代理然後訪問所有不同的器件,閃存和固件,分配給他們不同的地址,讓刀片跟服務配置相符合。這總共需要一到兩分鐘。隨後,刀片重啓,並準備接受一個操作系統。

  這個過程有點進退兩難:如果我想用PXE啓動操作系統怎麼辦呢?通過一些magic程序,UCS配置器PXE框架不會干擾正常的PXE操作。一旦刀片按照服務配置進行了設置,他就會聰明的讓路。從這一點開始,你可以像平時一樣安裝操作系統—比如,VMware ESX Server,RHEL 5.3,或者你有的任何系統。

  

 

上圖顯示的是完全不一樣的東西:一個Cisco BIOS POST畫面

  你還可以使用在遠程KVM功能中的虛擬媒體工具。這個稍微有點老套了,但是你可以從你的本地系統中選擇一個ISO鏡像來給刀片作爲連接在上面的CD或者DVD,從那裏啓動來安裝操作系統。這時另外一個有趣的事情發生了:一般來講,不用安裝任何的驅動程序。Windows Server 2008, RHEL 5.3以及後者VMware ESX 3.5 U4在他們的默認安裝中已經擁有所有的UCS驅動程序。你可能認爲思科計劃這個已經有段時間了,你還可能會認爲思科跟不同的操作系統供應商關係都不錯。可能你是正確的。

  思科UCS在房間中跳躍

  現在你用Windows Server 2008, VMware ESX, RHEL 5.3,或者別的什麼系統軟件配置了你的刀片。每個刀片都可以使用你定義的多個VLAN,都受你提出的SAN LUN約束,基本上每個刀片都是臃腫的、不做聲的,並且運行的十分歡快。那麼當一個刀片壞了的時候會發什麼事呢?

  UCS沒有一個真正定義的高可用性,這點有點讓人失望。然而,如果你把服務器實例分配到一個有很多刀片的池,它從SAN LUN啓動,如果其中一個刀片運行那個實例失敗,那麼會導致實例會從池裏面的另外一個同樣的刀片啓動。這個過程需要幾分鐘,因爲UCS需要根據服務配置的所有設定來準備目標刀片,然後重啓,但是它確實提供基本的HA能力。儘管這個窮人的HA實用,但是看到一些“真實的”HA形式在UCS上定義還是挺不錯的。

  UCS另外一個重要的方面是結構管理。思科UCS的管理框架利用了繼承的概念,這點跟LDAP的思想一樣。因此,有可能創建擁有自己策略、池、以及服務配置的組織,而由於子結構可以從父結構的池裏面提取等等,這些結構可以從上面的結構中繼承策略和池。這讓管理簡單了許多,可以允許你建立能夠成爲接受全部內容的全局池和策略,並對那些應用於特定結構的策略設定得更詳細。

  另外,管理可以順着結構這條線線安排。用另外一個設施dubbed Locales,管理人員對於特定機構的特定管理職責可以得到特定的權利,那些權利也會傳遞到子結構。

  思科UCS擴展情況

  對於所有的IT基礎設施來說,可擴展性是關鍵。令人驚奇的是,擴展對於UCS來說卻不是個問題。每個UCS 6120XP FI可以通過雙向局域網上行線處理144個刀片,馬上就要發佈的6140s可以用同樣的方式處理最大304個刀片。這個控制器—刀片比率是非常強大的,它允許UCS能進行極大的擴展,然而所需的只是相對便宜的機箱和刀片,而不是昂貴的FI.

  UCS還能提供一些重要的多租戶架構。比如,可能你有彼此獨立的工作組或者客戶,他們不僅需要從物理硬件上分開彼此,而且還需要完全獨立的局域網。使用Pin Group功能可以實現這個目標,它可以把特定的物理接口指定在某組服務器上。你可以把這些應用在局域網或者SAN連接上面,所以你能把特定的服務配置指派給特定的SAN——而不是指派給特定的刀片。

  這允許下面的一些情況:使用某個特定部門自己的局域網和SAN創建的一個服務配置可以使用四個刀片。這些服務配置將被指派到特定的上行端口連接到局域網和SAN.如果一個刀片不工作了,那麼安排這個刀片上面的服務配置就會分配到另外一個刀片上面——另外的刀片可能位於其他的機箱——然後這個服務器實例作爲pin group的一部分還是會一直保持其物理上的獨立性。這對於擁有完全不同的網絡部分和存儲部分的服務提供商和企業來說,是一個非常大的優點。UCS方案可以用在任何數量的不同的網絡拓撲結構中,還能保持物理上的獨立性,而且這個會自動進行。

  其實可擴展性的事宜就只剩下機箱自身了,比如一些金屬板,一個背板,還有一些組件接口等。機箱中沒有智能成分,這也使得他們價格便宜。另外隨着FI的大規模批量生產,意味着你擴展越多的機箱,你的方案會越便宜。如果說可以從UCS學到什麼的話,那麼應該是機箱其實就是FI的擴展,而且無論你需要什麼,他們都有足夠的帶寬來運行。這就是說,一旦你把一組FI裝滿,你就必須重新開始一個新的簇;不同的UCS簇尚不能在一個單獨的管理域裏面混合使用。

 

思科UCS貨物出門概不退換,買主須自行當心

  坦率的說,UCS的1.0版本提供的功能、範圍以及廣度給人印象非常深刻。但這並不是說它沒有問題。首先,改變服務配置是否會引起刀片重新啓動不是很明確。有些情況下,當配置改變可能會引起一個刀片重啓的時候會出現警告信息,然而刀片的狀態卻有點不明確。

  我遇到過幾個小的GUI問題以及一個更重要的小故障:在一個服務配置推進的過程中,PXE刀片預備啓動並不發生。通過KVM控制檯手動重啓這個刀片就會讓把所有的東西回到正規。在所有組建和拆卸刀片的過程中,這個故障就發生了這麼一次。

  令人有點擔心的是UCS故障監測方面的問題。舉個例子,把一個驅動器從正在運行的主機上的RAID1陣列中抽出來,這個事件不會引發故障信息來顯示驅動器已經出問題了。然而,它確實會產生一個通知,顯示服務器現在違反了分配給它的配置,因爲它只有一個磁盤。另外,重新插入磁盤以使得服務器符合配置文件,但是卻不會產生指示RAID陣列重新組建狀態的信息。事實上,除了利用重新啓動然後進入RAID控制器BIOS,好像沒有別的方法來查看這方面的信息了,然而這個方法有點麻煩。Cisco已經把跟這個問題相關的bug列成了文件,並且希望在即將發佈的版本中解決這些問題。

  另外一個小的需要考慮的事情是,雖然思科與此無關,但是談到將FC SAN作爲UCS的附件,他必須支持NPIV((N_Port ID虛擬化)。大多數現在的FC SAN應該不會有這方面的問題,但是這是一個絕對的要求。

  最後,是成本的問題。如果所有的東西都要購買思科的,那麼UCS不是很便宜。除非你打算至少使用三個機箱,否則的話他們未必值那個錢。原因是機箱相對來說比較便宜,但是FI和相關的許可卻非常貴。然而,UCS內在的可擴展性意味着你可以把很多的刀片放在兩個FI上,所有當你擴展機箱和刀片的時候,投資就顯得值得了。一個裝配精良的UCS配置,帶32個雙Nehalem E5540 CPU的刀片、本地SAS驅動器和48GB的RAM,每個價值差不多338,000美元。但是增加另外一個裝配精良的機箱只需花費78,000美元,與同等規格的傳統刀片機箱相比,價格便宜了近一半。

  的確,我發現了UCS的某些問題,不過基本上它們是很好的建立在基礎之上的。而同樣給我印象深刻的是UCS的可管理性、可擴展性,以及相對的簡易性。有很多理由喜歡UCS,以及很多理由喜歡那句話:UCS可能會引起那場革命。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章