在本话题的第一部分，我们就已经讨论过统一计算系统（UCS）的潜在问题和成本。

　　伴随UCS的较大问题就是厂商的锁定，它给企业带来的影响正反面都有。与单一厂商结盟可能带来协助和支持来源单一的好处。但是如果特定的方案妨碍了关键的业务活动或增长，不能成功解决当前根本的技术需求，或者阻止了与环境中运行着的其它重要非UCS设备或软件之间的交互操作，结果可能会剧烈下滑。

　　有关与非UCS技术互操作性的最后一个观点绝非夸大。例如， UCS平台也许是设计来运行Vmware管理程序的，但如果你将来不能够将其切换至Xen或Hyper-V，那将是一个潜在的问题，它会限制数据中心未来的灵活性。这是从硬件角度看到的相似问题。

　　“如果我引进Cisco [UCS]，我仍旧有Juniper，环境里面还有其它设备．．．我必须将这些都关联起来，那它们的工作效果会怎样呢？”Schulz说。

　　那么，这里有一个厂商自己的问题。选择一个UCS就意味着托付给这个厂商和它的发展路线，但如果厂商改变了它的产品线方向、放弃产品线、合并产品线、改变产品研发和支持的重点和被其他厂商收购，那将不会再沿着之前制定的路线。

　　所以，向UCS的迁移应该包括一项严格的检查，检查对象有供应商本身、供应商稳定性、合作伙伴稳定性（如思科与VMware的UCS合作）及供应商发展线路，同时还要考虑到UCS平台不受支持这一事件的偶然性。对成本分析、测试和评估进行尽职调查，并对供应商协议进行周密分析，这样才能看到所有导致一段时间后的潜在商务问题的限制条件。

　　部署UCS

　　UCS包含服务器、存储和网络这些基础硬件，因此，部署需要将大部分（如果不是全部）子系统和UCS供应商提供的子系统进行交换。除了硬件，UCS部署还包括hypervisor和虚拟机，同时还有数据管理及数据保护工具。但是，实际的实施一般都是从LAN和SAN中的升级网络开始。

　　“我们准备了两台Cisco 4507交换机构建了一个10千兆位的基础架构来支持UCS” 联合财务服务的IT基础架构工程师Rod Gabriel说，“我们需要使用两台MDS 9124交换机来构建我们所需的SAN交换基础架构”。

　　UCS还需要准备额外的存储容量，但当UCS运用中计算能力明显提高，如促使更多的托管服务器和虚拟机在线时，这个需求会非常明显。

　　一旦准备工作做足，UCS系统（如Cisco的UCS）就能和新服务器一起部署。但实际上并不是马上就转向UCS，专家希望有一个月的时间来测试、配置并在新平台获取经验。

　　“大约一个月之后（安装），我希望在UCS之后部署新的vSphere主机，”Gabriel称。“那样，我将迁移整个虚拟基础架构到UCS，在四月底的某个时候，我们所有的现有ESX服务器也将全部迁移至UCS平台。”

　　对整个UCS平台的入门的介绍理应没什么问题，但是潜在接管者还是要考虑一些部署后的事情。第一，对很多机构来讲，保持服务器和存储的增长是一个挑战。专家报告说，UCS很好地满足了机构增长的需求，但它又重新关注在容量规划实践上。

　　但是，Heil在实施一个不同于Vmware ESX 4和Windows2008的操作系统时，遇到了一个问题，他强烈地建议在使用USC之前需要预先仔细地计划操作系统需求并测试你期望使用的版本。

　　“我们不需要为了明白如何推出像Windows 2003一样的产品而烦恼，”他说，“我们最终需要在刀片上加载windows2003，从驱动器的角度来看，这是一个挑战且需要Cisco门票来得到下一步的正确方法。”

　　其它潜在的威胁在于UCS平台需要周期性地更新代码。由于UCS是一个完整的系统，代码更新故障可能对环境产生影响。管理员在执行UCS代码更新前应该采取额外的预防措施来保护数据并且有适当的应急费用。