SQL cluster question

Xtrema wrote: ↑ I assume you still run SQL on physical hardware?

Virtualization will solve this problem but if you are not virtualized yet, it's not a trivial task.

You can potentially add Hyper-v roles on your SQL cluster nodes to run VMs. If you are on Windows Server Datacenter, you can run unlimited VMs. If you are only Server standard, then you can have 2 VMs.

Once you are comfortable how a VM failover between your physical nodes, just install SQL on the VM. And since you are licensing SQL by the available cores these day (does CAL license still exist?), you shouldn't breach any licensing either.

But yeah, you should work towards virtualizing SQL. There are probably a lot of i's to dot and t's to cross but it will give you much more flexibility when a vendor won't bent.

rocking23nf wrote: ↑ im running a SQL cluster on virtual server 2019 servers, from a datacenter 2019 host (clustered as well) my SQL is licenced by core, but not the cores of the host, i have 8 cores with software assurance, so my second SQL in the cluster doesnt need cores assigned. if i licenced the whole host machine i would have needed 40 cores of SQL.

trane0 wrote: ↑ Not sure what exactly you're talking about, as there's no such thing as a SQL Server "cluster". I'm going to assume that you've got one or more availability groups set up across your SQL 2019 instances and as such, have one host designated as the usual primary, and the rest of the hosts in the AG will be secondary.

If you need to install a vendor product against one host, you can pick any in the AG and use that hostname explicitly in the connection string. However there will be no HA/DR capabilities for that vendor application (i.e. if the SQL instance goes down, the app goes down). If you want the vendor DB to be a part of one of the AGs, you can add the DB to the AG and have it take advantage of the HA/DR advantages, however it seems like your vendor doesn't won't support that configuration. That doesn't mean that it won't work though.

What I don't understand is that you have SQL 2019 (presumably enterprise edition) and Windows 2019 datacentre, but you don't have a dedicated DBA? That seems crazy to me, as this kind of configuration and supporting such an environment requires at least a part-time DBA.

rocking23nf wrote: ↑ Hi everyone, anyone here know if you can connect to a single node of a SQL cluster in SQL2019, my hunch is that this is a no, i have a SQL cluster running all my business APs, but a lone vendor says they cannot install against a cluster. they can only install against a single SQL node.

i dont want to make a single node SQL server because of cost and waste of time and resources, i also dont want to tear apart my cluster that is working just fine.

my hunch is this is not possible simply because of the way clusters operate, but maybe an advanced SQL expert may be on these boards that might have some insight?

thanks.

trane0 wrote: ↑ Not sure what exactly you're talking about, as there's no such thing as a SQL Server "cluster". I'm going to assume that you've got one or more availability groups set up across your SQL 2019 instances and as such, have one host designated as the usual primary, and the rest of the hosts in the AG will be secondary.

If you need to install a vendor product against one host, you can pick any in the AG and use that hostname explicitly in the connection string. However there will be no HA/DR capabilities for that vendor application (i.e. if the SQL instance goes down, the app goes down). If you want the vendor DB to be a part of one of the AGs, you can add the DB to the AG and have it take advantage of the HA/DR advantages, however it seems like your vendor doesn't won't support that configuration. That doesn't mean that it won't work though.

What I don't understand is that you have SQL 2019 (presumably enterprise edition) and Windows 2019 datacentre, but you don't have a dedicated DBA? That seems crazy to me, as this kind of configuration and supporting such an environment requires at least a part-time DBA.

HWDAN55 wrote: ↑ Vendor software has no awareness of a SQL cluster. As long as they aren't installing software on your SQL cluster you should be good. Generally we forbid installing any vendor software on a SQL Server server, whether stand-alone or a cluster. Keep your SQL Server purely independent database servers, apps belong on their own servers.

All the app needs to know about your SQL Server is the virtual SQL resource name and instance, or the virtual ip and port # for stuff that uses JDBC.

If Always on is configured, you generally use listener name, and the application driver needs to be a version that is Always On aware or you'll be in trouble when the primary switches over to the other instance.

rocking23nf wrote: ↑ i may have workaround in place setting up a new instance solely on node1, but that removes my high availability from my cluster.

Kherani wrote: ↑ Haven't worked with SQL in a long time, but I'm pretty sure I've connected to \\server\instance before in a clustered environment via SQL Server Management Studio.

mrtin905 wrote: ↑ Isn't Azure a better option?

rocking23nf wrote: ↑ you can have 2 instances, so \\cluster\instance1, and \\node\instance2.

but the database in my issue is \\cluster\instance1 and they claim to not be able to connect to that, that they can only use \\node\isntance.

i dont believe you can mount the same database in instance 1 and 2, and you cant connect to \\node of a cluster for a instance in a cluster. (maybe there is a hack or something that im not aware of)

rocking23nf wrote: ↑ i dont believe you can mount the same database in instance 1 and 2, and you cant connect to \\node of a cluster for a instance in a cluster. (maybe there is a hack or something that im not aware of)