Software-based VM-centric and flash-friendly VM storage + free version
Moderators: anton (staff), art (staff), Max (staff), Anatoly (staff)
-
Kevin Marefat
- Posts: 2
- Joined: Thu Jul 09, 2009 9:29 pm
Thu Jul 09, 2009 9:36 pm
Hi,
I am tryingto add ISCSI storage to an existing MSCS active/active cluster and am running into problems and am looking for community and vendor support.
There are 3 server s involved:
WINDB2 - windows 2003/StarWind Target offers 2 targets
P_OL1 - node1 of an MS cluster, Windows 2003/MS initiator
P_OL2 - node 2 of the cluster, similar to P_OL1
Current Shared Disk Aubsystem is an HP MSA2012
I did follow the instructions in the 3/2009 PDF exactly and still have the same problem:
1. LUNS are carved out using StarWind, and connected using MS initiator for Windows 2003 Server
2. Drives are created, partitioned and formatted
3. Resources are created into the cluster and assigned to cluster groups
4. Failover (move group) successfully tested
5. Drives are available to the OS and successfully tested for read/write
6. The SQL Server still does not see the new drives
I appreciate your assistance in advance.
Thanks,
Kevin
Last edited by
Kevin Marefat on Fri Jul 10, 2009 3:56 pm, edited 1 time in total.
-
Kevin Marefat
- Posts: 2
- Joined: Thu Jul 09, 2009 9:29 pm
Fri Jul 10, 2009 3:48 pm
Hi Robert,
The SQL resides on a clustered virtual server called VSDB1, which normally runs on the node 1 of the cluster and moved to node 2 when a fail over occurs. Not to complicate matters but that is half of an active/active cluster set up. a second virtual server called VSDB2 runs normally on node 2 of the cluster and moves to node 1 when a fail over occurs. I have logs available as well, and thank you for your response.
Kevin
-
AccuMegalith
- Posts: 1
- Joined: Fri Jul 10, 2009 7:58 pm
Fri Jul 10, 2009 8:03 pm
Have you added the new drives as dependencies for SQL Server? In other words, the SQL Server resource needs to have these two new drives as dependencies for this resource. Clustered SQL Server 2000 (and later) won't even acknowledge disks on which it's not dependent, and won't let you create databases on them. This makes sense, as it would be bad for SQL Server to come online when one or more clustered disks containing databases didn't. It's more consistent, and protective of data, if the SQL Server process fails to come online at all.
