Budget Clustering Standard Edition.

#1

I am aware that the standard edition does not 'include'
fail over clustering.

I have read this newgroup on items containing the
budget / standard edition clustering.

I get the strong impression that 'budget clustering' is
strongly advised against.
WHY ?

Thanks for your attention,
ben brugman

Elaboration :

We want to have two options :
1. Standard edition.
2. Enterprise / San / Fail over.

Offcourse for high availability, you have to pay and
go for the second solution.

But to make the first solution as good as possible,
we are thinking in lines of the 'suggested' budget
fail over clustering.

So we plan :
Two servers with internal OS / SQL-server software.
Two Raid storage units which will be host based mirrored.
(So each file is stored four times).
Two locations, one for each server, storage unit.

If a part of the storage fails, there is plenty of redundancy.
But if a server fails we plan to do a fail over to the 'second'
machine, just reattaching the disks. (With MSA management
software).
We want the maximum amount of availability which can be
obtained with using the standard edition.
If that is not enough management can choose for the second
configuration, which will be more expensive.

We do not want to make the choice but supply the management
with enough 'numbers' and arguments to make a sollid choice on
the configuration.

#2

1) Standard Edition is not supported
2) No Cluster resources will be created, thus adding tons of work during the
install
3) It is a violation of EULA
4) It will not failover properly
5) See number 1

Cheers,

Rod

"ben brugman" <ben (AT) niethier (DOT) nl> wrote

Quote:

I am aware that the standard edition does not 'include'
fail over clustering.

I have read this newgroup on items containing the
budget / standard edition clustering.

I get the strong impression that 'budget clustering' is
strongly advised against.
WHY ?

Thanks for your attention,
ben brugman

Elaboration :

We want to have two options :
1. Standard edition.
2. Enterprise / San / Fail over.

Offcourse for high availability, you have to pay and
go for the second solution.

But to make the first solution as good as possible,
we are thinking in lines of the 'suggested' budget
fail over clustering.

So we plan :
Two servers with internal OS / SQL-server software.
Two Raid storage units which will be host based mirrored.
(So each file is stored four times).
Two locations, one for each server, storage unit.

If a part of the storage fails, there is plenty of redundancy.
But if a server fails we plan to do a fail over to the 'second'
machine, just reattaching the disks. (With MSA management
software).
We want the maximum amount of availability which can be
obtained with using the standard edition.
If that is not enough management can choose for the second
configuration, which will be more expensive.

We do not want to make the choice but supply the management
with enough 'numbers' and arguments to make a sollid choice on
the configuration.

#3

He is asking about a low-cost cluster. Using Standard Edition instead of
Enterprise.

Cheers,

Rod

"DaveK" <anonymous (AT) discussions (DOT) microsoft.com> wrote

Quote:

Sorry could you explain what "budget clustering" is? Are you talking about
3rd party software?

Thanks
DaveK

http://www.sqlporn.co.uk

#4

First of all thanks for your time.
I would like to go over the points one at the time.

In my original mail I did (on purpose) elaborate, but
only at the end of the message.

"Rodney R. Fournier [MVP]" <rod (AT) die (DOT) spam.die.nw-america.com> wrote in
message news:uonKad#REHA.3708 (AT) TK2MSFTNGP10 (DOT) phx.gbl...

Quote:

1) Standard Edition is not supported

We do not intend to automatically fail over, but doing the fail over by
'hand',
in this group there are a lot of advices how to do this.

Quote:

2) No Cluster resources will be created, thus adding tons of work during
the
install
We need an extra machine and an extra installation of OS/SQL-server and

of course the setting up of the hardware and hardware management.
But I doubt if 'real' clustering has less work.

Quote:

3) It is a violation of EULA
I do not see a violation of the EULA, with this set up.

(But then EULA's are so complex that allthough I do understand them,
this is not totaly 100 %).

Quote:

4) It will not failover properly
I think by hand it wil. If this is not true please point out why.

