Where exactly is the storage located in Oracle Clusterware - ASM?

Question

Where exactly does the storage reside in an oracle clusterware architecture ?

Example:

• I have a database with 3 instances on 3 different nodes: instance1, 2 and 3.
  

Where is the storage located? And now these are the 2 possible cases that i could think of:

1. The same storage actually resides on each and single one of the nodes and is synchronized between the instances

2. There is a 4th like node where the disks in the diskgroups are located and these are shared between the instances

Now for me both of these seem plausible enough and i swear i didn't find a proper answer anywhere. I incline towards the first case more, but then why exactly do you use ASM and not dataguard?

And also, if the first case is correct, why exactly ALL THE PICTURES on the internet that describe the Oracle Clusterware look like this: https://i.sstatic.net/vwkLq.png, from which everyone can understand that there is 1 storage shared between the instances, instead of this https://i.sstatic.net/OlQ8d.png and not call this synchronization, instead of shared?

Shared = 1 source, multiple targets, i think everyone can agree with that; 1 to many relation Synchronized = many to many

And otherwise, if the second case is true, what exactly high availability means? I mean, high availability is referring to the situation in which one of the nodes becomes unavailable, but you can still access the db through one of the other nodes. But if the storage is a different server, and it fails, it wouldn't matter how many instances you have, because you have no storage..

Answer 1

Oracle Clusterware - aka Grid Infrastructure - provides shared storage to servers and databases using Automated Storage Management (ASM). The storage itself is generally composed of raw/unpartitioned disks or LUNs mounted from a SAN or NAS device. Think of ASM as Oracle's own Logical Volume Management (LVM) solution for databases.

ASM is a required component of Oracle RAC, which allows horizontal scaling of database resources across multiple server compute nodes, without wholesale synchronization of data. All cluster nodes generally exist within the same local network subnet with very low latency communication (I used to work with one that used dedicated fiber channel to present the SAN storage). If one node fails, the others carry on the workload without interruption until the failed node restarts and rejoins the cluster.

Data Guard is a database-specific disaster recovery solution that replicates transaction logs between distinct databases (not instances within a RAC), usually in geographically-separated regions. It does not require shared storage; it simply pumps the transaction logs from one server to another and then applies them to a standby database. If one database (not node) fails, Data Guard fails operation over to the standby database and reverses the synchronization when the failed database is back online.

RAC with ASM also provides scaling capabilities that Data Guard does not. They are often used in conjunction to provide multiple layers of high-availability protection to business-critical applications.