Conference decwet::winnt-clusters

Version 1.1 of cluster supports dual SQL primaries, e.g. each cluster server
runs an SQL server. Each of these SQL server work/own a different database on
different shared storage.

The connection from the clients can be through a named pipe or via sockets
(TCP).

Both connection will support failover.

The surviving SQL server will take over the DBs from the deseased (sp?) one
independant of the connection type.

hope this helps

	Thomas

Reply to .1 

Thomas, I believe those are general messages from SPDs which I am wondering 
is how can specifically apply is the point.  

If you, or anybody, have really got hands on dual SQL with cluster v1.1, you
will know what I am asking.  The issue is that one vertual IP address, in 
between two servers with their own IPs, can not commit the IP failover!! 

I suspect dual SQL IP failover can only be done with two IPs rather than 
one single IP sitting in between two servers with clustering v1.1.

Anyone pls advice.


Rgds,
:|
 
[Posted by WWW Notes gateway]

    
    IP addresses (i.e. IP failover objects) are placed into the groups in
    which your database storage resides.  That group is owned by one of the
    servers at a time.  If you want to implement databases on the other
    server as well and want clients to access the database(s) on that
    server using TCP/IP sockets, then you need another IP address for that
    group.  
    
    In other words, there is no IP address that sits "in between" both
    servers that allows client access via TCP/IP to databases residing on
    both servers.
    

Yes, that's exactly what I have found.  I believe this message should widely 
spread for all clusters gurus.  

However, I found dual SQL with multiple databases still have problems!!! 
Either
error message or Dr.Watson comes up.  But both servers seems working fine
later
on!? (if you ignore those "errors")  These are NOT accepted by customers. 

Besides, cluster administrator GUI ALWAYS cannot "see" both servers databases 
under SQL database objects.

In conclusion, v1.1 is not stable enough and I believe engineering should 
seriously look into and release any patch asap if possible.

Rgds,
:|

 

[Posted by WWW Notes gateway]

	Well, I agree that there are some annonyances in v1.1 but if
	you stick to the following SQL Server config rules everything
	is oke.
	With this I've never seen a Dr.Watson or error messages.

	Install NT4 (SP2) + SQL6.5(SP1) on both machines.
	Install NT Clusters 1.1

	Create some failover groups that will bring all the disks on-line
	to the same machine! This is very important.
	Now on this machine use the SQL Enterprise Manager to create
	your databases.
	Then enroll them on the same machine for NT Clusters.
	Assign an IP address to the group where you disks sit that
	contain those databases. (Automatically updated by NT Clusters)
	
	Fail each of the groups over to the other server and check that
	everything is still oke. Now for those groups that you want
	normally to be online on this machine, change the group to have
	the primary the current machine. (The other machine than that
	you created them on).
	
	With this setup, I've never seen any databases go missing or
	come up twice or DR.Watson messages.

	And a Cebit'97 we did this for over a week everyday at least 10-20
	failovers. It didn't miss a beat. Where there were at least around 
	10 different SQL databases configured, including mirrored ones, and
	one existing out of different datafiles.

	How to get into problems?
	Don't touch the Master.dat database and the Sys tables.
	Don't reinstall SQL Server!
	Check always the fmlog files in the NT Clusters\temp directory.
	They can tell you a lot.
	
	Pjotrr

Pjotrr,

Referring to your advice below, is it really works ??

      >>Fail each of the groups over to the other server and check that
        everything is still oke. Now for those groups that you want
        normally to be online on this machine, change the group to have
        the primary the current machine. (The other machine than that
        you created them on).

Sorry to ask but I need to try it out; however, my setup was broke-up
and loaned to customer until mid of May.  I'm desperately looking for 
my machines come back and test it out...

I have done all you've mentioned, just as mentioned from admin/config 
guide, but have no idea why we need to put all shared disks in primary 
machine first then change the group (with SQL database created) to the
backup server??  Is this somewhere documented I've missed ??

Besides, I believe when you create database from each SQL server, you 
need to specify where the database will be located.  Therefore, if we
change the group of shared disks to the backup server, as you mentioned,
is it really works ??  Will SQL intelligently knows the changes without
any errors ??  I'll doubt or shock if SQL will accept.

Pls kindly advice and help reconfirm....  Pls also advice on dual IP
address and if any command on client configuration.

If you reconfirm on this, I will not wait for my machines but go to 
customer site and try it out.  My customer is asking for such config
for a production environment. 

Looking forward to your prompt reply.


Best Selling,

Eddy
HK Tech Support

