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.
Dynamic quorum basically dynamically adjusts votes depending on available servers.
Each time when one of nodes goes down, dynamic quorum will remove the vote from that node.
In your scenario you have 2 nodes only and dynamic quorum will automatically remove the vote from your passive node, so the 1st node will have the majority of votes. In planned maintenance scenario when you are shutting down the first node quorum will transfer the vote from first to the second, and remove it from the first node.
However in scenario where first node just crashes quorum does not have time to transfer the vote and your second node wont get to vote, which basically will just shut down your cluster.
Therefore in scenario with 2 nodes only, it is recommended to have a witness.
Best Answer
You can configure Corosync and pacemaker for Linux. Good luck.
In the same cluster, no. Someone will argue with me and say, "Well, Sean, you can do read-scale availability groups like this!" and that may be true, however it isn't a cluster.
The only way to do this would be to have two different clusters, spanned by a distributed availability group. If you want to make life complicated then this would be the setup to do it.