提到我的名字：Cisco UCS思科理事会，可能大多数人脑海中出现的还是这个画面——
机身轻薄、简洁，一扫机房杂乱的线缆。但是！除了强势的外表，我的内涵同样丰富——其实，我不仅仅是个服务器，更是一个完整的系统！
听起来似乎不容易理解，我先给大家讲个案例：
某企业有 2 个应用系统，一个是 Oracle RAC，一个是 OA。
Oracle RAC 运行在 2 台服务器上，用的是I家的高端存储，网络是数据库专用网络思科理事会；
OA 运行在 3 台服务器上，用的是 E 家的中端存储，网络是 OA 网络。
2 个网络均建立了 ACL、配置了防火墙；存储网络也都使用了 C 家的存储交换机，并配置以 wwpn 为成员的 zoning（这些部署都符合业界的最佳实践）。
为了便于大家理解，我还亲自画了清（hun）晰（luan）的架构图：
看起来是不是很（hen）亲（tou）切（da）思科理事会？
现在问题来了，我们发现数据库处理能力不足，需要添加一台服务器时，怎么办？
方案一
借服务器
从 OA 的 3 台服务器中借一台给数据库：
首先，将OA服务器关机、所有线缆拔掉，重新接入数据库的网络和存储。这意味着：拔掉原先的2条网线+2条光纤线；插入新的2条网线+2条光纤线。
其次，在数据库的SAN交换机上配置zoning，在网络交换机上加入ACL条目，再规划LUN的mapping。这还没完！
但是，完成这些过程需要至少1天，而数据库的处理高峰早已过去……
方案二
布置思科 UCS
10 分钟内完成、不动任何线缆，效率极高同时减少出错可能！没错，你需要的就是我——Cisco UCS，分分钟完成复杂需求！
要问我是如何做到的？
物理架构上依赖我的 “先天优势” ——在面世的那一刻起，UCS就将计算，网络，存储作为一个整体，将架构由原先的分离式变为融合式。服务器再多，也只需通过Unified Fabric接入网络和存储。
软件层面我有“无状态计算”——要想使这个架构真正运行起来，还要解决软件层面的问题，达到目前数据中心的所谓“软件定义计算”的高度！这就要提到UCS作为一个整体的第二个创新点：无状态计算！
无状态计算
把服务器里面的物理唯一性参数和服务器硬件本身脱离关系，单独作为一个配置文件存在。也就是说：在使用服务器时，只需修改配置文件、规定要几个网卡、网卡的 MAC 地址以及 HBA 卡机器 wwpn 即可，将这些配置文件 “附着” 在任一服务器硬件上，服务器就可以投入使用了!
理论上我已阐述完毕，现在回到最初的问题，实际操作中，我是如何实现 “借用” 的复杂需求？其实 Easy，只要如下几步就可以：
所有 5 台服务器接入 Unified Fabric，就是俗称的 “交换矩阵”；
创建 3 个 Oracle 的配置文件，规定好网络只能走接入到数据库网络交换机的特定端口；存储只能走接入到数据库 SAN 交换机的特定端口，建立 SAN Boot 的启动顺序。同理再创建 3 个 OA 的配置文件；
将 3 个 Oracle RAC 的配置文件 “附着” 到 3 台服务器上，在数据库网络交换机里配置 ACL，在数据库 SAN 交换机里配置 zonging。在 I 家存储上划分启动 LUN 和数据 LUN，安装 OS，安装数据库。完成后得到一个 3 节点的 Oracle RAC；
将其中任意一台服务器关机，将其上的 “配置文件” 拿走备用。这时就有 2 台 Oracle RAC 和 3 台 “无状态” 的服务器；
将 OA 的 3 个配置文件 “附着” 到剩下的 3 台服务器上，同样配置 ACL，zoning，boot LUN 和数据 LUN，安装 OS 和 OA 软件；
完成！这时，你有 2 台 Oracle RAC 服务器，3 台OA 服务器，各自接入自己的网络和存储，开始正常工作；如果 Oracle RAC 需要 “临时” 借用一台服务器，只要将任意 OA 服务器的配置文件拿掉，将备用的 Oracle 配置文件 “附着” 上去即可。服务器重启，就会再现第 3 步的场景，实现 3 节点的 Oracle RAC。你当然可以再 “临时” 借台服务器，实现第 4 个节点的 Oracle RAC；
如果要将服务器还回去，只要将前 6 步反着做一遍即可。
整个过程，无需在前后奔走在服务器之间，无需插拔一根线缆，只要网络能通，甚至在家中就能处理这种紧急情况！
怎么样，听完我的自述，现在明白“Cisco UCS不仅仅是服务器，更是一个完整的系统”其中的奥秘了吧！
以服务器的规格，打造系统级性能
