AlwaysOn terminology

Question

Hello!
http://blogs.technet.com/b/dataplatforminsider/archive/2013/06/27/alwayson-in-sql-server-2014-ctp1.aspx
"AlwaysOnencompasses
the SQL Server solutions for mission-critical high availability and disaster recovery. Two solutions were included under the AlwaysOn umbrella in SQL Server 2012:
Availability Groupsand
Failover Cluster Instances.
I don't understand why  "Availability Groupsand
Failover Cluster Instances" are both parts of AlwaysOn technology: AlwaysOn can
not exist without Availability Groups should they be deployed on standalone SQL instances or FCI instances, as depicted here:
http://msdn.microsoft.com/en-us/library/hh270278.aspx
In other words, I can install FCI and NOT use AlwaysON or I can deploy AlwaysON on an already existing SQL cluster, so why 
Availability Groupsand
Failover Cluster Instances
"included under the AlwaysOn umbrella"??? Failover Cluster Instances technology existed far earlier than AlwaysON...
Thank you in advance,
Michael

Answer 1

AGs always part of Failover Cluster Instances (FCI) or Standalone instance and this runs under WSFC
The logic is simple, Without OS, WSFC, SQL Instance, SQL instance AGs & SQL Failover cant happen,  So her is the communication layer between each other resources is coming to picture,performing failover operation and making sure all the resoruces
are up and running etc... listener, Quorum, heartbeat, witness and more..
WSFC cluster
A Windows Server Failover Clustering (WSFC) cluster is a group of independent servers that work together to increase the availability of applications and services.
Failover cluster instance
An instance of a Windows service that manages an IP address resource, a network name resource, and additional resources that are required to run one or more applications or services. Clients can use the network name to access the resources in the group,
similar to using a computer name to access the services on a physical server. However, because a failover cluster instance is a group, it can be failed over to another node without affecting the underlying name or address.
Node
A Microsoft Windows Server system that is an active or inactive member of a server cluster.
Cluster resource
A physical or logical entity that can be owned by a node, brought online and taken offline, moved between nodes, and managed as a cluster object. A cluster resource can be owned by only a single node at any point in time.
Resource group
A collection of cluster resources managed as a single cluster object. Typically a resource group contains all of the cluster resources that are required to run a specific application or service. Failover and failback always act on resource groups.
Resource dependency
A resource on which another resource depends. If resource A depends on resource B, then B is a dependency of A.
Network name resource
A logical server name that is managed as a cluster resource. A network name resource must be used with an IP address resource.
Preferred owner
A node on which a resource group prefers to run. Each resource group is associated with a list of preferred owners sorted in order of preference. During automatic failover, the resource group is moved to the next preferred node in the preferred owner list.
Possible owner
A secondary node on which a resource can run. Each resource group is associated with a list of possible owners. Resource groups can fail over only to nodes that are listed as possible owners.
Quorum mode
The quorum configuration in a failover cluster that determines the number of node failures that the cluster can sustain.
Forced quorum
The process to start the cluster even though only a minority of the elements that are required for quorum are in communication.
WSFC :
Distributed metadata and notifications. WSFC service and hosted application metadata is maintained on each node in the cluster. This metadata includes WSFC configuration and status in addition to hosted application settings. Changes to a node's
metadata or status are automatically propagated to the other nodes in the cluster.
Resource management. Individual nodes in the cluster may provide physical resources such as direct-attached storage, network interfaces, and access to shared disk storage. Hosted applications register themselves as a cluster resource, and may
configure startup and health dependencies upon other resources.
Health monitoring. Inter-node and primary node health detection is accomplished through a combination of heartbeat-style network communications and resource monitoring. The overall health of the cluster is determined by the votes of a quorum
of nodes in the cluster.
Failover coordination. Each resource is configured to be hosted on a primary node, and each can be automatically or manually transferred to one or more secondary nodes. A health-based failover policy controls automatic transfer of resource ownership
between nodes. Nodes and hosted applications are notified when failover occurs so that they may react appropriately.
AlwaysOn Availability Groups and AlwaysOn Failover Cluster Instances :
Both AlwaysOn Availability Groups and AlwaysOn Failover Cluster Instances use WSFC as a platform technology, registering components as WSFC cluster resources. Related resources are combined into a
resource group, which can be made dependent upon other WSFC cluster resources. The WSFC cluster service can then sense and signal the need to restart the SQL Server instance or automatically fail it over to a different server node in the WSFC cluster.
Instance-level High Availability with AlwaysOn Failover Cluster Instances
An AlwaysOn Failover Cluster Instance (FCI) is a SQL Server instance that is installed across nodes in a WSFC cluster.
In the event of a failover, the WSFC service transfers ownership of instance's resources to a designated failover node. The SQL Server instance is then re-started on the failover node, and databases are recovered as usual. At any given moment, only a single
node in the cluster can host the FCI and underlying resources.
Database-level High Availability with AlwaysOn Availability Groups
An availability group is a set of user databases that fail over together. An availability group consists of a primary
availability replica and one to four secondary replicas that are maintained through SQL Server log-based data movement for data protection without the need for shared storage. Each replica is hosted by an instance of SQL Server on a different node
of the WSFC cluster. The availability group and a corresponding virtual network name are registered as resources in the WSFC cluster.
An availability group listener on the primary replica's node responds to incoming client requests to connect to the virtual network name, and based on attributes in the connection string, it redirects each request to the appropriate SQL Server
instance.
In the event of a failover, instead of transferring ownership of shared physical resources to another node, WSFC is leveraged to reconfigure a secondary replica on another SQL Server instance to become the availability group's primary replica. The availability
group's virtual network name resource is then transferred to that instance.
At any given moment, only a single SQL Server instance may host the primary replica of an availability group's databases, all associated secondary replicas must each reside on a separate instance, and each instance must reside on separate physical nodes.
WSFC Inter-node Health Detection and Quorum Voting
Each node in a WSFC cluster participates in periodic heartbeat communication to share the node's health status with the other nodes. Unresponsive nodes are considered to be in a failed state.
A quorum node set is a majority of the voting nodes and witnesses in the WSFC cluster. The overall health and status of a WSFC cluster is determined by a periodic
quorum vote. The presence of a quorum means that the cluster is healthy and able to provide node-level fault tolerance.
A quorum mode is configured at the WSFC cluster level that dictates the methodology used for quorum voting and when to perform an automatic failover or take the cluster offline.
Disaster Recovery Through Forced Quorum
Depending upon operational practices and WSFC cluster configuration, you can incur both automatic and manual failovers, and still maintain a robust, fault-tolerant SQL Server AlwaysOn solution. However, if a quorum of the eligible voting nodes in the WSFC
cluster cannot communicate with one another, or if the WSFC cluster otherwise fails health validation, then the WSFC cluster may go offline.
If the WSFC cluster goes offline because of an unplanned disaster, or due to a persistent hardware or communications failure, then manual administrative intervention is required to
force a quorum and bring the surviving cluster nodes back online in a non-fault-tolerant configuration.
Afterwards, a series of steps must also be taken to reconfigure the WSFC cluster, recover the affected database replicas, and to re-establish a new quorum.
Hope this helps answering your question, In the above some how everything is part of SQL, WSFC,FCI,OS etc.. :)
Raju Rasagounder Sr MSSQL DBA