cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1686
Views
0
Helpful
4
Replies

Service profile and server pool behaviour

mehrantgs
Level 1
Level 1

Hi

I am new to Cisco UCS product. we have bought a Cisco UCS 5108 with 4 blades and 2 FIs. now i am implementing it.

Cabling is finished and i have all connectivities established to storage and network.

now i am going to create a service profile and assign it to a server pool but i have got really confused in deal of it.

after i created a service profile and assigned it to manual/automatically created server pool, i saw mounted OS just installed on one physical blade and not all of them, and when i look at server association, the service profile just had been associated with one of them

now i have a question:

regardless of how i selected a server pool(Manual or automated), i expected each blade server be an option for my provided service profile (considering all blade servers have simultaneous specs) and my given iso image should be installed on all of them, but what i see there,is completely confusing.

as i said, service profile associated with a pool just shows one of blades and consumes all resource of selected pool

i dont know what will happen if that blade fails

i hope my question is clear :-|

2 Accepted Solutions

Accepted Solutions

Kirk J
Cisco Employee
Cisco Employee

Greetings.

Server pools are normally used for fairly large environments.

If you have just a single chassis or two, the added complexity of the server pools is probably not going to be beneficial in your environment.

Best practices would involve creating an updating service profile template, then generating a service profile from the template for each of the blades.

Blades (and UCSM managed C series servers) have a one to one relationship with service profiles.

In the event you do have hardware failure, you are still going to have to decomission the existing blade and allow the service profile to re-associate with another member of the pool.

In small environments, it is generally easier to just manually assign your service profiles to individual blades without pools.

My 2 cents.

 

Thanks,

Kirk...

View solution in original post

If you are using boot from san (iSCSI, FC), then you can easily reassign a service profile to a different blade as the service profile has all the unique IDs that transfer with it (i.e. uuid, wwpn, mac, iscsi iqn, etc)

If you can virtualize most of your OS/applications, then generally a hyper-visor with some advanced features can take care of the HA/fail-over, vmotion, load balancing, etc.  Examples would be VMware with HA, DRS, storage DRS, Network IO control, etc.

Someone else in these forums recently asked a somewhat similar question about automating blade hardware failover in conjuction with server pools, and it gets complicated when it comes to having something like the UCSM trying to decide all the possible scenarios that would trigger automated decomissioning of a blade, reassigning of same service profile to other hardware.

This would really require some additional orchestration component (i.e. UCS Director) on top making those decisions based on a number of test/fail conditions.

 

In regards to local install media, that can easily be transferred (along with service profile) in the case of an RMA of a blade, or if you want to move to another similar server.  Obviously, boot from san removes this concern, but not everyone uses that.

 

Hope this helps,

Kirk...

View solution in original post

4 Replies 4

Kirk J
Cisco Employee
Cisco Employee

Greetings.

Server pools are normally used for fairly large environments.

If you have just a single chassis or two, the added complexity of the server pools is probably not going to be beneficial in your environment.

Best practices would involve creating an updating service profile template, then generating a service profile from the template for each of the blades.

Blades (and UCSM managed C series servers) have a one to one relationship with service profiles.

In the event you do have hardware failure, you are still going to have to decomission the existing blade and allow the service profile to re-associate with another member of the pool.

In small environments, it is generally easier to just manually assign your service profiles to individual blades without pools.

My 2 cents.

 

Thanks,

Kirk...

Thanks to your reply kirk

But that was bad news to me!

I thought server pools, cluster all resources of their subset blades and i can devide it to some desired part (smaller or gereater than a single blade) and service profile is responsible to provide my requested hardware, 

Now according to your reply if a blade fails, a service profile can assign to another available resources manually (after decomissoining failed blade) but what will happen to locally installed OS? Does it should install again or i should detach it's disk/flash and attach it to new blade? 

 

If you are using boot from san (iSCSI, FC), then you can easily reassign a service profile to a different blade as the service profile has all the unique IDs that transfer with it (i.e. uuid, wwpn, mac, iscsi iqn, etc)

If you can virtualize most of your OS/applications, then generally a hyper-visor with some advanced features can take care of the HA/fail-over, vmotion, load balancing, etc.  Examples would be VMware with HA, DRS, storage DRS, Network IO control, etc.

Someone else in these forums recently asked a somewhat similar question about automating blade hardware failover in conjuction with server pools, and it gets complicated when it comes to having something like the UCSM trying to decide all the possible scenarios that would trigger automated decomissioning of a blade, reassigning of same service profile to other hardware.

This would really require some additional orchestration component (i.e. UCS Director) on top making those decisions based on a number of test/fail conditions.

 

In regards to local install media, that can easily be transferred (along with service profile) in the case of an RMA of a blade, or if you want to move to another similar server.  Obviously, boot from san removes this concern, but not everyone uses that.

 

Hope this helps,

Kirk...

Thanks buddy

Review Cisco Networking for a $25 gift card

Review Cisco Networking for a $25 gift card