Netapp Overview
Last updated
Last updated
Bottom level of the Netapp storage Architecture are called Disks. These are the hard drives themselves. (Storage Space)
These get grouped into Aggregates. An Aggregate is a set of physical disks.
One of the attributes for the Aggregates is the RAID group configuration.
If you check the GUI in NetApp on the Storage tab you can see an Aggregates tab where you can check how these are grouped and the RAID configuration, but there isn’t a RAID tab as this is a Aggregate feature.
Meaning that RAID Groups are configured on the Aggregate level.
The next level of this are the Volumes. This is the lowest level where users can access data at.
To summarize, Disks and Aggregates are physical resources, volumes are logical resources on top of that.
Moving up are the QTrees, the main function of these is to configure cotas. For example you could limit the total size of a QTree or you could limit the total space a user/group can use.
Once this has been configured the client will see it as a directory in that volume. You can also share a QTree.
The last component in the Storage Architecture is LUNs. (Logical unit numbers) This is used in SANs and it is the storage container that is going to be used for their storage.
LUNs can either go into a QTree or a Volume. LUNs are for for SAN protocols only.
Allows you to have one physical storage system, and create multiple Logical Storage Systems that are kept secure and separate from each other.
Disks and Aggregates are still shared in Virtualization on order to get the best use out of the storage space. (View it as dynamically allocated rather than fixed)
Furthermore let’s say you would like to create 2 environments (A&B)
You can allocate resources to both from the Physical Layer via Volumes, you can add QTrees and LUNs on top of that.
Both will have different IP addresses, namings and once logged onto the environment as a Admin you will be able to see only the environment that you are connected to.
A and B operate separate from each other and do not know of each other's existence. Unless configured otherwise.
VServers provide file-level data access by using NAS Protocols (CIFS, NFS) and block-level data access by using SAN Protocols. (iSCSI, FC, FCoE)
A LIF is an IP address associated with a physical port. If there is any component failure, a LIF can fail over to or be migrated to a different physical port, thereby continuing to communicate with the cluster.
LIFs can be placed on physical ports, interface groups or VLANs. Multiple LIFs can be placed on the same port.
LIFs can move to other nodes non-disruptivly.
A LIF keeps its IP address wherever it moves.
LIFs are owned by VServers (SVMs)
A LIF can have any one of the five roles:
Node Management
Cluster management
Cluster
Intercluster
Data
One node-management LIF exists per node (Meaning that it does not move nodes)
One cluster-management LIF which exists on the entire cluster. Usually 2 or more cluster LIFs exist per node The majority of port traffic goes over IP therefor they need an IP address as well. â—Ź Data LIFs serve client access over protocols such as NFS, CIFS (for NAS) and iSCSI or FC (for SAN)
For intercluster peering, intercluster LIFS must be created on each node (This is used for SNAP Mirror)
SnapMirror replicates data from a source volume or qtree to a partner destination volume or qtree respectively, by using Snapshot copies.
Before using SnapMirror to copy data you need to establish a relationship between the source and the destination.
NetApp Snapshot software is the foundation for SnapManager, SnapMirror, SnapRestore and SnapVault software. Together they create unified, all-risks protection for valuable data.
SnapMirror replicates data from a source volume or qtree to a partner destination volume or qtree respectively, by using Snapshot copies.
Before using SnapMirror to copy data you need to establish a relationship between the source and the destination.
Workflow:
Creates a Snapshot Copy of the data on the source volume
Copies it to the destination, which can be a read-only volume or qtree
Updates the destination to reflect incremental changes on the source, as per the schedule you specify.
The result of this process is an online read-only volume or qtree that contains the same data as the source at the time of the most recent update.
Each of the following replication methods consists of a pair of operation, one operation each at the source storage system and the destination storage system.
Volume SnapMirror replication
Qtree SnapMirror replication
SnapVault replication.
If a storage system is the source for one replication and the destination for another replication, iut uses two replication operations. Similar if a storage system is the source as well as the destination for the same replication, it uses two replication Operations.
HA (High-Availability Clusters) - Also known as Failover Clusters: Are groups of computers that support server applications that can be reliably utilized with a minimum amount of downtime.
They operate by using High-Availability Software to harness redundant computers in groups or clusters that provide continued service when system components fail.
NVRAM is more or less RAM with a backup in case of a power outage or “disaster events” .
All filers have a battery-backed NVRAM which allows them to commit writes to stable storage quickly without waiting on the disks.
Its primary mission is to preserve that not-yet-written data in care of a “disaster event”
How it works:
Acknowledgements are sent to clients as soon as the data is written to memory. This occurs before the data is written to disks themselves therefore optimising the performance.
As far as the client is concerned after the ack the data is written permanently to storage.
If we would be using DRAM (Dynamic RAM) in this case and there would be a power outage that data would be lost as RAM loses all data once there is no power in it.
NVRAM is Non-Volatile meaning it survives a power outage and the data can be recovered.
NVRAM will write the data back into System Memory and it will be written to disk from there in a Consistency Point.
The data is written to both controllers in a HA pair so that there is a takeover the HA peer can write the data to disk.
Client sends a write request to Controller 1 which is written in the System Memory and NVRAM. The PURPLE write request bumps down the previous System Memory requests and gets written on NVRAM.
This is also further written to Controller 2 into it’s NVRAM via an HA connection.
Once the data has been written to System memory and NVRAM of Controller 1 and into NVRAM on Controller 2, Controller 2 sends “ack” to Controller 1 which further sends an “ack” to the Client informing them that the data has been written permanently to storage (even tho it’s a lie at this point)
Once the NVRAM is about half full it gets written to the Aggregate or Disks (On the Physical Layer - when the data is actually permanently saved to storage)
This is written at half capacity because it takes some time to write the data on the physical disk itself and if this would be done when the NVRAM is full it would cause problems with incoming write requests.
After the data has been written the NVRAM will be flushed of that data in order to have additional space for future write requests.
In case of a Read request: Once a read request comes in, Controller 1 checks for the data on it’s system first, if it is there it serves it up to the requester, which is much faster then serving it up from disk.
After the data is served, all the data in System Memory gets bumped down on space, and the required data (Green in the case above) takes its place.
If the data is on the disk, the system will search the aggregates, will find the data and will serve it up to the user, the read request will be cached in the top slot of system memory and will be sent to the client.
If the client tries to access the data via Controler 2 this will check if it has the data in its System memory first, if it does not then it will go through a cluster interconnector to the Controller 1 (owner of the Aggregates) and will use up a slot in its system memory rather then using a slot in the initially accessed Controller.
This is good because any interrogated cluster will not use up its cache, it will only use the cache of the controller that owns the aggregate.
Read and Write requests work exactly the same way.
Controller 1 Failure: If Controler 1 fails Controller 2 will copy the pending rights from Controller 1 via HA and then they will be written down into the Aggregates in the next consistency point.
After that the NVRAM on Controller 2 will be flushed and the process can start over again.
WAFL is optimised for writes. It writes many operations to disk at once in a sequential CP (Consistency Point). It does not do separate writes to disk for each individual client request, instead it sends the ack back and writes all the data once the NVRAM is half full.
It’s called Write Anywhere File Layout because the data can be written anywhere on the disk, as it does not require writing of metadata to fixed locations.
This reduces the number of disk seek operations and improves performance.
Full Video on how it works: https://www.youtube.com/watch?v=q3kvRdc01jk