Creating a new SQL Server Instance in a Failover environment

  • I am having a real hard time trying to create a new instance for a database using SQL Server 2019 Failover cluster.

    I am trying to follow these directions. I am stuck on Step 10 which is Instance Configuration. Normally when I create an instance in a regular SQL Server I just give it an instance name and that is it. In the SQL Server Network Name field would I need to create a new computer in the AD? Would the client point to this db in the connection string? I tried doing that. I entered the instance name and ID the same for my new instance (INSTANCE2). Then in the Cluster Resource Group page I get the same same errors for Available storage and Cluster Group, but also SQL Server(INSTANCE1): "The cluster group 'SQL Server(INSTANCE1)' contains resource 'SQL Server(INSTANCE1)' of type 'SQL Server' That are not permitted in a SQL cluster group. Ensure the cluster group does not contain SQL resources from another instance or Generic Service types."

    If I click to the next screen (Cluster Disk Selection), I can't select any of my disks.

    I get the following errors:

    Disk: Quorum: The disk resource 'Quroum' Cannot be used because it is a cluster quorum drive.

    SQL-DATA: The disk 'SQL-DATA' is already in use by resource 'SQL Server(INSTANCE1)'. To use a disk in a new SQL Server failover cluster instance, the disk must not have any dependencies that reference it..

    SQL-LOGS: The disk 'SQL-LOGS' is already in use by resource 'SQL Server(INSTANCE1)'. To use a disk in a new SQL Server failover cluster instance, the disk must not have any dependencies that reference it.

    I am really unsure how to proceed. Any help would be greatly appreciated.

    • This topic was modified 3 years, 3 months ago by  Papote.
  • You need to present all fresh storage.  You cannot use the existing storage which has been provisioned and presented to INSTANCE1.

    You then need a new computer object in AD for SQLVirtualName2

    After you have brand new disks, and pre-staged the necessary AD objects you can then go and install another instance of SQL as an FCI.

  • So there is no way at all to share storage for a new instance using fail over clustering? Kinda wish I knew this before hand.

    I personally like to create a new instance when a system uses multiple databases, to tidy up. Like SharePoint on premise which creates a bunch of databases with no similar names. Is there a Best Practice for when it is necessary to create new instances?

     

  • No, no way at all.

    The resources used by the role must be independent of other roles resources.

    Each FCI **MUST** have its own storage, its own VNN, its own IP.

     

    Best practise is always subjective, create the instances as they are needed, but my best practise is to never have more than 1 instance per cluster/machine, unless someone can give me a very good reason to use stacked instances.

     

     

  • To install or upgrade a SQL Server failover cluster instance (FCI), you must run the Setup program on each node of the underlying Windows Server failover cluster. To add a node to an existing SQL Server failover cluster instance, you must run SQL Server Setup on the node that is to be added to the SQL Server failover cluster instance. Do not run Setup on the active node to manage the other nodes.

    Depending on how the nodes are clustered, the SQL Server failover cluster instance is configured in the following ways:

    SEVENMENTOR: BEST TRAINING PROVIDER

    Nodes on the same subnet or the same set of subnets - The IP address resource dependency is set to AND for these types of configurations.

    Nodes on different subnets - The IP address resource dependency is set to OR and this configuration is called a SQL Server multi-subnet failover cluster instance configuration. For more information, see SQL Server Multi-Subnet Clustering (SQL Server).

    The following options are available for SQL Server failover cluster installation:

    Option1: Integration Installation with Add Node

    SQL Server integrated failover cluster installation consists of the following steps:

    Create and configure a single-node SQL Server failover cluster instance. When you configure the node successfully, you have a fully functional failover cluster instance. At this point, it does not have high availability because there is only one node in the failover cluster instance.

    On each node to be added to the SQL Server failover cluster instance, run Setup with Add Node functionality to add that node.

    Option 2: Advanced/Enterprise Installation

    SQL Server Advanced/Enterprise failover cluster installation consists of the following steps:

    On each node that is a possible owner of the new SQL Server failover cluster, follow the Prepare Failover Cluster setup steps that are listed in the Prepare section. After you run the Prepare Failover Cluster on one node, Setup creates the Configuration.ini file that lists all the settings that you specified. On the additional nodes to be prepared, instead of following these steps, you can supply the autogenerated Configuration.ini file from the first node as an input to the Setup command line. For more information, see Install SQL Server 2016 Using a Configuration File. This step prepares the nodes ready to be clustered, but there is no operational instance of SQL Server at the end of this step.

    After the nodes are prepared for clustering, run Setup on one of the prepared nodes. This step configures and finishes the failover cluster instance. At the end of this step, you will have an operational SQL Server failover cluster instance and all the nodes that were prepared previously for that instance will be the possible owners of the newly-created SQL Server failover cluster instance.

    If you are creating a failover cluster instance that spans multiple subnets, Setup will detect the union of all the subnets across all nodes that have the SQL Server prepared failover cluster instance. You will be able to specify multiple IP addresses for the subnets. Each prepared node must be the possible owner of at least one IP address.

     

     

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply