|So, to get a bit further into the management of the UCS in a heterogeneous environment, I went to the source and did a quick interview with Brian Schwarz, who is Product Manager focused on UCS Manager in the Server Access and Virtualization BU. Brian came to Cisco via the Nuova acquisition and prior to that he worked at Symantec/Veritas.|
Omar: So, how does Cisco UCS integrate into a customer’s existing environment--there seems to be a perception that UCS will be an island in the data center. Brian: UCS Manger runs below the operating system. There is a whole ecosystem of tools that runs operating system and above and they use host agents and traditional forms of host interaction--those will all work unmodified on top of the UCS. When we are done associating a service profile with a server and it’s attached networks, the OS essentially gets a bare metal server exactly like it sees it today. There should be no need to change any of those products in order to work with UCS servers. Having said that, that’s the base level qualification--the UCS and OS level tools won’t break each other. There is still a value in ISVs exploiting the UCS XML API. They can deliver new capabilities to our mutual customers that has not been possible with non-unified architectures. This is what BMC has done with their BladeLogic offering, but integration is not a requirement in order for their software to work.
Omar: So, to be clear, BMC is a solution, but it’s not the only solution? Brian: Absolutely
Omar: Can you give me an example of other tools out there that folks might be using? Brian: I’ll use the example of operating system provisioning. It’s a common thing that’s necessary in large data centers—and it’s not something UCS manager does--we do things below the operating system. A common way of getting operating systems onto servers is done with a PXE boot environment and PXE server--UCS Manager can enable a NIC on a server to PXE boot and any PXE boot server can respond to that PXE boot request in a very traditional fashion--there is nothing we do to modify any of that--so then they can install their operating system onto a local drive or onto a SAN LUN somewhere to do a SAN boot and those systems will work as they do today. There is an advantage of those tools to integrate with our XML API, because not only can they do their existing tasks, they can expand their capabilities to exploit service profiles--to actually be able to change the boot order in service profiles through the XML API instead of some other methods like scripts run by the host agent or something like that. Or, they can go through the process to create service profiles and associate them with pieces of hardware is they really want to do real bare metal provisioning.
Omar: So, I assume this XML schema will be published at some point? Brian: Yes, we have given out copies of the XML schema to several ISVs at this point and we have a document--a 50 page instruction manual--on how to use the API. It covers how to authenticate against to the API, how to search for certain types of objects in the schema to get the server objects or the network objects and how to filter them--say only servers that have an associated service profile. We also have a bunch of XML examples in that document that were written by one of the technical marketing engineers. The other thing we talk to people about is that our GUI uses our own XML API and it’s a JAVA based GUI--it runs in a JVM--there is a logfile that contains all the XML that goes back and forth between the GUI and the heart of UCSM, the DME--the brain that sits inside the UCS fabric interconnect. That’s a great way to learn how to use the API--you can do things in the GUI then go back and look in the logfile to see what the XML commands are and which objects are being modified. It’s a good way to learn about the schema in an applied sense.
Omar: I’ve got a data center that’s already full of blade server and I am running an enterprise manager, maybe some tools like Opsware. Say I deploy a UCS or two--can I integrate all this stuff or will I end up running some sort of split environment? Brian: There are three ways to integrate the environments. The first category are things that don’t need to be modified at all because they do things at the operating system level or above--I mentioned a couple of examples of this earlier. Most system management tools use a host agent inside the OS--that’s a big category. When you get into the second category, you are doing integration, the tools actually interact with the UCS itself, we have some industry standard APIs that should allow those tools to work out of the box as long as they comply with the standard. Two easy examples are SNMP and IPMI. There are a whole host of tools that use those interfaces. The third category outside of host agents and industry standard APIs is tools from vendors exploit the UCS Manager XML API. There are three initial companies that we mentioned at the launch on Monday 3/16: BMC BladeLogic was one that was highlighted, and we are also working with the Microsoft Systems Center team. We are also working with some of the management tools within EMC, such as EMC Control Center and EMC SMARTS – we have been working in conjunction with them for quite some time. Those were the three that were introduced on Monday--we have some others that we are working on as well in terms of qualification and potential integration too.
Omar: How about from an application perspective? Can the application reach down to the hardware level as, say, application loads change? Brian: I think we will start to see that at some point in the future. Today, applications run on operating systems. So there is a layer of indirection between the application vendor and the hardware itself. We are running non-modified x86 operating systems. Most application vendors only certify against the operating system version, so UCS can run all the applications without the need to modify any of them. There are some vendors that have a more formal certification process for the hardware and we are working with those folks--Oracle and SAP are good examples. I think, in the future, one of the things service profiles enable you to do is have the application drive the hardware more explicitly, because the application vendors know much better than anyone else when they need more hardware, and what type of resource is needed. It could be I/O bandwidth, CPU cycles, or more memory. When an app needs another node in the cluster to do more processing they can drive that into the UCS system via XML, having a pre-defined service profile that has another node pre-defined. This profile is essentially in the network—and the application or upper level system management tool can be the trigger for when that service profile gets deployed to a new blade. You could also think about the same concept with load balancers--load balancers today have the ability to add nodes dynamically to the cluster but they are not the ones to actually deploy the nodes--somebody goes in and essentially programs a new node. I think there are some interesting things that can be done here, because the UCS Manager enables a much more dynamic environment, and people are going to do some great things with that capability. Many thanks to Brian for taking time to chat with me and get my questions answered. For the final blog entry in this series, I hope to get some video shot, so you can see all this stuff in action. Stay tuned.