体会思科UCS刀片

本文格式为Word版，下载可任意编辑——体会思科UCS刀片

体会思科UCS刀片

革命性的、前沿的、尖端的等，这些都是用来形容IT领域中好多产品的词汇，但是后来们这些产品却变成了无用的、普通的、不稀奇的。事实上，真正革命性的产品很少见。尽管如此，思科UCS(统一计算系统)却能符合这个要求。

为了能够完全理解思科的这一全新技术，你需要摒弃原来形成的对刀片式服务器和刀片机箱(chassis)的观念。请重新整理你那些关于KVM、控制台访问、网络和存储接口的概念。你要改变服务器数据中心即被存储阵列和网络包围的服务器岛屿的这种思想。思科的优点是从一开始就使用基于刀片式的服务器平台，而且是最大限度地利用刀片式服务器。

简而言之，思科UCS是围围着刀片机箱这一熟悉的概念而建立的，UCS对刀片机箱进行了重构，使之有更强的管理能力和更好的扩展性。这篇总结文章侧重于UCS实质性的细节，以及笔者近期访问思科SanJose测试试验室时操作这个系统的亲身体验。

思科UCS的组成模块

一个CiscoUCS机箱提供八个刀片(一半宽度)插槽，每块刀片配备两个英特尔Nehalem处理器，最多可以容纳96GB的DIMM(8GB)内存;两个SAS驱动插槽，一个LSILogicSASRAID控制器，以及一个刀片背板(backplane)连接。另外，每块刀片还配备了一个Cisco集中网络适配器(CNA)。这个CNA实质上是系统的心脏，即UCS区别于传统刀片式系统的组成部分。

CNA是一个夹层板(mezzanineboard)，它直接跟机箱的网络结构相连，板子上装有QLogic4Gb光纤HBA通道和一个Intel10Gb以太网接口。连接刀片的一端是两个10Gb的NIC和两个4GbFC接口，并在另一端有两个10Gb的连接连到背板上。最初发布的版本不支持每个刀片上有多片CNA，或许那时一个CNA真的就足够了。不过，CNA对于整个UCS系统运行来说是必需的，由于它通过两个10Gb的通道进行存储和网络活动，这使得blade与传统I/O之间有着本质的区别。这是通过使用以太网光纤通道(FCoE)来实现的。因此，系统除了刀片其余的部分都是以太网，系统使用结构互联(FabricInterconnect，FI)来处理FC网络流量。

那么在机箱中我们拥有了一些配备CNA的刀片。在同一个机箱中我们还有两个四口的10Gb光纤接口卡，以及两个FI来驱动所有的东西。技术上称FI为交换机是不确凿的，由于机箱的功能更像是一个装载刀片的远程线路卡。在机箱内部没有交换发生;对于刀片来说它们只是简单的背板，跟FI有直接的连接。物理上，FI的外形跟CiscoNexus5000交换机是一样的，但是FI有更大的功率和存储空间来处理FCoE跟FC之间的大量数据。它们提供了二十个10Gb的端口，每个端口支持一个扩展卡。

这些扩展卡有不同的类型，或支持四个4Gb的FC端口和四个10Gb的以太网端口，或支持六个10Gb的以太网端口，或者支持八个4Gb的FC端口。这是每个FI中除了那二十个10Gb端口以外的硬件。还有三个铜做的管理和簇端口，也有期望的串行控制台接口。FI全权负责UCS方案的管理和业务流程，能够同时运行CLI和GUI界面，不需要任何基于外部服务器的组件。

思科UCS连接各部分

