Comments on: Blades and HA / Cluster design http://www.yellow-bricks.com/2009/02/09/blades-and-ha-cluster-design/ Building blocks for virtualization... Mon, 15 Mar 2010 05:56:52 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Hugo http://www.yellow-bricks.com/2009/02/09/blades-and-ha-cluster-design/comment-page-1/#comment-2617 Hugo Thu, 26 Feb 2009 11:12:38 +0000 http://www.yellow-bricks.com/?p=1820#comment-2617 Thanks for the information, this is something that I have always put as a very small risk in a blade deployment with large clusters. The majority of my designs and deployments have used c7000, with two OA modules, 10 fans and 6 power supplies, multiple virtual connect or Cisco and Brocade modules connected to different network stacks and fabrics and power distributions, so my recommendation is: mitigate the risk by reducing the possibilities of failure to the chassis'. Thanks for the information, this is something that I have always put as a very small risk in a blade deployment with large clusters. The majority of my designs and deployments have used c7000, with two OA modules, 10 fans and 6 power supplies, multiple virtual connect or Cisco and Brocade modules connected to different network stacks and fabrics and power distributions, so my recommendation is: mitigate the risk by reducing the possibilities of failure to the chassis’.

]]> By: bcool http://www.yellow-bricks.com/2009/02/09/blades-and-ha-cluster-design/comment-page-1/#comment-2616 bcool Thu, 26 Feb 2009 07:19:17 +0000 http://www.yellow-bricks.com/?p=1820#comment-2616 I think N+1 could be the solution. max hosts in a HA cluster now is 32 and running 16 hosts in 2 chassis is the worst case scenario. So why not have 17 primaries in one cluster? Another thought is to elect the primaries across the hosts that respond slowest and fastest to the Heartbeat. My assumption is that if all primaries are in the same chassis, they will have similar fast response time on the heartbeat, if they are across the chassis, those hosts will respond slower than the one on the same chassis. I think N+1 could be the solution. max hosts in a HA cluster now is 32 and running 16 hosts in 2 chassis is the worst case scenario. So why not have 17 primaries in one cluster?
Another thought is to elect the primaries across the hosts that respond slowest and fastest to the Heartbeat. My assumption is that if all primaries are in the same chassis, they will have similar fast response time on the heartbeat, if they are across the chassis, those hosts will respond slower than the one on the same chassis.

]]> By: Duncan http://www.yellow-bricks.com/2009/02/09/blades-and-ha-cluster-design/comment-page-1/#comment-2491 Duncan Mon, 16 Feb 2009 11:47:25 +0000 http://www.yellow-bricks.com/?p=1820#comment-2491 I think that information is still under NDA. I think that information is still under NDA.

]]> By: gboskin http://www.yellow-bricks.com/2009/02/09/blades-and-ha-cluster-design/comment-page-1/#comment-2489 gboskin Mon, 16 Feb 2009 11:13:52 +0000 http://www.yellow-bricks.com/?p=1820#comment-2489 Does anyone know if the number of allowed primary node would be increased in ESX4?? Does anyone know if the number of allowed primary node would be increased in ESX4??

]]> By: superted666 http://www.yellow-bricks.com/2009/02/09/blades-and-ha-cluster-design/comment-page-1/#comment-2435 superted666 Wed, 11 Feb 2009 10:28:53 +0000 http://www.yellow-bricks.com/?p=1820#comment-2435 Very interesting, However it feels we are addressing a short fall. Ideally vmware should be able to be updated to be 'blade aware' so administrators can plan around the unique challenges introduced by blade servers. Very interesting,
However it feels we are addressing a short fall.

Ideally vmware should be able to be updated to be ‘blade aware’ so administrators can plan around the unique challenges introduced by blade servers.

]]> By: Duncan http://www.yellow-bricks.com/2009/02/09/blades-and-ha-cluster-design/comment-page-1/#comment-2431 Duncan Wed, 11 Feb 2009 08:12:57 +0000 http://www.yellow-bricks.com/?p=1820#comment-2431 Euuhm JustMe, Scott was talking about a designated primary node for Blade Environments... Your solution won't cover the fact that an entire chassis can go down. When a re-election is forced it will probably recollect the state and don't know it needs to restart certain vm's. So for a blade chassis you still want to designate primaries. I would love to see it like this: bladechassis01 , bladechassis02 “das.preferredprimary.01” = bladec01-h01 bladec01-h02 bladec01-h03 “das.preferredprimary.02” = bladec02-h01 bladec02-h02 bladec02-h03 So you can pick primaries for both chassis and HA does the rest. maybe even just say you've got blade chassis and divide the cluster up in two chuncks just for administration and primary purpose, would also make a nice view in vCenter I guess. Euuhm JustMe, Scott was talking about a designated primary node for Blade Environments… Your solution won’t cover the fact that an entire chassis can go down. When a re-election is forced it will probably recollect the state and don’t know it needs to restart certain vm’s. So for a blade chassis you still want to designate primaries.