Quote:

5) See number 1
See number one.

As said we will do the switch manually, also switching the
application servers. (By newly resolving the name and reconnecting).
So the fail over is manually, but we do not need to restore and recover.
So there is less availability than for 'real' clustering, but more than
if a (backup) restore recover is done in case of a server failure.

Any new insights ?

ben brugman.

Quote:

Cheers,

Rod

"ben brugman" <ben (AT) niethier (DOT) nl> wrote in message
news:%23kCvdN%23REHA.1340 (AT) TK2MSFTNGP12 (DOT) phx.gbl...
I am aware that the standard edition does not 'include'
fail over clustering.

I have read this newgroup on items containing the
budget / standard edition clustering.

I get the strong impression that 'budget clustering' is
strongly advised against.
WHY ?

Thanks for your attention,
ben brugman

Elaboration :

We want to have two options :
1. Standard edition.
2. Enterprise / San / Fail over.

Offcourse for high availability, you have to pay and
go for the second solution.

But to make the first solution as good as possible,
we are thinking in lines of the 'suggested' budget
fail over clustering.

So we plan :
Two servers with internal OS / SQL-server software.
Two Raid storage units which will be host based mirrored.
(So each file is stored four times).
Two locations, one for each server, storage unit.

If a part of the storage fails, there is plenty of redundancy.
But if a server fails we plan to do a fail over to the 'second'
machine, just reattaching the disks. (With MSA management
software).
We want the maximum amount of availability which can be
obtained with using the standard edition.
If that is not enough management can choose for the second
configuration, which will be more expensive.

We do not want to make the choice but supply the management
with enough 'numbers' and arguments to make a sollid choice on
the configuration.

#5

"Rodney R. Fournier [MVP]" <rod (AT) die (DOT) spam.die.nw-america.com> wrote in
message news:OskDg1#REHA.3660 (AT) tk2msftngp13 (DOT) phx.gbl...

Quote:

He is asking about a low-cost cluster. Using Standard Edition instead of
Enterprise.

Cheers,

Rod

"DaveK" <anonymous (AT) discussions (DOT) microsoft.com> wrote in message
news:31F9BABD-78FB-4174-B831-9E1B0C3D3093 (AT) microsoft (DOT) com...
Sorry could you explain what "budget clustering" is? Are you talking
about
3rd party software?

Thanks
DaveK

http://www.sqlporn.co.uk

I do not see the 'original message of DaveK, so I'll attach my anwser here.

By budget clustering, different people have different meanings.
What I did understand and mean by budget clustering is :
Using the standard edition SQL-server.
Setting up a second machine similar to the first machine.
If the first machine fails, attach the 'database' disks to the
second machine.
And start up SQL-server on the second machine.
Because this machine has a different name and ip address the
applications have to reconnect after a new name resolve.
(So this has to be changed as well).
Of course here we are missing a lot of the advantages of the
'real' clustering mechanism where 'everything' goed automatic.
(failure detection, switching over, name resolving and if the
application is cluster aware the reconnection).
But the advantage of this way creating high availability is that
you do not have to restore and recover a database in case of
a server failure.
So in my this 'might' give a higher availability then using the
backup and restore route.

Remarks :
Offcourse have you datastorage redundant. So that a storage failure
(disk or system) can be handled.
A server failure will be a rare event (using servers which have redundancy
in power supply, memory etc.). So during a server failure you might lose
some availability time.
But losing say an hour every two years because of a server failure, or
paying for the more expensive 'real fail over' capable system, is something
that has to be decided by the management.
Off course there will also be down time during regular upgrades of mainly
software and rearely hardware, but that can be planned.
Although we run a 7 x 24 hours shop, planned downtime is not to disruptive.

With my question, I hope to get some insight in how realistic this set up
is. I would like to form an opinion based on more than : "That won't work"
or "That is not supported" or "That is not allowed".

ben brugman

#6