:>
 
  
[Posted by WWW Notes gateway]

	Yes, it really works.

	There some unniceties in the current v1.1 product.
	This is one of them. It will be fixed with SP1.
	I don't think it's documented anywhere, besides here in the notesfiles and
	I believe it has been mentioned during the NT Wizards.
	
	SQL Server has the knowledge about a primary and failback server.
	In each of the master.dat files you'll find the definitions around the
	databases on both machines (at least the ones that are enrolled).
	Open an ISQLW window to each of the machine and play around with the
	sp_fallback_help and the sp_helpserver stored procedures.
	Do this before and after the enrollment in CLuster Admin.
	You'll see that SQL Server knows alot about failing over of clustered databases.

	The procedure is basically like this.
	Do everything first to one server bein with all the relevant groups (that will
	contain SQL Server databases) online currently to one machine.
	The primary server should at that moment always be that machine.
	Then on this machine do:
	Create SQL devices
	Create SQL Databases on top of those devices.

	Up till now nothing special.

	Then:
	Activate Cluster Admin and enroll all of the databases!
	Don't leave an databases unenrolled!
	Cluster Admin, will when it comes up check on both machine if MSSQLSERVER is running
	and if not, it will start it.
	Then it will see if it's stored procedures are already installed
	(there's a reg. key for this, don't know which one anymore) and if the key is
	not set yet, it will first load those stored procedures to each of the systems.
	Cluster Admin uses these stored procedures to figure out which physical disks contain
	SQL databases, which databases are already enrolled, which are suspect and have to
	be set to unsuspect etc.
	Cluster Admin will then present you with a list of databases that can be enrolled.
	Or actually should be enrolled.
	When you then enroll those databases, Cluster Admin will then execute the stored
	procedures for you to register this in the master.dbo.
	It will also make automatically SQL Objects that are put each in the group that
	points to the disk they are on.
	This is saved in the registry of the cfmd object on each server.

	Again for now v1.1, without SP1, you have to do the creation en enrollment all on
	one machine. Then for those groups that you normally want to have on the other
	machine, you first fail them over to the other one, and then change the primary
	server. If you do this you should not run into any problems.

	Now what is really crucial however is not to destroy any of this change of info.
	Do never reinstall SQL Server without unenrolling the databases!
	The reinstall of SQL server will wipe out the master.dbo data around these databases
	and their failover capability. (The install asks you if you wnat really to overwrite
	the master.dat, answer there no here!)
	Also do not delete a database first from SQL Enterprise Manager without unenrolling
	it first! Then NT Cluster still thinks there's a database as well as SQL Server in the
	master.dbo. In reality it is not however. You have to resort to very low level
	stored procedures to clear this mess up.
	This is all clearly explained in the admin guide. 

	Pjotrr


	

After I tried the above suggestion I found both servers looks much more
better!
I would say perfectly in good condition; however, when I tried to add more
database in the failover group, errors occurred.  (Errors such as Dr. Watson
or "cluster-get-sql-info-array" error)

Pls kindly provide formal procedures for adding addition database after
cluster is up and running.  I believe we should still failover all failover
objects to one server...  I'm still trying to resolve this.

Besides, I still find problem on client connection to cluster alias -- cannot
see both servers' database.

Pls kindly advice.


Best Selling,

Eddy
HK Tech Support

:>


[Posted by WWW Notes gateway]

After more several trial, follow error was hit:  
( Still perfectly Good ??  I'll doubt now)

>Error from ClimFmSqlGetDBInfoArray = -1073741819
>Unknown error code 3221225477 (sev=3,fac=0x0,id=0x5)

&

>Error initializing
>Error getting SQL databases from CLUMGMT.DLL = -1073741819

I can see all databases on both servers side but still only see either one of
the servers' database from client side.

Pls help !!!

Rgds,
Eddy.
:}  
[Posted by WWW Notes gateway]

For the Dual SQL environment, I found that client cannot see all databases as
I mentioned in pervious messages.  Any advice for dual SQL client connect
suggestion ??

I believe, till now, that under dual SQL, only dual IP can be supported ?? 
ie. only support TCP/IP socket, instead of name-pipe or the rest of the
protocol.  
Somebody pls back me up or confirm this point.  I strong believe so...

Rgds,
Eddy
:{
[Posted by WWW Notes gateway]

    In order to get access to two seperate SQL databases using ISQL/w you
    need to set up an alternate pipe using the SQL Client Configuration
    Utility.   Once you have this alternate pipe then you can connect to
    the other database.  It is detailed how to do this in the Cluster
    Administrator handbook.  I have done as the book states and can connect
    to two seperate databases with no problems.
    
    Hth,
    
    
    /Shaun

On a NT client, I can see all databases by multi-connection but 
heard may not work on Window95, is this ture??

I'll try it out myself later.

Rgds,
Eddy

:>
[Posted by WWW Notes gateway]

Pls see my reply on note topic#781.

We've encountered both Win95 and Winnt now can see all databases but by
chances 
clients may need to initiate another connection to the server.

Rgds,
Eddy

:>
 
[Posted by WWW Notes gateway]

Clients Win95/Winnt are working properly and perfectly only if server side 
encounter no single problem.  

As long as DECnotes Topic # 783 and 765 got resolved.


:>

 
[Posted by WWW Notes gateway]