Differentiating virtual SQL names and physical servers

[Raymond Kim]

Greetings . . .

Is there any way for SIM to recognize the difference between a virtual SQL server name that resides on a cluster, and the physical server on which it resides?

Here's the deal: I utilize our SIM back-end database to maintain records on a server inventory database that I maintain. The problem is that we have a number of virtual SQL names that are picked up by SIM.

Example: let's say I have virtual SQL server "VSQL" that resides on a DL380 called "SQLServ." If I looked at these two records in SIM (or in my DB), I'd think that I was looking at two physical servers (not knowing one of them is virtual), and I'd be wondering what's wrong because they have the same serial number. Also, if I ran an audit of these records, it would not show one physical and one virtual server, it would show two physical servers.

Can anyone tell me if SIM can provide a way around this?

[Rob Buxton]

Not too sure what you mean by virtual SQL names.
SIM can differentiate between a physical and virtual server.
In both cases the System Type is listed as Server, but the Product Name should be different. On the physical you should see something like Proliant DL380 G4 whereas on our VMWaere ESX Guests we see VMWare Virtual Platform. I'm not sure what you'd see with MS Virtual Servers. The System Sub-Type should also show a difference between a virtual and physical server.

If you have VMM in HPSIM then it does enhance the visibility of the Virtual Infrastructure.

[Raymond Kim]

These machines have nothing to do with VMWare, so it doesn't apply here.

I'm not the administrator for these, so I might hack the description here, but here's how it was described to me.

The nodes in question are SQL cluster servers. One of our engineers told me that each cluster has four names associated with it: one name each for each of the two physical hosts, a name for the cluster, and a SQL virtual name.

What SIM is doing is it's picking up the SQL virtual name and reporting it as though it was a physical server. Hence the confusion.

Hope that clarifies it a bit.

[Raymond Kim]

After posting my last message, it just occurred to me what SIM is doing.

SIM is picking up all four names on the cluster. The two physical hosts aren't a problem; they're being reported as they should. The cluster name isn't a problem, because SIM differentiates it by defining the product type (under the ProductTypeStr field in the Devices database table) as a cluster.

The problem is with the fourth virtual cluster name. SIM picks it up and identifies it as being a "server" product type, along with all the hardware characteristics of its host. There's no way to identify it as a virtual SQL cluster name.

I suspect the way to go around this would be to configure something in the cluster itself.

Thoughts?

[Rob Buxton]

That "virtual" word can mean so many things depending on the context...

[Raymond Kim]

I hear you.

Would we be better off configuring something in SIM, or should I look into playing around with the cluster configuration?

[Greg Bates]

I have gone through many different configurations in SIM to get clusters to show up right. This is what I have right now.

Step 1. Make sure that clusters are being monitored on the HP agents in all the cluster servers. That way SIM can see that they are clusers. It will monitor the cluster resources and associate the physical servers with cluster group name.

This is as far as I have found that SIM can understand clusters. Once you start adding additional IP address that can be associated with more than one physical server, SIM gets confused.

I make sure that the cluster group name and all the physical servers are discovered in SIM, then I exclude all IP addresses associated with the cluster from the autodiscovery process. The autodiscovery process will tend to start associating IP addresses, with one server and eventually will forget about the other server(s). The virtual IP's, and server names do not need to be monitored directly by SIM.

[Raymond Kim]

Sounds reasonable. Let me pass this along to our engineers, and see what they say.