I think you want to look at creating a SQL Standby Server, which is
supported and very easy to do. Nothing to do with clustering, but neither
does your solution.

Cheers,

Rod
"ben brugman" <ben (AT) niethier (DOT) nl> wrote

Quote:

First of all thanks for your time.
I would like to go over the points one at the time.

In my original mail I did (on purpose) elaborate, but
only at the end of the message.

"Rodney R. Fournier [MVP]" <rod (AT) die (DOT) spam.die.nw-america.com> wrote in
message news:uonKad#REHA.3708 (AT) TK2MSFTNGP10 (DOT) phx.gbl...
1) Standard Edition is not supported

We do not intend to automatically fail over, but doing the fail over by
'hand',
in this group there are a lot of advices how to do this.

2) No Cluster resources will be created, thus adding tons of work during
the
install
We need an extra machine and an extra installation of OS/SQL-server and
of course the setting up of the hardware and hardware management.
But I doubt if 'real' clustering has less work.

3) It is a violation of EULA
I do not see a violation of the EULA, with this set up.
(But then EULA's are so complex that allthough I do understand them,
this is not totaly 100 %).

4) It will not failover properly
I think by hand it wil. If this is not true please point out why.

5) See number 1
See number one.

As said we will do the switch manually, also switching the
application servers. (By newly resolving the name and reconnecting).
So the fail over is manually, but we do not need to restore and recover.
So there is less availability than for 'real' clustering, but more than
if a (backup) restore recover is done in case of a server failure.

Any new insights ?

ben brugman.

Cheers,

Rod

"ben brugman" <ben (AT) niethier (DOT) nl> wrote in message
news:%23kCvdN%23REHA.1340 (AT) TK2MSFTNGP12 (DOT) phx.gbl...
I am aware that the standard edition does not 'include'
fail over clustering.

I have read this newgroup on items containing the
budget / standard edition clustering.

I get the strong impression that 'budget clustering' is
strongly advised against.
WHY ?

Thanks for your attention,
ben brugman

Elaboration :

We want to have two options :
1. Standard edition.
2. Enterprise / San / Fail over.

Offcourse for high availability, you have to pay and
go for the second solution.

But to make the first solution as good as possible,
we are thinking in lines of the 'suggested' budget
fail over clustering.

So we plan :
Two servers with internal OS / SQL-server software.
Two Raid storage units which will be host based mirrored.
(So each file is stored four times).
Two locations, one for each server, storage unit.

If a part of the storage fails, there is plenty of redundancy.
But if a server fails we plan to do a fail over to the 'second'
machine, just reattaching the disks. (With MSA management
software).
We want the maximum amount of availability which can be
obtained with using the standard edition.
If that is not enough management can choose for the second
configuration, which will be more expensive.

We do not want to make the choice but supply the management
with enough 'numbers' and arguments to make a sollid choice on
the configuration.

#7

Thanks,
ben

"Rodney R. Fournier [MVP]" <rod (AT) die (DOT) spam.die.nw-america.com> wrote in
message news:OIAIp1JSEHA.2936 (AT) TK2MSFTNGP10 (DOT) phx.gbl...

Quote:

I think you want to look at creating a SQL Standby Server, which is
supported and very easy to do. Nothing to do with clustering, but neither
does your solution.

Cheers,

Rod
"ben brugman" <ben (AT) niethier (DOT) nl> wrote in message
news:c9k4ft$dt5$1 (AT) reader10 (DOT) wxs.nl...
First of all thanks for your time.
I would like to go over the points one at the time.

In my original mail I did (on purpose) elaborate, but
only at the end of the message.

"Rodney R. Fournier [MVP]" <rod (AT) die (DOT) spam.die.nw-america.com> wrote in
message news:uonKad#REHA.3708 (AT) TK2MSFTNGP10 (DOT) phx.gbl...
1) Standard Edition is not supported

We do not intend to automatically fail over, but doing the fail over by
'hand',
in this group there are a lot of advices how to do this.

