【IT168 评测】革命性的、前沿的、尖端的等，这些都是用来形容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来选择刀片。然后，奇迹发生了。