Conference decwet::winnt-clusters

Extracted from the Wolfpack White Paper - Part 3:
    
>> Microsoft SQL Server 6.5 functions similar to Wolfpack with the concept of 
>> a Virtual Server (VS). A VS is one logical SQL Server running on a Wolfpack 
>> cluster. One node of the cluster is designated the primary node for the VS 
>> and the other node is designated as the backup node. Should a failure occur
>> on the primary node, the Wolfpack coordinates a failover to the secondary 
>> node. Control of the SQLServer database instance is transferred to the
>> backup secondary node. 
>>
>>The definition of a server includes: 
>>
>>- Executables on the shared disks which includes all executables and all 
>>  server databases including the Master, Model, MSDB, and TempDB. 
>>
>>- All user databases and log files on the clusters shared disks. 
>>
>>- All server contexts stored in the WindowsNT registry. 
>>
>>- The named pipe that serves as the connection point to the database and 
>>  the IP address corresponding to that named pipe. 
>>
>>- The SQL Executive and the Distributed Transaction Coordinator of the VS. 
>>
>>
>> SQL Server will ensure that all databases and logs, and everything stored in 
>> the master database (configuration parameters, groups and users, replication 
>> information, etc.) stays consistent between the primary server and backup 
>> server. The databases and logs reside in the same place (the shared disks) 
>> regardless of whether the virtual server runs on the primary or backup node. 
>> Registry information is kept consistent between the primary and secondary 
>> nodes by using registry replication.
    
    It says: "SQL Server will ensure that all..." - is this through the
    Virtual Server? If so - is this Virtual Server part of SQL Server V6.5,
    or is it something Microsoft has developed for their Cluster Software?
    If so - should we use the VS in our Cluster Solution?
    
    Questions, questions....
    
    - Bjarne
    

    SQL Server replication is not supported in Digital Clusters V1.1.  We
    have had many requests to support it, and are investigating what it
    would take.
    
    The Wolfpack Whitepaper to which you refer is very interesting.  We
    know that Microsoft was considering a "virtual server" design, and this
    will probably be their future for a number of services like SQL server. 
    However, as far as we know, MS has decided NOT to implement a virtual
    server for SQL 6.5 due to many problems.  Microsoft's public statement
    is that WOlfpack V1.0 will support "simple SQL 6.5 failover", which
    means the server runs on ONE node at a time, and the entire server
    fails over to the other node.  This is very similar to what we provided
    in Digital Clusters V1.0.
    
    Digital Clusters V1.1 does not provide a virtual server implementation
    of SQL 6.5.  Rather, we allow SQL 6.5 to run on both nodes, and
    failover causes the SQL server process running on one node to "take
    over" the shared databases that were being served by the other node. 
    This only works for databases on shared disks.  It does not cover the
    SQL "system" databases such as master or msdb.  Since replication is
    controlled by the msdb database, we have to look for alternate
    approaches to replication in a cluster.

    Thank you very much so far. We have some additional questions.
    
    >> Digital Clusters V1.1 does not provide a virtual server
    >> implementation of SQL 6.5.  Rather, we allow SQL 6.5 to run on both
    >> nodes and failover causes the SQL server process running on one node to
    >> "take over" the shared databases that were being served by the other 
    >> node.    
    
    What happens when node A is up and running again? Will it "take back"
    the shared databases that were being served by node B when node A was
    down? If so, can we expect the replication to continue as normal after
    node A is up and running againg?
    
    >> This only works for databases on shared disks.  It does not cover
    >> the SQL "system" databases such as master or msdb.  Since replication
    >> is controlled by the msdb database, we have to look for alternate
    >> approaches to replication in a cluster.
    
    Does this mean that we shouldn't run SQL Server V6.5 with replication
    in a V1.1 Cluster at all? Or does it just mean that replication will
    not happen while node A is down? An SQL Server system that
    don't replicate is better than an SQL Server system that stops to
    function in case of a breakdown of node A.....
    
    Sorry, I've still got questions, but we need to get the scenario(s)
    clarified before we contact the customer.
    
    
    Thank you in advance,
    
    Bjarne

    I think you got the right idea in your previous reply.  When Node A is
    down, replication will not take place.  However, Node B can still serve
    databases on the shared disks.  When Node A comes back up, it could
    resume replication.  (If you are using replication to publish a database
    on the shared disks, then the shared disks must be put back online on
    Node A.)

Thank you again, still some questions to go before we have all this clear.

>> When node A comes back up, it could resume replication. 
   
Will all modifications that has been done when Node B was "in charge" also
be replicated? Do we have to do some work to make this happen?
Has this ever been tested? It would be nice to have a description of what
we can expect to happen:
	- when Node A goes down
	- in the periode Node A is down
	- when Node A comes back up

Is this ever tested? As long as you use the term "could resume replication"...

These are very new technologies to us, so it would be nice to know the answers
of these questions both for a cluster that does replication, and for a cluster
that don't replicate.

Many thanks in advance. 
    
    - Bjarne

    Any comments to my last questions? We need to give the customer the
    definite answer to the question:
    
    - Do the subscription servers loose data when the replication
    process is down (a failover situation)? 
    
    Or, better:
    
    - every update during Node A downtime will be replicated
    as soon as Node A replication is up and running again?
    
    Which of these is true? Thank you in advance.
    
    SQL Server scheduled tasks will not be failed over at all, will they?
    They are defined is msdb, which resides in the msdb database. Would it
    be possible to "clone" the contents of this database on the failover
    server?
    
    Regards,
    
    Bjarne

    I have not tried replication - if I were you, I would set up a lab
    situation if possible and try it out before recommending to a customer.
    
    >>Will all modifications that has been done when Node B was "in charge"
    >>also be replicated? 
    
    Since replication is log-based, I would expect it to be able to pick up
    at the point it left off when replication is resumed.  Note there are
    problems (well described in the SQL doc) with letting the publishing
    and subscription databases get too far out of sync.
    
    >>Do we have to do some work to make this happen?
    
    I would think you'd just have to make sure replication was running once
    the primary server was back in control, but I don't know for sure.
    
    >>Has this ever been tested? It would be nice to have a description of
    
    Not by me...
    
    >>SQL Server scheduled tasks will not be failed over at all, will they?
    >>They are defined is msdb, which resides in the msdb database. Would
    >>it be possible to "clone" the contents of this database on the
    >>failover server?
    
    It is supposedly possible to clone tasks using replication.  I wouldn't
    advise it in this case.
    
    	Al