I see; is there any advantage of creating a 8-Node cluster in SQL server then?

The only thing I can think of is if we go 2-node configuration with the 8
servers, we have 4 severs doing nothing. Well they are there for the HA; but
I think we decided the 8-node configuration to better use the hardware.

Maybe a 3 node configuration will be enough with (active-active-passive)?
So it doesn't seem like as big of a waste? What you think?

Thanks for the comments

--
Mohit K. Gupta
B.Sc. CS, Minor Japanese
MCTS: SQL Server 2005
http://sqllearnings.blogspot.com/


"Linchi Shea" wrote:

With an 8-node cluster, you may save some money on having fewer servers doing
nothing. But you have increased complexity and have to deal with the
scenarios where multiple instances fail to the same node. The issue here is
HA, not load balancing. As such, it's best to consider, for instance, a
2-node failover cluster as a single server that has built-in redundancy for
your database. Just as you should use multiple HBAs and multiple NICs in a
server, and never consider the extra NICs/HBAs as doing nothing, it's simply
the cost of doing business if the business requires it.

Linchi

"Mohit K. Gupta" wrote:

With an 8-node cluster, you may save some money on having fewer servers doing
nothing. But you have increased complexity and have to deal with the
scenarios where multiple instances fail to the same node. The issue here is
HA, not load balancing. As such, it's best to consider, for instance, a
2-node failover cluster as a single server that has built-in redundancy for
your database. Just as you should use multiple HBAs and multiple NICs in a
server, and never consider the extra NICs/HBAs as doing nothing, it's simply
the cost of doing business if the business requires it.

Linchi

"Mohit K. Gupta" wrote:

With an 8-node cluster, you may save some money on having fewer servers doing
nothing. But you have increased complexity and have to deal with the
scenarios where multiple instances fail to the same node. The issue here is
HA, not load balancing. As such, it's best to consider, for instance, a
2-node failover cluster as a single server that has built-in redundancy for
your database. Just as you should use multiple HBAs and multiple NICs in a
server, and never consider the extra NICs/HBAs as doing nothing, it's simply
the cost of doing business if the business requires it.

Linchi

"Mohit K. Gupta" wrote:

With an 8-node cluster, you may save some money on having fewer servers doing
nothing. But you have increased complexity and have to deal with the
scenarios where multiple instances fail to the same node. The issue here is
HA, not load balancing. As such, it's best to consider, for instance, a
2-node failover cluster as a single server that has built-in redundancy for
your database. Just as you should use multiple HBAs and multiple NICs in a
server, and never consider the extra NICs/HBAs as doing nothing, it's simply
the cost of doing business if the business requires it.

Linchi

"Mohit K. Gupta" wrote:

With an 8-node cluster, you may save some money on having fewer servers doing
nothing. But you have increased complexity and have to deal with the
scenarios where multiple instances fail to the same node. The issue here is
HA, not load balancing. As such, it's best to consider, for instance, a
2-node failover cluster as a single server that has built-in redundancy for
your database. Just as you should use multiple HBAs and multiple NICs in a
server, and never consider the extra NICs/HBAs as doing nothing, it's simply
the cost of doing business if the business requires it.

Linchi

"Mohit K. Gupta" wrote:

With an 8-node cluster, you may save some money on having fewer servers doing
nothing. But you have increased complexity and have to deal with the
scenarios where multiple instances fail to the same node. The issue here is
HA, not load balancing. As such, it's best to consider, for instance, a
2-node failover cluster as a single server that has built-in redundancy for
your database. Just as you should use multiple HBAs and multiple NICs in a
server, and never consider the extra NICs/HBAs as doing nothing, it's simply
the cost of doing business if the business requires it.

Linchi

"Mohit K. Gupta" wrote:

With an 8-node cluster, you may save some money on having fewer servers doing
nothing. But you have increased complexity and have to deal with the
scenarios where multiple instances fail to the same node. The issue here is
HA, not load balancing. As such, it's best to consider, for instance, a
2-node failover cluster as a single server that has built-in redundancy for
your database. Just as you should use multiple HBAs and multiple NICs in a
server, and never consider the extra NICs/HBAs as doing nothing, it's simply
the cost of doing business if the business requires it.

Linchi

"Mohit K. Gupta" wrote:

With an 8-node cluster, you may save some money on having fewer servers doing
nothing. But you have increased complexity and have to deal with the
scenarios where multiple instances fail to the same node. The issue here is
HA, not load balancing. As such, it's best to consider, for instance, a
2-node failover cluster as a single server that has built-in redundancy for
your database. Just as you should use multiple HBAs and multiple NICs in a
server, and never consider the extra NICs/HBAs as doing nothing, it's simply
the cost of doing business if the business requires it.

Linchi

"Mohit K. Gupta" wrote:

With an 8-node cluster, you may save some money on having fewer servers doing
nothing. But you have increased complexity and have to deal with the
scenarios where multiple instances fail to the same node. The issue here is
HA, not load balancing. As such, it's best to consider, for instance, a
2-node failover cluster as a single server that has built-in redundancy for
your database. Just as you should use multiple HBAs and multiple NICs in a
server, and never consider the extra NICs/HBAs as doing nothing, it's simply
the cost of doing business if the business requires it.

Linchi

"Mohit K. Gupta" wrote: