革命性的、前沿的、尖端的等，這些都是用來形容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可能會引起那場革命。
本文轉自q狼的誘惑 51CTO部落格，原文連結：http://blog.51cto.com/liangrui/893771，如需轉載請自行聯系原作者