I would love to see it like this:
bladechassis01 , bladechassis02
“das.preferredprimary.01” = bladec01-h01 bladec01-h02 bladec01-h03
“das.preferredprimary.02” = bladec02-h01 bladec02-h02 bladec02-h03

So you can pick primaries for both chassis and HA does the rest. maybe even just say you’ve got blade chassis and divide the cluster up in two chuncks just for administration and primary purpose, would also make a nice view in vCenter I guess.

]]> By: justme http://www.yellow-bricks.com/2009/02/09/blades-and-ha-cluster-design/comment-page-1/#comment-2429 justme Wed, 11 Feb 2009 05:21:55 +0000 http://www.yellow-bricks.com/?p=1820#comment-2429 @ Gabrie van Zanten.... I was thinking the same thing.... Scotts solution is what HA does today! As always the another option would be for the secondary hostss to monitor the primany hosts and if none are responding, force an election for 5 new primany hosts to take over. This way it could be 'automatic' and out of the box. @ Gabrie van Zanten…. I was thinking the same thing…. Scotts solution is what HA does today!

As always the another option would be for the secondary hostss to monitor the primany hosts and if none are responding, force an election for 5 new primany hosts to take over. This way it could be ‘automatic’ and out of the box.

]]> By: matbac http://www.yellow-bricks.com/2009/02/09/blades-and-ha-cluster-design/comment-page-1/#comment-2408 matbac Tue, 10 Feb 2009 18:39:54 +0000 http://www.yellow-bricks.com/?p=1820#comment-2408 Great information! The HA feature do need some planning before implementing. Just to give another aspect of the discussion regarding the idea of spreading the hosts between different Enclosures: In my eyes we would also benefit the performance regading I/O by spreding the hosts. At least our configuration includes a SAN switch in every Enclosure with a limited number of uplinks to the SAN backbone. By Spreding the hosts between the Enclosures we will ensure a better SAN connectivity for the other Servers in the same Enclosure, Yepp we still have some physical servers as well. Putting to many Hosts in the same enclosure would affect the bandwith in a bad way. Great information! The HA feature do need some planning before implementing.

Just to give another aspect of the discussion regarding the idea of spreading the hosts between different Enclosures:
In my eyes we would also benefit the performance regading I/O by spreding the hosts.
At least our configuration includes a SAN switch in every Enclosure with a limited number of uplinks to the SAN backbone.
By Spreding the hosts between the Enclosures we will ensure a better SAN connectivity for the other Servers in the same Enclosure, Yepp we still have some physical servers as well. Putting to many Hosts in the same enclosure would affect the bandwith in a bad way.

]]> By: pironet http://www.yellow-bricks.com/2009/02/09/blades-and-ha-cluster-design/comment-page-1/#comment-2407 pironet Tue, 10 Feb 2009 18:17:30 +0000 http://www.yellow-bricks.com/?p=1820#comment-2407 Great article! Keep on sharing such info. I've double checked our environment which consist of 32 hosts spread over 5 HP C7000 enclosures and fortunately primaries are not grouped on the same enclosure... Anyway, as I don't want to split my unique big VMware cluster into small pieces to accommodate this design flaw I guess I will have to scheduled a cat /var/log/vmware/aam/aam_config_util_listnodes.log every day or so... Operators will be happy, I can hear that from here :) Great article! Keep on sharing such info.

I’ve double checked our environment which consist of 32 hosts spread over 5 HP C7000 enclosures and fortunately primaries are not grouped on the same enclosure…

Anyway, as I don’t want to split my unique big VMware cluster into small pieces to accommodate this design flaw I guess I will have to scheduled a cat /var/log/vmware/aam/aam_config_util_listnodes.log every day or so…

Operators will be happy, I can hear that from here :)

]]> By: yoman http://www.yellow-bricks.com/2009/02/09/blades-and-ha-cluster-design/comment-page-1/#comment-2406 yoman Tue, 10 Feb 2009 17:21:00 +0000 http://www.yellow-bricks.com/?p=1820#comment-2406 could you share what kind of manufacturer the enclosure that failed was from? could you share what kind of manufacturer the enclosure that failed was from?

]]>