后者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方案可以用在任何数量的不同的网络拓扑结构中，还能保持物理上的独立性，而且这个会自动进行。