First, when using AGs, you generally are not using a clustered instance of SQL Server, you are using multiple standalone SQL Servers. You are able to technically connect to each individual SQL Server in the Windows Cluster Separately. Each having their own configuration and resources.
Secondly, each group has its own name in AD as a computer object and its own IP address. These are registered in DNS. These are different than the cluster name. The listener name is a special object to route traffic based on incoming query type. For instance, if you configured your AG to use a secondary node for read only queries, the listener name is what routes that query to the secondary node, not the cluster group. Backups are also attached to that listener name for routing traffic from the primary to the secondary node.
If you are monitoring AG health, it will be based off of the listener name/object, not the cluster name. It is possible to have a 3 node windows cluster, but only have an AG involving 2 nodes. The cluster name would not properly handle that.
Adding further complexity to this question. With SQL 2016, you have distributed availability groups which uses separate clusters on different networks or domains. Those separate clusters are clusters all to them selves and are only joined via the listener name for failover purposes.
Lastly, if you chose to extend your AG to Azure, you will need to use the listener when connecting to the "active" database so your query can route to the appropriate node. The cluster resource name does not know about the Azure secondary node.
Yes it is the same thing. See section 3 which explains this term.
First lets get few terms straight.
- Windows Server Failover Clustering
A Windows Server Failover Clustering (WSFC) cluster is a group of
independent servers that work together to increase the availability of
applications and services. SQL Server 2016 takes advantage of WSFC
services and capabilities to support Always On availability groups and
SQL Server Failover Cluster Instances.
- Always On Availability Groups (SQL Server)
The Always On availability groups feature is a high-availability and
disaster-recovery solution that provides an enterprise-level
alternative to database mirroring. Introduced in SQL Server 2012,
Always On availability groups maximizes the availability of a set of
user databases for an enterprise. An availability group supports a
failover environment for a discrete set of user databases, known as
availability databases, that fail over together. An availability group
supports a set of read-write primary databases and one to eight sets
of corresponding secondary databases. Optionally, secondary databases
can be made available for read-only access and/or some backup
operations. An availability group fails over at the level of an
availability replica.
Failovers are not caused by database issues such as a database
becoming suspect due to a loss of a data file, deletion of a database,
or corruption of a transaction log.
- Always On Failover Cluster Instances (SQL Server)
As part of the SQL Server Always On offering, Always On Failover
Cluster Instances leverages Windows Server Failover Clustering (WSFC)
functionality to provide local high availability through redundancy at
the server-instance level—a failover cluster instance (FCI). An FCI is
a single instance of SQL Server that is installed across Windows
Server Failover Clustering (WSFC) nodes and, possibly, across multiple
subnets. On the network, an FCI appears to be an instance of SQL
Server running on a single computer, but the FCI provides failover
from one WSFC node to another if the current node becomes unavailable.
Item number 2 and 3 can be combined and item 1 is a prerequisite for implementing any combination. 2 alone, 3 alone, 2 and 3 together.
When you combine 2 and 3 you get: Failover Clustering and Always On Availability Groups (SQL Server)
You can set up a second layer of failover at the server-instance level
by implementing SQL Server failover clustering together with the WSFC
cluster. An availability replica can be hosted by either a standalone
instance of SQL Server or an FCI instance. Only one FCI partner can
host a replica for a given availability group. When an availability
replica is running on an FCI, the possible owners list for the
availability group will contain only the active FCI node. + Always On
availability groups does not depend on any form of shared storage.
However, if you use a SQL Server failover cluster instance (FCI) to
host one or more availability replicas, each of those FCIs will
require shared storage as per standard SQL Server failover cluster
instance installation.
I would highly recommend reading this FAQ by SQLHA (Allan Hirt) which clarifies many basic questions when you combine these 3 items.
Best Answer
A SQL Server Failover Cluster Instance (FCI) will always have a "Network name resource" for clients to connect to the active node.
But with AlwaysOn Availability Groups it is optional, and created through SQL Server. If you don't create an AG Listener, the Windows cluster will not have any IP address or hostname that moves along with the AG.
In any case an AG Listener is a Windows Server Failover Clustering "Network name resource", and so is confined to a single Cluster. If you have a Distributed Availability Group which spans multiple Clusters, or a Read-Scale Availability Group which has no cluster, then you can't have an AG Listener. (Although with a Distributed AG each participating AG can have its own listener).