SQL Server Cluster Connection Point

This is an example, not a recommendation. It records a configuration Innovative built and proved end to end in its own lab, and is provided for informational purposes only. Innovative does not support or recommend any particular system. Licensing, networking, security policy, and infrastructure differ between installations — verify every address, name, and account against your own environment and standards, and involve your database and network administrators, before running any command or configuration found here. See Start Here.

Once an availability group pair is running, clients still have to know which node to talk to. A cluster connection point removes that question: one virtual IP that always points at the node currently holding the databases, so a failover requires no change on any client.

The virtual IP is a standard SQL Server availability group listener. Everything below is Microsoft's documented procedure.

Why one address

The SBN databases form a single failover unit — they depend on each other at run time, so they always move together. A listener belongs to exactly one availability group, so where a licence allows only one database per group, there is no single listener that spans them all.

That does not mean there is no single address. Because the groups are required to stay co-located, a listener on the group holding the database the application logs in to always resolves to the node holding every other database as well. One listener, on that anchor group, is the connection point for the whole set.

What you need first

1. A working two-node failover cluster with the availability groups created, every replica synchronised and healthy, and all groups on the same node.
2. One spare static IP address on the nodes' subnet, outside any DHCP scope, that nothing else answers on.
3. A DNS name for it. This example uses SBN-CLUSTER. Alphanumerics, hyphens and underscores only; NetBIOS reads only the first 15 characters.
4. Permission to create it: sysadmin, or ALTER ANY AVAILABILITY GROUP / CONTROL SERVER.
5. A third machine to test from — not either node. A node can always reach its own address, so testing on a node proves nothing.

Step 1 — Reserve the address and the name

Have the address reserved for the listener's exclusive use. Then confirm, on both nodes, that the address sits in a live subnet and that nothing already answers on it.

Standalone or workgroup nodes with no DNS server: there is nothing to register the name in, so add it to hosts on both nodes and on every client. Domain-joined installations skip this — the cluster registers the name itself.

Verify

1. The address is recorded, static, and outside any DHCP scope.
2. Each node shows an adapter in the virtual IP's subnet.
3. Test-Connection returns False on both nodes.

Step 2 — Create the listener

On the node that is currently primary:

That is the entire configuration. SQL Server creates the two cluster resources it needs — a Network Name and an IP Address — inside that group's cluster role, and moves them with the group on every failover. The remaining groups get no listener; nothing connects to a single database on its own.

Create it from SQL Server, never from Failover Cluster Manager. Microsoft: “Avoid creating a listener directly in the WSFC cluster.” And afterwards: “Don’t add or remove resources in the clustered service (resource group) for the availability group. Don’t change any availability group properties.” The availability group depends on its listener by design — that dependency is the listener, and removing it makes SQL Server stop recognising it.

Use a static IP, not DHCP. “We do not recommend DHCP in production environment. If there is a down time and the DHCP IP lease expires, extra time is required to register the new DHCP network IP address.”

Verify

One row: the anchor group, SBN-CLUSTER, the port, and your address. In the cluster, three resources in that role — the availability group, its Network Name and its IP Address — all Online.

Step 3 — Point every client at it

Every client uses the one address and nothing else: the desktop application, the background services, the API layer, and the compilers. Stored procedures reach the other databases through cross-database chaining on whichever instance the connection lands on, so a single entry point is all that is needed.

A service running under LocalSystem has its own profile — configuration placed only in an interactive user's profile is invisible to it. Set the address in both.

This is a one-time change. The virtual IP follows the primary automatically on every future failover, so no client is ever reconfigured again.

Never configure a connection from the registry — no ODBC DSN, no ConnectionString registry value, no other machine-local connection setting. A setting parked in the registry is invisible to every other machine, survives reinstalls, silently overrides what the product was told to do, and re-creates the per-machine special case the virtual IP exists to eliminate.

Do not change an operator's default database to work around a management tool. If a tool struggles to connect a login whose default database belongs to an availability group, set the initial catalog in that tool's own connection properties.

Verify

From the third machine, not from a node:

Expect the operator's own name, the node currently holding the groups, and the operator's normal default database.

The SBN Services tier gets its own virtual IP for the Concentrator — see SBN Services Cluster Connection Point.

Step 4 — Test it

Test with a live session open, not just a fresh connection — the point is that people already working keep working.

1. From the third machine, sign in as an ordinary operator through the cluster address and open a screen that queries continuously. Confirm the groups are together — a single row naming one node, with a count equal to the number of databases:

1. Fail every group over to the other node together, in one operation, using Transact-SQL or SSMS. Never move them one at a time, and never with Failover Cluster Manager.
2. Watch the session. It pauses briefly while it reconnects — about 20 seconds in Innovative's own two-node test — then carries on. The operator is not signed out and does not log in again, and nothing on the client is reconfigured.
3. Re-run the query. One row again, full count, naming the other node.
4. Fail back and repeat. A failover that only works in one direction is not a tested failover.

Verify

1. The session survived both failovers without a new login.
2. The cluster address named the correct node each time.
3. The co-location check returned a single row before and after each failover.
4. No client configuration changed at any point.

If the groups split

The one risk this design concentrates: the address still answers, but from a node that is primary for only part of the set. Queries touching a database that is primary elsewhere fail by name — “…is participating in an availability group and is currently not accessible for queries”. Run the co-location check after every failover, and move the groups back together before resuming operations.

Reference links

1. Configure an availability group listener
2. Failover clustering and Always On availability groups
3. Basic availability groups
4. Always On client connectivity