2) No Cluster resources will be created, thus adding tons of work
during
the
install
We need an extra machine and an extra installation of OS/SQL-server and
of course the setting up of the hardware and hardware management.
But I doubt if 'real' clustering has less work.

3) It is a violation of EULA
I do not see a violation of the EULA, with this set up.
(But then EULA's are so complex that allthough I do understand them,
this is not totaly 100 %).

4) It will not failover properly
I think by hand it wil. If this is not true please point out why.

5) See number 1
See number one.

As said we will do the switch manually, also switching the
application servers. (By newly resolving the name and reconnecting).
So the fail over is manually, but we do not need to restore and recover.
So there is less availability than for 'real' clustering, but more than
if a (backup) restore recover is done in case of a server failure.

Any new insights ?

ben brugman.

Cheers,

Rod

"ben brugman" <ben (AT) niethier (DOT) nl> wrote in message
news:%23kCvdN%23REHA.1340 (AT) TK2MSFTNGP12 (DOT) phx.gbl...
I am aware that the standard edition does not 'include'
fail over clustering.

I have read this newgroup on items containing the
budget / standard edition clustering.

I get the strong impression that 'budget clustering' is
strongly advised against.
WHY ?

Thanks for your attention,
ben brugman

Elaboration :

We want to have two options :
1. Standard edition.
2. Enterprise / San / Fail over.

Offcourse for high availability, you have to pay and
go for the second solution.

But to make the first solution as good as possible,
we are thinking in lines of the 'suggested' budget
fail over clustering.

So we plan :
Two servers with internal OS / SQL-server software.
Two Raid storage units which will be host based mirrored.
(So each file is stored four times).
Two locations, one for each server, storage unit.

If a part of the storage fails, there is plenty of redundancy.
But if a server fails we plan to do a fail over to the 'second'
machine, just reattaching the disks. (With MSA management
software).
We want the maximum amount of availability which can be
obtained with using the standard edition.
If that is not enough management can choose for the second
configuration, which will be more expensive.

We do not want to make the choice but supply the management
with enough 'numbers' and arguments to make a sollid choice on
the configuration.

#8

"Rodney R. Fournier [MVP]" <rod (AT) die (DOT) spam.die.nw-america.com> wrote in
message news:OIAIp1JSEHA.2936 (AT) TK2MSFTNGP10 (DOT) phx.gbl...

Quote:

I think you want to look at creating a SQL Standby Server, which is
supported and very easy to do. Nothing to do with clustering, but neither
does your solution.

Did look up standby servers, but this is not what I meant.
In my mail I described that we didn't want to use the
backup / restore sequence, but just the switching of the
disks.

I have seen this mentioned as "budget clustering", but could
be wrong there. Sorry for that misunderstanding. Haven't got
a name / term for it.

ben

Quote:

Cheers,

Rod
"ben brugman" <ben (AT) niethier (DOT) nl> wrote in message
news:c9k4ft$dt5$1 (AT) reader10 (DOT) wxs.nl...
First of all thanks for your time.
I would like to go over the points one at the time.

In my original mail I did (on purpose) elaborate, but
only at the end of the message.

"Rodney R. Fournier [MVP]" <rod (AT) die (DOT) spam.die.nw-america.com> wrote in
message news:uonKad#REHA.3708 (AT) TK2MSFTNGP10 (DOT) phx.gbl...
1) Standard Edition is not supported

We do not intend to automatically fail over, but doing the fail over by
'hand',
in this group there are a lot of advices how to do this.

2) No Cluster resources will be created, thus adding tons of work
during
the
install
We need an extra machine and an extra installation of OS/SQL-server and
of course the setting up of the hardware and hardware management.
But I doubt if 'real' clustering has less work.

3) It is a violation of EULA
I do not see a violation of the EULA, with this set up.
(But then EULA's are so complex that allthough I do understand them,
this is not totaly 100 %).

4) It will not failover properly
I think by hand it wil. If this is not true please point out why.