可能你的脑子中已经想出了连接的大约状况。UCS的配置基准应当有两个FI，分别运行在主动/被动模式，所有的网络通讯也是以主动/被动模式在两个FI和每个机箱之间运行。(想想一个带多余主机的CiscoCatalyst6509交换机机箱，即使其中一个主机待机，它上面的以太网口还是可以用的。两个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(数据管理引擎)，它是一个基于内存的关系数据库，控制着方案的所有方面。他是通过一个开放的XMLAPI程序自身驱动的。所有的东西都是围绕这个API进行，利用此API可以十分简单的编写跟显示器连接的脚本或者执行UCS的任何一个功能。实际上，GUI和CLI都是围绕XML配置的基本shell，所以GUI和CLI分别能够做什么和不能够做什么并没有实质上的区别，甚至外部的脚本也一样。UCS是一个令人诧异的、开源的、便利使用的系统。由于这个原则，备份整个UCS配置也变得简单了：整个配置可以通过SCP、FTP、SFTP或者TFTP协议发送到一个服务器上，尽管这一操作不能通过GUI或者CLI来安排。

UCS初次安装大约需要一分钟。第一个FI上面的带外管理接口通过控制台能够获得一个IP地址，通过同样的子网络获得一个簇的IP地址。你所需要做的只是命名这个簇，设置管理员密码就可以了。其次个FI将会监测第一级设置，然后请求一个IP地址参与到系统中。接着，点击簇上面的浏览器会连接到JavaGUI上，这时你就可以对UCS进行配置了。

这个便利的示意图展示了单个机箱跟一对结构互联FI的直接关系。尽管在图中被显示为外部设备，但是结构扩展器(FabricExtender)实际上在机箱自身的内部。

把思科UCS建立起来

第一步是在FI上面定义端口。他们既可以做上行连接端口连接到LAN又可以做服务器端口连接到机箱。右击每个FI的可视标识，然后选择适合的功能来配置这些端口。这比较简单，但是有点麻烦，由于你不能同时选择一组端口，你必需一个一个的定义。一旦你定义了端口，机箱就会自动被连接，几分钟后所有机箱内的刀片都会显示出来，等待你给他们分派任务。

此时事情变得有意思了。在对刀片进行任何的配置之前，你必需定义各种池(pool)和全局设置。这些池涉及光纤通道的WWNN(WorldWideNodeName)和WWPN(WorldWidePortName)分派、以太网MAC的池分派、UUID分派以及刀片上面BMC接口的IP管理池。这些都是开放的，你可以给UUID，

WWNN，WWPN和MAC分派任何你想喜欢的地址范围。实际上，他们太开放了，以至于假使不防备的话，你可能会重复使用这些地址，给自己带来麻烦。然而，配置池十分简单，你只需要指定一个起始地址和放在池里面的地址数量。不过请确保把这些地址搞明白，不要弄错，由于过后你不能修改设置好的池;你只能用相邻的地址范围再设置另外一个池。

上图是一个机箱的错误提醒，显示了一个刀片被突然拉动之后刀片上面的错误标记。下图是一个结构互联的示意图，显示了连接的端口和系统状态。

你还需要考虑固件的修改。你可以把所有刀片器件几个不同的固件版本都装载在FI上，然后把这些版本进行自定义，保证特定的刀片为其每个器件运行特定版本的固件，从FCHBA一直到blade自身的bios设置。由于UCS十分新，所以只有几个可以选择的修订版本，可以通过FTP，SFTP，TFTP，和SCP来把他们装载到FI上。一旦装载到了FI上，固件就会按要求加载到每个刀片中。你还能设置预先定义系统的启动顺序—譬如，先从CD-ROM启动，然后是本地磁盘，再然后是FCLUN，以及PXE(预先启动执行环境)。这些都可以按要求分派到每个服务器实例，假使需要的话还可以只包括一个元素。

你还可以给刀片定义VLAN，以及哪个VLAN应当是本地(native)的。假设每个服务器都会连接那些10Gb的接口，但是本地VLAN分派意味着那不是一个不能变通的要求。在实际工作中，很可能每个blade都会连接电缆，所以上面那个假设成立。然而，FI不会跟VTP(VLAN连接协议)协同的很好，所以VLAN的定义需要手动进行，而不是源自交换局域网其余的部分。假使你需要给你的服务器定义好多VLAN，那么请准备好，你需要进行好屡屡点击和输入。思科希望在后面发布的版本中修正这个问题。

虽然互联结构(FabricInterconnects)不跟网络的其他部分对话VTP，但是你可以定义跟更大的局域网匹配的VLAN.

还有一些其他的零碎事情，譬如擦除策略(scrubpolicies)等。这个策略是为了决定当服务从带本地磁盘的物理刀片抽出的时候应当采取什么行动——换言之，本地磁盘是应当被擦除呢还是可以置之不理。不幸的是，这个“擦除〞不是真正的擦除——它只是毁掉分区表，却没有覆盖磁盘。

一旦已经建立好你的池，你就可以开始把你的刀片建设成实际的服务器了。建设服务器的选择很简单：刀片要么从SAN或者PXE启动，要么从本地磁盘启动。存储管理不在UCS的范围之内，所以让我们假设你有一个器件存储管理程序，你需要给最初的UCS安装分派好多LUN.那么你可以通过UCSGUI列出一个简单的WWNN和WWPN分派列表，并马上把这个列表转出到CSV，这样可以把这个信息十分简单的传递到存储配置的管理员手中。很便利吧。

我好像扯远了——我们还没有建立一个服务器呢。

思科UCS服务配置

服务器的构建是在服务配置文件中定义的，这些文件本身是从服务配置模板中获得的。服务配置模板允许你定义特定的服务器实例，并自动提供一个或多个服务器。一旦您创立了一个全局配置文件，您可以把这个配置文件复制到大量需要完成任务的服务器中去。结构配置文件确定每个刀片组件的固件修订版本;以及可供选择的WWNN，WWPN和MAC池;确定你可能已经定义好的启动顺序;甚至启动方法——通过SAN启动，通过本地启动，或者通过你拥有的其他方法启动。这一切组织起来稀奇的简单。

上面的图显示了所有配置服务的分派状态，以及哪些配置服务被分派到哪些物理刀片上。下图的清单显示了一个WWNN池以及哪些服务配置正在使用的哪些池地址。这个列表可以十分便利的导出为一个CSV格式文件。

你还可以访问你早期建立的以太网和FC端口指示，譬如eth0、eth1、fc0和fc1——这些要跟每个FI对应起来，因此在每个刀片上面产生了一定的冗余。我就在这里遇到过一些错误，举个例子，分派的端口明白的被定义为FabricA，但是当模板应用到一个服务器时，FabricA中不知怎么又冒出了一个FabricB，这就需要手动来校正。他们向我保证他们正在积极的修改这个错误。在这个宏伟的格局中，这只是个小问题，而且强调一下，这是1.0版本。

有两种形式的服务配置模板：原始型和升级型。每个模板都有其优缺点，不幸的是两种模式之间不能相互切换;假使你一开始用的是原始模式，那么以后不能进行升级。

原始型模板用来建立一次性的服务配置，最初的模板没有附件。而升级型的模板是跟这些服务配置形影相随的，所以在升级型模板中改变设置就会引起所有相关服务配置的改动。这是一把双刃剑，由于它可以使服务配置管理变的简单，只要重新启动就会完成这些配置的修改——而几乎不会出现警告。可是当你点击保存的时候，会引起20个刀片都重新启动，虽然这个启动跟改变模板启动顺序步骤那样无伤大雅。假使有一个选择可以错开所有的重新启动，或者可以对其进行时间安排，或者两种选择都有就好了。思科已经知晓这个问题，并且正在着手研究解决方案。

原始型配置没有这个问题，但是一旦建立后，假使需要修改的话，那么你必需一个一个手动修改，一个服务器一个服务器的来。不幸的是，这里没有两全其美的解决方案。

无论如何，你可以建立一个服务配置，定义刀片应当在器件上运行什么固件;把什么样的WWNN，WWPN，和MAC地址分派给刀片上的各种端口;把什么样的管理IP地址分派给BMC;启动刀片的顺序;以及从哪里启动刀片——本地磁盘还是SANLUN.然后你可以把这个配置分派给特定的刀片，或者你可以把所有的刀片汇集在一起组成池，然后把配置分派给这个池，让UCS来选择刀片。然后，奇迹发生了。思科UCSPXE的魔法

在UCS进行处理之前，每个刀片里面什么配置都没有。根据每个服务器服务配置，一个刀片必需能够符合任何数量的特定要求，从固件的修订版本开始。Cisco通过PXE用某种网络PXEmagic程序启动刀片，以及用PXE推动基于Linux的配置代理，完成从什么都没有的刀片到完全配置好的刀片的转变。代理然后访问所有不同的器件，闪存和固件，分派给他们不同的地址，让刀片跟服务配置相符合。这总共需要一到两分钟。随后，刀片重启，并准备接受一个操作系统。

这个过程有点进退两难：假使我想用PXE启动操作系统怎么办呢?通过一些magic程序，UCS配置器PXE框架不会干扰正常的PXE操作。一旦刀片依照服务配置进行了设置，他就会聪明的让路。从这一点开始，你可以像平日一样安装操作系统—譬如，VMwareESXServer，RHEL5.3，或者你有的任何系统。你还可以使用在远程KVM功能中的虚拟媒体工具。这个稍微有点老套了，但是你可以从你的本地系统中选择一个ISO镜像来给刀片作为连接在上面的CD或者DVD，从那里启动来安装操作系统。这时另外一个好玩儿的事情发生了：一般来讲，不用安装任何的驱动程序。WindowsServer2023，RHEL5.3以及

后者VMwareESX3.5U4在他们的默认安装中已经拥有所有的UCS驱动程序。你可能认为思科计划这个已经有段时间了，你还可能会认为思科跟不同的操作系统供应商关系都不错。可能你是正确的。思科UCS在房间中腾跃

现在你用WindowsServer2023，VMwareESX，RHEL5.3，或者别的什么系统软件配置了你的刀片。每个刀片都可以使用你定义的多个VLAN，都受你提出的SANLUN约束，基本上每个刀片都是臃肿的、不做声的，并且运行的十分欢快。那么当一个刀片坏了的时候会发什么事呢?

UCS没有一个真正定义的高可用性，这点有点让人失望。然而，假使你把服务器实例分派到一个有好多刀片的池，它从SANLUN启动，假使其中一个刀片运行那个实例失败，那么会导致实例会从池里面的另外一个同样的刀片启动。这个过程需要几分钟，由于UCS需要根据服务配置的所有设定来准备目标刀片，然后重启，但是它确实提供基本的HA能力。尽管这个穷人的HA实用，但是看到一些“真实的〞HA形式在UCS上定义还是挺不错的。

UCS另外一个重要的方面是结构管理。思科UCS的管理框架利用了继承的概念，这点跟LDAP的思想一样。因此，有可能创立拥有自己策略、池、以及服务配置的组织，而由于子结构可以从父结构的池里面提取等等，这些结构可以从上面的结构中继承策略和池。这让管理简单了大量，可以允许你建立能够成为接受全部内容的全局池和策略，并对那些应用于特定结构的策略设定得更详细。

另外，管理可以顺着结构这条线线安排。用另外一个设施dubbedLocales，管理人员对于特定机构的特定管理职责可以得到特定的权利，那些权利也会传递到子结构。

思科UCS扩展状况

对于所有的IT基础设施来说，可扩展性是关键。令人诧异的是，扩展对于UCS来说却不是个问题。每个UCS6120XPFI可以通过双向局域网上行线处理144个刀片，马上就要发布的6140s可以用同样的方式处理最大304个刀片。这个控制器—刀片比率是十分强大的，它允许UCS能进行极大的扩展，然而所需的只是相对低廉的机箱和刀片，而不是昂贵的FI.

UCS还能提供一些重要的多租户架构。譬如，可能你有彼此独立的工作组或者客户，他们不仅需要从物理硬件上分开彼此，而且还需要完全独立的局域网。使用PinGroup功能可以实现这个目标，它可以把特定的物理接口指定在某组服务器上。你可以把这些应用在局域网或者SAN连接上面，所以你能把特定的服务配置指派给特定的SAN——而不是指派给特定的刀片。

这允许下面的一些状况：使用某个特定部门自己的局域网和SAN创立的一个服务配置可以使用四个刀片。这些服务配置将被指派到特定的上行端口连接到局域网和SAN.假使一个刀片不工作了，那么安排这个刀片上面的服务配置就会分派到另外一个刀片上面——另外的刀片可能位于其他的机箱——然后这个服务器实例作为pingroup的一部分还是会一直保持其物理上的独立性。这对于拥有完全不同的网络部分和存储部分的服务提供商和企业来说，是一个十分大的优点。UCS方案可以用在任何数量的不同的网络拓扑结构中，还能保持物理上的独立性，而且这个会自动进行。

其实可扩展性的事宜就只剩下机箱自身了，譬如一些金属板，一个背板，还有一些组件接口等。机箱中没有智能成分，这也使得他们价格低廉。另外随着FI的大规模批量生产，意味着你扩展越多的机箱，你的方案会越低廉。假使说可以从UCS学到什么的话，那么应当是机箱其实就是FI的扩展，而且无论你需要什么，他们都有足够的带宽来运行。这就是说，一旦你把一组FI装满，你就必需重新开始一个新的簇;不同的UCS簇尚不能在一个单独的管理域里面混合使用。

思科UCS货物出门概不退换，买主须自行留心

坦率的说，UCS的1.0版本提供的功能、范围以及广度给人印象十分深刻。但这并不是说它没有问题。首先，改变服务配置是否会引起刀片重新启动不是很明确。有些状况下，当配置改变可能会引起一个刀片重启的时候会出现警告信息，然而刀片的状态却有点不明确。

我遇到过几个小的GUI问题以及一个更重要的小故障：在一个服务配置推进的过程中，PXE刀片预备启动并不发生。通