![]() | |
![]() |
| | Thread Tools | Display Modes |
#11
| |||
| |||
|
|
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 in message news:c9kiif$kgg$1 (AT) reader10 (DOT) wxs.nl... "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. |
![]() |
| Thread Tools | |
| Display Modes | |
| |