5) See number 1
See number one.

As said we will do the switch manually, also switching the
application servers. (By newly resolving the name and reconnecting).
So the fail over is manually, but we do not need to restore and recover.
So there is less availability than for 'real' clustering, but more than
if a (backup) restore recover is done in case of a server failure.

Any new insights ?

ben brugman.

Cheers,

Rod

"ben brugman" <ben (AT) niethier (DOT) nl> wrote in message
news:%23kCvdN%23REHA.1340 (AT) TK2MSFTNGP12 (DOT) phx.gbl...
I am aware that the standard edition does not 'include'
fail over clustering.

I have read this newgroup on items containing the
budget / standard edition clustering.

I get the strong impression that 'budget clustering' is
strongly advised against.
WHY ?

Thanks for your attention,
ben brugman

Elaboration :

We want to have two options :
1. Standard edition.
2. Enterprise / San / Fail over.

Offcourse for high availability, you have to pay and
go for the second solution.

But to make the first solution as good as possible,
we are thinking in lines of the 'suggested' budget
fail over clustering.

So we plan :
Two servers with internal OS / SQL-server software.
Two Raid storage units which will be host based mirrored.
(So each file is stored four times).
Two locations, one for each server, storage unit.

If a part of the storage fails, there is plenty of redundancy.
But if a server fails we plan to do a fail over to the 'second'
machine, just reattaching the disks. (With MSA management
software).
We want the maximum amount of availability which can be
obtained with using the standard edition.
If that is not enough management can choose for the second
configuration, which will be more expensive.

We do not want to make the choice but supply the management
with enough 'numbers' and arguments to make a sollid choice on
the configuration.

#9

FYI, you can do a fully functional "budget cluster" using standard edition
of SQL/Windows using Legato's clustering product. Of course, it ain't free,
so that might blow your budget :-)

Regards,
John

"ben brugman" <ben (AT) niethier (DOT) nl> wrote

Quote:

"Rodney R. Fournier [MVP]" <rod (AT) die (DOT) spam.die.nw-america.com> wrote in
message news:OskDg1#REHA.3660 (AT) tk2msftngp13 (DOT) phx.gbl...
He is asking about a low-cost cluster. Using Standard Edition instead of
Enterprise.

Cheers,

Rod

"DaveK" <anonymous (AT) discussions (DOT) microsoft.com> wrote in message
news:31F9BABD-78FB-4174-B831-9E1B0C3D3093 (AT) microsoft (DOT) com...
Sorry could you explain what "budget clustering" is? Are you talking
about
3rd party software?

Thanks
DaveK

http://www.sqlporn.co.uk

I do not see the 'original message of DaveK, so I'll attach my anwser
here.

By budget clustering, different people have different meanings.
What I did understand and mean by budget clustering is :
Using the standard edition SQL-server.
Setting up a second machine similar to the first machine.
If the first machine fails, attach the 'database' disks to the
second machine.
And start up SQL-server on the second machine.
Because this machine has a different name and ip address the
applications have to reconnect after a new name resolve.
(So this has to be changed as well).
Of course here we are missing a lot of the advantages of the
'real' clustering mechanism where 'everything' goed automatic.
(failure detection, switching over, name resolving and if the
application is cluster aware the reconnection).
But the advantage of this way creating high availability is that
you do not have to restore and recover a database in case of
a server failure.
So in my this 'might' give a higher availability then using the
backup and restore route.

Remarks :
Offcourse have you datastorage redundant. So that a storage failure
(disk or system) can be handled.
A server failure will be a rare event (using servers which have redundancy
in power supply, memory etc.). So during a server failure you might lose
some availability time.
But losing say an hour every two years because of a server failure, or
paying for the more expensive 'real fail over' capable system, is
something
that has to be decided by the management.
Off course there will also be down time during regular upgrades of mainly
software and rearely hardware, but that can be planned.
Although we run a 7 x 24 hours shop, planned downtime is not to
disruptive.

