革命性的、前沿的、***的等，这些都是用来形容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界面，不需要任何基于外部服务器的组件。
#p#
思科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）实际上在机箱自身的内部。
#p#
把思科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，这样可以把这个信息非常简单的传递到存储配置的管理员手中。很方便吧。
我好像扯远了——我们还没有建立一个服务器呢。
#p#
思科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来选择刀片。然后，奇迹发生了。
#p#
思科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驱动程序。你可能认为思科计划这个已经有段时间了，你还可能会认为思科跟不同的操作系统供应商关系都不错。可能你是正确的。
#p#
思科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，管理人员对于特定机构的特定管理职责可以得到特定的权利，那些权利也会传递到子结构。
#p#
思科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簇尚不能在一个单独的管理域里面混合使用。
#p#
思科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可能会引起那场革命。
【编辑推荐】
