May 26, 2008 at 1:21 pm
Hi,
I know this are very fundamental questions but I have failed once and I do not want to fail again...
I am trying to setup a active/active SQL 2005 Clustering. We are using 2 HP Blades with the quorum disk, and all dedicated disks on SAN. The Cluster will be running on Windows 2003 EE and SQL 2005 Enterprise. I have the windows clustering working and have the first SQL instance installed and failover tested on node 1.
My main question is how should I install the second instance?
Should I install it on node 1 or should I install it on node 2?
Do I need to specify the different folder on C drive for the installation folder?
Thank you,
Joses
May 26, 2008 at 3:22 pm
for the installation its better to select onther directory.
about active active am not sure, what i think is if u installed the second instance on only one node1 then it wont failover when u need to.
and u have to options:
1- instance1 on node1
instance2 on node1
so this is active/passive
or
2- instance1 on node1
instance2 on node2
so this is active/active
..>>..
MobashA
May 26, 2008 at 4:33 pm
If you have time please go thru this nice document:--
http://www.sqlservercentral.com/articles/Installation/clustering_a_sql_server_machine_/344/
Clustering SQL Server 2000 from 500 Feet.
Although urs is 2005 but concept of Active and passive configuration is still the same.
Manu
May 27, 2008 at 12:35 am
Hi,
I just set up last friday a 2 node SQL 2005 cluster with 4 SQL Virtual Servers (SQL instances). so the infos are current
🙂
Big picture:
- Each clustered SQL Virtual Instance has to to run on a separate, shared disk (LUN) so that it can failover independent of any other SQL virtual instance
- The installation of each instance has to go onto such a shared disk (This means that you will have several 'Microsoft SQL Server' directories, each of them on another shared disk
- For the production environment, plan to have the following shared disks (LUNs) for each instance: Database, Transaction Log, tempDB and eventually a backup LUN, if you dump the DBs and the T-Logs.
Proceed as follows:
- Define the 3-4 shared LUNs for each SQL virtual instance as well as a small LUN (500MB is enough) for the Cluster Quorum on your Storage solution (SAN, iSCSI, etc) and present them to your physical servers
- Power off Node 2 (to free the shared LUNs from any unwanted concurrent access)
- On node 1, create a new windows cluster which uses the shared quorum disk as the 'quorum'
- Power up Node 2
- On node 2, join this newly created cluster
- On Node 1, Start the SQL Setup. When you reach the page, where you can select the different components which you want to setup, select SQL Server (Database Services) and also select Create a SQL failover cluster. You also may choose the workstation components, if you want to manage the SQL cluster directly on the 2 nodes.
- In the next page, you can either choose default instance or you can enter a named instance. Remember: Only one default SQL instance can exist in a Microsoft SQL Cluster
This will install SQL Server on both of your cluster nodes.
Repeat above steps for each additional SQL instance you want to install on the cluster.
- When all of your SQL instances are installed, Start the setup of SQL SP2. This will give you the choice to upgrade all SQL instances in one shoot. You can select which ones you want to upgrade.
Active/Active Clustering: It is fully supported (had my design in review with microsoft) and is in fact the recommended setup regarding performance so you can use the power of both of your physical nodes instead of letting one hang arround idle doing nothing.
Hope this helps,
with kind regards,
John Ranger
May 28, 2008 at 7:00 am
Thanks for your info! Just one more question...
Should I install the second instance from Node 1 or from Node 2?
Thank you,
Joses
May 28, 2008 at 7:44 am
Hi,
install it from the node which is the active node for the resource group which contains the LUNs for your next SQL instance. (If you have not yet created this resource group, create it and add the dedicated LUNs to it).
This can be node 1 or node 2 and it doesn't make any difference if - at the time of the execution of the setup - the already existing SQL Virtual instance is hosted on node 1 or 2. There is no difference. Just make sure that the node from where you install ist the active node of the resource group for your next SQL instance (the node which currently hosts that resource group).
One important point I had forgot in my first post: Make sure that the SQL Server Resource is dependent on all its LUNs (Physical Disk resource) in a resource group. Meaning: That all disks are online before the SQL Virtual Instance tries to start. Same with SQL Server Agent Resource.
Hope this helps 🙂
With kind regards,
John Ranger
May 28, 2008 at 8:36 pm
John Ranger (5/28/2008)
One important point I had forgot in my first post: Make sure that the SQL Server Resource is dependent on all its LUNs (Physical Disk resource) in a resource group. Meaning: That all disks are online before the SQL Virtual Instance tries to start. Same with SQL Server Agent Resource.
In general good advice, but not always true. Any drives which the SQL Server instance is going to use for database files , log files, and tempdb files (both database and log files) must be configured as dependencies for the SQL Server service. This isn't necessary to do for SQL Server Agent as SQL Server Agent should have the SQL Server service configured as a dependency (meaning the drives are already taken care of).
If a drive isn't going to be used for database or log files, it doesn't have to be configured as a dependency. For instance, if you add a LUN to write backups to, this doesn't have to be a dependency. Whether or not you want it to be depends on your procedures.
K. Brian Kelley
@kbriankelley
May 28, 2008 at 11:38 pm
Brian,
thanks for the correction. My learning curve is still steep 🙂
With kind regards,
John Ranger
May 30, 2008 at 9:33 am
This is a doc I had to create for our department recently, about SQL Installation on a cluster (the formatting looks better in Word!!):
This assumes that the Cluster is built, with the LUNS allocated to the relevant Cluster Groups.
(1)Install MSDTC if required – this should be installed in the Cluster control Cluster Group
(2)Start install on Node1.
(a)Installing Prerequisites: SQL Prerequisites are installed – NOTE these components are only installed on the current node at this time; they are installed on the other node(s) later in the process. The process to install the prerequisites on the other nodes is transparent to the installer. In case of error installing the prerequisites, try rebooting all nodes in the cluster and restarting the install. If the error(s) persists, troubleshoot the error(s) to successfully complete this phase.
(b)System Configuration Check: The install performs a System Configuration Check. All items should have green checks. Any yellow warning icons should be investigated and resolved, these can sometimes be ignored (NOTE - if you are going to install SSRS, you must have IIS installed). Any red error icons must be resolved before proceeding.
(c)Enter registration info.
(d)Components To Install: Select the SQL components to install.
The ‘Create SQL Failover Cluster’ option is required.
Instance Name: Select the Default or a Named instance and define the Instance Name – this is the second part of ‘ServerName\InstanceName’.
(e)Virtual Server Name: Define the Virtual Server Name – this is the first part of ‘ServerName\InstanceName’. This should, ideally, be the same as the Cluster Group name.
(f)Virtual Server Configuration: Define the IP address for the Virtual Server. This should be the same as the IP address for the Cluster Group. The IP address must belong to the same subnet as the IP addresses used by all of the nodes. Don’t forget to click ‘ADD’ …
(g)Cluster Group Selection: Select the predefined Cluster Group to install SQL to.
(h)Cluster Node Configuration: Add all available Nodes to the Selected Nodes box. The current Node is in the Required Node field, and cannot be removed.
(i)Remote Account Information: Enter an AD account that has admin rights on all the Cluster Nodes participating in the Virtual Server.
(j)Service Account: Enter the details for the Service Account to be used to run the SQL Components Services.
(k)Domain Groups For Clustered Services: Select pre-existing global domain groups that are used to contain the startup account for each clustered service. You can choose to add all three services to the same global domain group, or to create separate global domain groups, one for each service.
(3)Completing the install. There should be no-one logged on to the other node(s) while this is happening, this will appear to do nothing for a while the other node(s) are updated. If any component(s) should fail to install, the installation must be rolled back, and the process restarted from scratch. This may require manual intervention to rollback the installation.
(4)Reboot all nodes (not required, but I have found this to be a good practice)
(5)Install SQL Server latest SP (downloaded from MS).
(6)Reboot all nodes.
(7)Verify that SQL starts.
Installation of a second (or subsequent) SQL instance on the cluster is just a case of repeating the above steps, referencing the different values in steps (2) (e) through (g).
How to use Surface Area Configuration Manager on a clustered SQL Instance
(1)Connect to the cluster (any node, or any V-Server), this step isn’t strictly necessary, as long as you can resolve the Network Name or IP address of the V-Server / instance you want to administer, any machine will do, but doing this from the cluster seems ‘tidier’.
(2)Open Surface Area Configuration Manager .
(3)On this screen, click the change computer link
(4)Select ‘Remote computer’, and enter the Network Name or the IP address of the V-Server / instance you want to administer.
(5)When you click ‘OK’ you should see the name you just entered instead of "localhost"
(6)On the “Surface Area Configuration for Services and Connections” screen, make sure you are looking at the right instance; you will see all instances installed on the cluster.
May 30, 2008 at 12:56 pm
Good collection Brian and Simon, Thanks for giving those info.
MCP, MCTS (GDBA/EDA)
May 30, 2008 at 1:45 pm
If you only install SQL Server instances from a single node, Integration Services (as well as Notification Services and Client Tools if you want them installed) will not be present when you spread the resources around.
So, if you install the data engine instances from a single node, be certain to hit the other nodes with integration services and (optionally) Notification Services and the client tools. If you use maintenance plans, they won't run without integration services.
Kyle
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply