思科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可能会引起那场革命。