Re: A complicate cluster configuration...
- From: "Daniel Escudero de Félix" <daniel_escudero@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 22 Apr 2005 21:42:01 +0200
Hello.
It seems to be possible as you explain, but you should to keep in mind a
few things :
The SQL Server 2000 EE will be running just in one node, but if you want to
be able to make a fail over in case of problems, both server must be
possible owners of SQL Server 2000 application cluster group. To prevent the
fail back, disable it from group configuration.
It is possible that an operator can manage the cluster from a terminal
services session, but don´t forget that when the SQL services will be
started again, it is very recommendable to start the associated resource
from "cluster adminstrator" instead of using the services console
(services.msc for instance). When this happens, a manual fail over from
pasive node (as you said "backup") to active node (the usually active node)
could be made.
During fail over process, all comunications between clients and application
will be lost until the affected cluster group is running again, so some
transactions will be lost and no one file should be locked.
Best regards,
Daniel Escudero
"SR" <stefano@xxxxxxxxxxxxx> wrote in message
news:1114182770.838833.261350@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> ...for me at least.
>
> I'm a (Windows) cluster newbie. I have been surfing the web for a few
> days to figure out how to implement a cluster for a mission critical
> application we are running; the result will have to be compliant with
> our company's policies, so I'm turning to you to check whether or not
> my assumptions are correct.
>
> The cluster should be made of 2 nodes sharing a RAID storage unit, both
> running Win2k Advanced Server (no chance to upgrade to W2k3 due to
> internal policies).
>
> On both the nodes the following will be installed:
>
> - SQL Server 2k Enterprise Edition, to which 2 client apps will connect
> from outside the cluster via ODBC/JDBC
> - Oracle Transparent Gateway, allowing a remote OLAP system to access
> the SQL Server DB
> - Service A, an ActiveX Server executable that continuosly polls
> several dirs on the file system for text files to import into the DB,
> and monitors the DB for data that must be exported as text to different
> dirs. The service is designed to shutdown automatically if connection
> to the DB is lost.
> - Service B, that polls Service A's output dirs, re-processes the files
> and SFTPs them to a remote machine.
>
> Both the Transp. Gateway and services A and B will be stopped on the
> backup node, and configured for manual startup
>
> What we need:
>
> - DB files and in/out dirs should be placed on the storage.
> - MSCS should be configured in shared-nothing mode, so that only one
> node at a time can access the storage
> - The cluster will be configured as "Active/Stand By".
> - Should the whole default node, or its SQL instance, fail, the cluster
> should failover to the backup node.
> - An operator should then receive an alert and connect to the cluster
> from remote to start the stopped services on the backup node.
> - Once the problem with the default node has been solved, no automatic
> failback procedure should be triggered, but an operator should perform
> the switch manually instead, and this is my first big question: is this
> possible? And is it possible from remote (assuming you have admin
> access through terminal services, of course).
>
> I assume that:
>
> Though hosts outside the cluster see the nodes as a single host, any
> service/app running on a node connects to the local SQL instance over
> the loopback interface, so if it's SQL to fail, and not the whole
> machine:
>
> - During/after failover Oracle Transparent Gateway (think of it simply
> as an ODBC client) on the default node will lose connection to the DB.
> - During/after failover Service A will lose connection to the DB, and
> to the in/out dirs, being the cluster in shared-nothing mode. The
> cluster, I assume MSCS will handle things smoothly so that no lock on
> the file will survive the failover, thus blocking access to services on
> the backup node after it has taken control.
> - Similarly, Service B won't be able to reach the storage etc.
> - It will be possible for a remote user to check what's wrong with SQL
> Server on the default node from remote, while control has been
> transferred to the backup node.
>
> Is all the above possible? Are my assumptions correct?
>
> Any help would be greatly appreciated.
>
> Thanks
>
> Stefano
>
.
- References:
- Prev by Date: Re: cluster don't fail
- Next by Date: Re: cluster don't fail
- Previous by thread: A complicate cluster configuration...
- Next by thread: Failover behaviour on a 2 node cluster
- Index(es):
Relevant Pages
|