With my question, I hope to get some insight in how realistic this set up
is. I would like to form an opinion based on more than : "That won't work"
or "That is not supported" or "That is not allowed".

ben brugman

#10

Ok, if its not a Standby Server, then I am lost. Maybe you are thinking
Mirrored Servers with SQL 2005?

Cheers,

Rod

"ben brugman" <ben (AT) niethier (DOT) nl> wrote

Quote:

"Rodney R. Fournier [MVP]" <rod (AT) die (DOT) spam.die.nw-america.com> wrote in
message news:OIAIp1JSEHA.2936 (AT) TK2MSFTNGP10 (DOT) phx.gbl...
I think you want to look at creating a SQL Standby Server, which is
supported and very easy to do. Nothing to do with clustering, but
neither
does your solution.

Did look up standby servers, but this is not what I meant.
In my mail I described that we didn't want to use the
backup / restore sequence, but just the switching of the
disks.

I have seen this mentioned as "budget clustering", but could
be wrong there. Sorry for that misunderstanding. Haven't got
a name / term for it.

ben

Cheers,

Rod
"ben brugman" <ben (AT) niethier (DOT) nl> wrote in message
news:c9k4ft$dt5$1 (AT) reader10 (DOT) wxs.nl...
First of all thanks for your time.
I would like to go over the points one at the time.

In my original mail I did (on purpose) elaborate, but
only at the end of the message.

"Rodney R. Fournier [MVP]" <rod (AT) die (DOT) spam.die.nw-america.com> wrote in
message news:uonKad#REHA.3708 (AT) TK2MSFTNGP10 (DOT) phx.gbl...
1) Standard Edition is not supported

We do not intend to automatically fail over, but doing the fail over
by
'hand',
in this group there are a lot of advices how to do this.

2) No Cluster resources will be created, thus adding tons of work
during
the
install
We need an extra machine and an extra installation of OS/SQL-server
and
of course the setting up of the hardware and hardware management.
But I doubt if 'real' clustering has less work.

3) It is a violation of EULA
I do not see a violation of the EULA, with this set up.
(But then EULA's are so complex that allthough I do understand them,
this is not totaly 100 %).

4) It will not failover properly
I think by hand it wil. If this is not true please point out why.

5) See number 1
See number one.

As said we will do the switch manually, also switching the
application servers. (By newly resolving the name and reconnecting).
So the fail over is manually, but we do not need to restore and
recover.
So there is less availability than for 'real' clustering, but more
than
if a (backup) restore recover is done in case of a server failure.

Any new insights ?

ben brugman.

Cheers,

Rod

"ben brugman" <ben (AT) niethier (DOT) nl> wrote in message
news:%23kCvdN%23REHA.1340 (AT) TK2MSFTNGP12 (DOT) phx.gbl...
I am aware that the standard edition does not 'include'
fail over clustering.

I have read this newgroup on items containing the
budget / standard edition clustering.

I get the strong impression that 'budget clustering' is
strongly advised against.
WHY ?

Thanks for your attention,
ben brugman

Elaboration :

We want to have two options :
1. Standard edition.
2. Enterprise / San / Fail over.

Offcourse for high availability, you have to pay and
go for the second solution.

But to make the first solution as good as possible,
we are thinking in lines of the 'suggested' budget
fail over clustering.

So we plan :
Two servers with internal OS / SQL-server software.
Two Raid storage units which will be host based mirrored.
(So each file is stored four times).
Two locations, one for each server, storage unit.

If a part of the storage fails, there is plenty of redundancy.
But if a server fails we plan to do a fail over to the 'second'
machine, just reattaching the disks. (With MSA management
software).
We want the maximum amount of availability which can be
obtained with using the standard edition.
If that is not enough management can choose for the second
configuration, which will be more expensive.

We do not want to make the choice but supply the management
with enough 'numbers' and arguments to make a sollid choice on
the configuration.