Automatic Service Profile Fail-Over

[ikent]

One of the great things about UCS Manager is that you have complete access to the Management Information Tree (configuration management database) for a UCS domain that can scale to 160 servers.  Integrators can use the client integration technology of their choice to configure, manage and monitor a UCS domain.  This allows integrators to focus on the problem they wish to solve, rather than the intricacies of a proprietary interface.  A great example of this ease of integration is the automatic service profile fail-over script that I demonstrated at Cisco Live.    You can download the sample code from here:  MonitorSp.

The script periodically polls the UCS Manager to determine the health of a named service profile.  If the physical server associated with the service profile has a fatal fault (based on a csv file of fatal faults), the script will decommission the server.  When a server is decommissioned and the service profile is associated with a compute pool, UCS Manager will automatically associate the service profile with another available server.    It is quite impressive that this advanced functionality is based on only 5 PowerTool cmdlets:

Get Service Profile Hierarchy:

$lSpMos = (Get-UcsServiceProfile -dn $aInSpDn -hierarchy)     

Get Compute Hierarchy:

$lBladeMos = (Get-UcsManagedObject -dn $aInDn -hierarchy)


Delete our requirement: 

Get-UcsServiceProfile -dn $aInSpDn | Disconnect-UcsServiceProfile -force

Decomission our server:

Set-UcsManagedObject -force -XmlTag computeBlade -PropertyMap @{dn = $lPnDn ; lc= "decommission"}

Associate a service profile with a server:

Get-UcsServiceProfile -dn $aInSpDn | Associate-UcsServiceProfile -ServerPoolName $lPoolName -force

This script illustrates some real UCS product differentiators:

• UCS Manager can be used to quickly repurpose hardware, expand computing capacity, and replace failed hardware resources;
• Service profiles can assure that hardware configuration is identical right down to the bios settings and firmware versions;
• UCS faults can be easily queried and are automatically correlated (faults are children of the affected object);
• Server pools provide a means to identity migration targets ahead of time; The personality of the server is applied at association time.

Please note that this script was created for illustrative purposes only (so, run it on your UCS Platform Emulator and not your production network!) Creating a robust and fault tolerant UCS deployment is an involed problem and will often include:

• Monitoring server health - snmp, call-home, querying faults and statistics;        
• Integration with software stack - both application and process monitoring;
• Safety mechanisms: throttling migration, integration with existing monitoring processes (to prevent compounding the problem);

Enjoy  Ike

[kshitij_korde]

Hi,

Is "decommission"(ing) the server [compute-blade] the only way to trigger automatic failover of the Service Profile.

Can I select any of the "available" servers from the Server Pool and then take a decision of the compute-blade on which I would want to migrate my SP?

i.e

a) Find Available Servers from the corresponding Server Pool.

b) Select Available Server.

c) Dissociate the Service Profile from the current faulted compute blade.

d) Associate the Service Profile to the selected server.

Nonetheless, UCS Manager possesses lot more intelligence and can make a correct decision as to which would be the optimum compute blade for Service Profie Migration. ( is this correct ? )

Can I achieve the same result using the below perl lines..

$cmd_curl = " curl -H \"Content-Type: text/xml\" -N -s -d ";

$server_dn = "sys/chassis-1/blade-7";

$url = " http://XXX.XX.ABC.YY/nuova ";

$flag_inHierarchical = "true";

Command : [$cmd_configConfMo_computeBlade = $cmd_curl."'<configConfMo cookie=\"$cookie\" inHierarchical=$flag_inHierarchical dn=\"$server_dn\"><inConfig><computeBlade lc=\"decommission\"></computeBlade></inConfig></configConfMo>'".$url;]

[ikent]

Hi Kshitij

De-commisioning the server will cause UCSM to automatically select another server from the pool to associate with the service profile. The dis-associated server will not be used by any other service profiles.  You could simply decommission the server and achieve a similar result.

In my script, I dis-associate and re-association the service profile with the pool since it will be a little bit quicker than waiting on UCSM to select another server for me (since the client is doing the decomission, why not rebind with the pool to speed things up?)

Setting the lc (life-cycle) to "decomssion" is the correct way to decommission a server (so your xml looks correct - although I didn't test it).

Many of our customers use compute pools to group together similar resources based on their intended use.  For example, you could create a pool of servers intended to be used as production hypervisors. The pool could be populated with servers that meet the user's criteria - for example a certain amount of memory, type of adapter or physical location of the server.  When a service profile is associated with a pool, the user typically does not care which server is chosen since they know it is coming from a pool that was constructed for a specific purpose. Of course, you do not have to use pools (UCSM is very flexible) and you could manually associate with the server of your choice.  The best approach will depend on your target environment.

As a client integrator, you do have access to the  UCSM MIT (Management Information Tree or configuration management database)  - which means that you have access to the same information that UCSM uses to make its configuration decisions (like selecting a server from a pool)

Hope this helps.

Cheers

Ike

[kshitij_korde]

thanks Ike for your explanation !

That helps.

Best Regards,

Kshitij.