04 Architecture SG PDF

Module 4
Architecture
NetApp Confidential
MODULE 4: ARCHITECTURE
4-1
Clustered Data ONTAP Administration: Architecture
2013 NetApp, Inc. This material is intended only for training. Reproduction is not authorized.
Module Objectives
After this module, you should be able to:
Show the end-to-end path of a file write
request through a cluster
Answer questions about replicated database
(RDB) concepts
Identify the differences between a vol0 root
volume and a data virtual storage server
(Vserver) root volume
NetApp Confidential
MODULE OBJECTIVES
4-2
Lesson 1
NetApp Confidential
LESSON 1
4-3
Components
Three major software components on every
node:
The network module
The data module
The SCSI module
Other key software components on every

node:
The cluster session manager (CSM)
The replicated database units (RDB)
NetApp Confidential
COMPONENTS
The modules refer to separate software state machines that are accessed only by well defined APIs. Every
node contains a network module, a SCSI module, and a data module. Any network or SCSI module in the
cluster can talk to any data module in the cluster.
The network module and the SCSI module translate client requests into Spin Network Protocol (SpinNP)
requests and vice versa. The data module, which contains the WAFL (Write Anywhere File Layout) file
system, manages SpinNP requests. The cluster session manager (CSM) is the SpinNP layer between the
network, SCSI, and data modules. The SpinNP protocol is another form of RPC interface. It is used as the
primary intranode traffic mechanism for file operations among network, SCSI, and data modules.
The members of each replicated database (RDB) unit on every node in the cluster are in constant
communication with each other to remain synchronized. The RDB communication is like the heartbeat of
each node. If the heartbeat cannot be detected by the other members of the unit, the unit corrects itself in a
manner that is discussed later in this course. The four RDB units on each node are the blocks configuration
and Operations Manager (BCOM), the volume location database (VLDB), VifMgr, and management.
4-4
Single Node Components (Illustrated)

Node
Network and
SCSI
modules
Client Access (Data)
Management
M-Host
Cluster Traffic
CSM
Data
module
RDB Units:
Mgwd
VLDB
VifMgr
BCOM
Data Vserver
Root Volume
Vol0
Root
Vol1
Vol2
NetApp Confidential
SINGLE NODE COMPONENTS (ILLUSTRATED)
4-5
The Network Module

Manages networking, NFS, and CIFS
Speaks:
TCP/IP and UDP/IP
NFS and CIFS
SpinNP
NetApp Confidential
THE NETWORK MODULE
4-6
The SCSI Module

Manages networking, FC, Fibre Channel over
Ethernet (FCoE), and iSCSI
Speaks:
FC
SCSI
SpinNP
TCP/IP
NetApp Confidential
THE SCSI MODULE
4-7
The Data Module

Manages the WAFL (Write Anywhere File
Layout) file system, RAID, and storage
Speaks:
SpinNP
FC and SAS to disk and tape devices
NetApp Confidential
THE DATA MODULE
4-8
The CSM
Provides a communication mechanism
between any network or SCSI module and
any data module
Provides a reliable transport for SpinNP traffic
Is used regardless of whether the network or
SCSI module and the data module are on the
same node or on different nodes
NetApp Confidential
THE CSM
4-9
The Path of a Local Write Request

Node1
Requests
Responses
Node2
Network and
SCSI
modules
Network and
SCSI
modules
CSM
CSM
Data
module
Data
module
NAS and SAN

Clients
Vol0
Root
Vol1
Vol2
Root
Vol 1
NetApp Confidential
Vol0
Vol3
Vol4
10
THE PATH OF A LOCAL WRITE REQUEST

A NAS or SAN client sends a write request to a data logical interface (LIF). The network module (NAS) or
SCSI module (SAN) that is currently associated with that LIF translates the NFS or CIFS (NAS), FC, FCoE,
or iSCSI (SAN) request to a SpinNP request. The SpinNP request goes through the CSM to the local data
module. The data module sends the data to nonvolatile RAM (NVRAM) and to the disks. The response works
its way back to the client.
4-10
The Path of a Remote Write Request

Node1
Requests
Responses
Node2
Network and
SCSI
modules
Network and
SCSI
modules
CSM
CSM
Data
module
Data
module
NAS and SAN

Clients
Vol0
Root Root
Vol1
Vol 1
Vol2
NetApp Confidential
Vol0
Vol3
Vol4
11
THE PATH OF A REMOTE WRITE REQUEST

A NAS or SAN client sends a write request to a data LIF. The network module or SCSI module that is
currently associated with that LIF translates the NFS or CIFS, FC, FCoE, or iSCSI request to a SpinNP
request. The SpinNP request goes through the CSM to the remote data module by means of the remote CSM.
The data module sends the data to NVRAM and to the disks. The response works its way back to the client.
4-11
Clustered Data ONTAP Modules

NAS
The network module:
Network
Module
SAN
Module
Network
Module
SAN
Module
Network
Module
SAN
Module
Cluster Interconnect
Network
Module
SAN
Module
WAFL
RAID
Storage
Is called the N-blade
N
V
R
A
M
WAFL
Provides NAS protocols
The SCSI module:

Is called the SCSI-blade
RAID
Storage
Provides SAN protocols
The data module:

WAFL
RAID
Storage
Is called the D-blade
N
V
R
A
M
WAFL
Provides storage access

to shelves (WAFL file
system, RAID
subsystems, and storage
shelves subsystems)
RAID
Storage
NetApp Confidential
CLUSTERED DATA ONTAP MODULES
4-12
12
CSM
Data ONTAP Architecture

Cluster Traffic
Data module
Network and SCSI

modules
Network
Protocols
WAFL
RAID
Storage
Clients
To HA partner
Physical
Memory
NVRAM
Management
NetApp Confidential
DATA ONTAP ARCHITECTURE
4-13
13
The Vol0 Volume

Contains data for managing the node and
cluster:
Is used for RDB databases and log files
Doesnt contain user or client data
Cannot be accessed by NAS or SAN clients

Exists on every nodeone vol0 per node
Must not be confused with the root volume of
a data Vserver
Cannot be mirrored, moved, or backed up
Can be re-created after a disaster
NetApp Confidential
14
THE VOL0 VOLUME

The vol0 volume of a node is analogous to the root volume of a Data ONTAP 7G operating system. The vol0
volume contains the data that is needed for the node to function.
The vol0 volume does not contain any user data, nor is it part of the namespace of a Vserver. The vol0
volume resides permanently on the initial aggregate that is created when each node is initialized.
The vol0 volume is not protected by mirror relationships or tape backups, which is valid. Although vol0 is an
important volume (a node cannot boot without its vol0 volume), the data that is contained on vol0 is largely
re-creatable. If the data is lost, the log files are indeed gone. But because the RDB data is replicated on every
node in the cluster, that data can be automatically re-created on this node.
4-14
Data Vservers
1 of 2
Formerly known as cluster Vservers

Are virtual entities within a cluster
Can coexist with other cluster data Vservers
in the same cluster
Are independent of nodes
Are independent of aggregates
Contain all the volumes of their namespaces
NetApp Confidential
15
DATA VSERVERS: 1 OF 2
Think of a cluster as a group of hardware elements (nodes, disk shelves, and more). A data Vserver is a
logical piece of that cluster, but a Vserver is not a subset or partitioning of the nodes. A Vserver is more
flexible and dynamic. Every Vserver can use all the hardware in the cluster, and all at the same time.
Example: A storage provider has one cluster and two customers: ABC Company and XYZ Company. A
Vserver can be created for each company. The attributes that are related to specific Vservers (volumes, LIFs,
mirror relationships, and others) can be managed separately, while the same hardware resources can be used
for both. One company can have its own NFS server, while the other can have its own NFS, CIFS, and iSCSI
servers.
4-15
Data Vservers
2 of 2
Represent unique namespaces

Can and should have multiple data logical
interfaces (LIFs), each of which is associated
with one Vserver
Can and do have multiple volumes, each of
which is associated with one Vserver
NetApp Confidential
16
DATA VSERVERS: 2 OF 2
A one-to-many relationship exists between a Vserver and its volumes. The same is true for a Vserver and its
data LIFs. Data Vservers can have many volumes and many data LIFs, but those volumes and LIFs are
associated only with this one data Vserver.
4-16
Building a Namespace with Volumes and

Junctions
R
A Data ONTAP Cluster
G H
A
B
C
R
G
R is the root of a data Vserver.

A, B, C, and F are mounted to R through junctions.
D and E are mounted to C through junctions.

G and H are mounted to F through junctions.
NetApp Confidential
17
BUILDING A NAMESPACE WITH VOLUMES AND JUNCTIONS

These nine volumes are mounted together through junctions. All volumes must have a junction path
(mountpoint) to be accessible within the Vservers namespace.
Volume R is the root volume of a Vserver. Volumes A, B, C, and F are mounted to R through junctions.
Volumes D and E are mounted to C through junctions. Likewise, volumes G and H are mounted to F.
Every Vserver has its own root volume, and all nonroot volumes are created within a Vserver. All nonroot
volumes are mounted into the namespace, relative to the Vserver root.
In this example if volume C goes offline, clients who are mounted to R or C will not be able to access D or E.
Clients who are mounted directly to D or E will have uninterrupted access to D or E.
4-17
Vservers, Namespaces, and Volumes

PopCo
PetCo
RonCo
QuekCo
Namespace
Namespace
Namespace
Namespace
Vserver
Root
Vserver
Root
Vserver
Root
Volume
Volume
Vserver
Root
Volume
Volume
Volume
Volume
NetApp Confidential
18
VSERVERS, NAMESPACES, AND VOLUMES

NOTE: This slide is a representation of logical concepts and is not meant to show any physical relationships.
For example, all of the objects that are shown as part of a Vserver are not necessarily on the same physical
node of the cluster. In fact, that situation is unlikely.
This slide shows four distinct Vservers and namespaces. Although the hardware is not shown, these four
Vservers might reside in a single cluster. These namespaces are not separate entities of the Vservers but are
shown merely to indicate that each Vserver has a namespace. The volumes, however, are separate entities.
Each volume is associated with one Vserver. Each Vserver has one root volume, and some Vservers have
additional volumes. Although a Vserver might have only one volume (the Vservers root volume), in real life,
it is more likely that a Vserver consists of multiple volumes, possibly thousands. Typically, a new volume is
created for every distinct area of storage. For example, every department and employee might have volume
separate volume in a Vserver.
4-18
Namespaces
A namespace is the file system of a data
Vserver.
A namespace consists of many volumes.
A namespace is independent of the
namespaces of other data Vservers.
The root of the namespace is the cluster
data Vserver root volume.
A client mount or mapping can be to the data
Vserver root volume or to a point further into
the tree.
NetApp Confidential
19
NAMESPACES
A namespace is a file system. A namespace is the external, client-facing representation of a Vserver. A
namespace consists of volumes that are joined together through junctions. Each Vserver has one namespace,
and the volumes in one Vserver cannot be seen by clients that are accessing the namespace of another
Vserver.
4-19
The Data Vserver Root Volume

Exists on each data Vserverone per
data Vserver
Is the root of the data Vserver namespace
Is a normal flexible volume
Contains junctions
Can be moved, copied, and backed up
Can have Snapshot copies
Is usually mirrored
NetApp Confidential
20
THE DATA VSERVER ROOT VOLUME

Each Vserver has one namespace and, therefore, one root volume. This volume is separate from the vol0
volume of each node.
4-20
Lesson 2
NetApp Confidential
LESSON 2
4-21
21
The RDB
The RDB is the key to maintaining highperformance consistency in a distributed
environment.
The RDB maintains data that supports the cluster,
not the user data in the namespace.
Operations are transactional (atomic): entire
transactions are either committed or rolled back.
Four RDB units exist: the volume location
database (VLDB), management, VifMgr, and
blocks configuration and operations manager
(BCOM).
NetApp Confidential
22
THE RDB
The RDB units do not contain user data. The RDB units contain data that helps to manage the cluster. These
databases are replicated; that is, each node has its own copy of the database, and that database is always
synchronized with the databases on the other nodes in the cluster. RDB database reads are performed locally
on each node, but an RDB write is performed to one master RDB database, and then those changes are
replicated to the other databases throughout the cluster. When reads of an RDB database are performed, those
reads can be fulfilled locally without the need to send requests over the cluster interconnects.
The RDB is transactional in that the RDB guarantees that when data is written to a database, either it all gets
written successfully or it all gets rolled back. No partial or inconsistent database writes are committed.
Four RDB units (the VLDB, management, VifMgr, and BCOM) exist in every cluster, which means that four
RDB unit databases exist on every node in the cluster.
4-22
Management Gateway
Is also known as the M-host
Enables management of the cluster from any
node
Provides the CLI
Runs as mgwd (the management gateway
daemon) on every node
Stores its data in the management RDB unit
NetApp Confidential
23
MANAGEMENT GATEWAY
The management RDB unit contains information that is needed by the management gateway daemon (mgwd)
process on each node. The kind of management data that is stored in the RDB is written infrequently and read
frequently. The management process on a given node can query the other nodes at run time to retrieve a great
deal of information, but some information is stored locally on each node, in the management RDB database.
4-23
Volume Location Database

The VLDB is:
One of the RDB units
An index of which aggregate owns a volume
An index of which node hosts an aggregate
VLDB content is cached in memory on each

node for instant access by each network and
SCSI module to speed up the lookup process
during data access by clients.
NetApp Confidential
24
VOLUME LOCATION DATABASE

Although each RDB unit consists of a process and a database on each node in the cluster, an RDB unit is
considered a single entity. One of the RDB units is the VLDB.
The VLDB tracks where the volumes and aggregates are.
Because the VLDB is potentially referenced (read) frequently for client requests, the VLDB content is cached
in memory on each node so that the network and SCSI modules can avoid RDB lookups during client
requests.
4-24
VIF Manager
Runs as vifmgr
Stores and monitors LIF configuration
Stores and administers LIF failover policies
NetApp Confidential
25
VIF MANAGER
The VifMgr is responsible for creating and monitoring NFS, CIFS, and iSCSI LIFs. It also handles automatic
NAS LIF failover and manual migration of NAS LIFs to other network ports and nodes.
4-25
Blocks Configuration and Operations

Management
Runs as bcomd
Stores LUN map definitions
Stores initiator groups (igroups)
NetApp Confidential
26
BLOCKS CONFIGURATION AND OPERATIONS MANAGEMENT

The BCOM RDB unit hosts the SAN ring that contains the replicated configuration information data for block
data access, including LUN maps and initiator groups( igroups).
4-26
The RDB: Details

1 of 2
Each RDB unit has its own replication ring.

For each of the units, one node is the master
and the other nodes are secondaries.
The master node for each unit might be
different than the master nodes for the other
units.
Writes for an RDB unit go to its master and
are then propagated to the secondaries
through the cluster interconnect.
NetApp Confidential
27
THE RDB: DETAILS: 1 OF 2

Each RDB unit has its own ring. An RDB ring is the total of all RDB units of each type across the cluster. For
example, in an eight-node cluster, the eight vldb units make up the vldb ring. Each of the four RDB rings
elects a master. The master is considered the "official" copy of the database in case of discrepancies.
If n is the number of nodes in the cluster, each unit or ring consists of n databases and n processes. At any
given time, one of those databases is designated as the master, and the others are designated as secondary
databases. Each RDB units ring is independent of the other RDB units. For example, if node X has the
master database for the VLDB unit, node Y might have the master for the VifMgr unit, and node Z might
have the master for the management unit and the BCOM unit.
The master of a given unit can change. For example, when the node that is the master for the management
unit is booted, a new management master must be elected by the remaining members of the management unit.
Note that a secondary can become a master and a master can become a secondary. Nothing is special about
the database itself; the database that is designated as the master is the role of the process that manages the
database (master versus secondary).
When data must be written to a unit, the data is written to the database on the master, and then the master
immediately replicates the changes to the secondary databases on the other nodes. If a change cannot be
replicated to a specific secondary, the entire change is rolled back everywhere, which is what no partial
writes means. Either all databases of an RDB unit get the change, or none gets the change.
4-27
The RDB: Details

2 of 2
An RDB unit is considered to be healthy only
when it is in quorum (when a master can be
elected).
In quorum means that a simple majority of
nodes are communicating with each other.
When the quorum is lost or regained, the master
might change.
If a master has communication issues, a new
master is elected by the members of the unit.
One node has a tie-breaking ability (epsilon) for
all RDB units.
NetApp Confidential
28
THE RDB: DETAILS: 2 OF 2

RDB Terminology and Definitions
A master can be elected only when a quorum of member nodes is available (and healthy) for a particular RDB
unit. Each member votes for the node that it thinks should be the master for this RDB unit. One node in the
cluster has a special tie-breaking ability called epsilon. Unlike the master, which might be different for each
RDB unit, epsilon is a single node that applies to all RDB units.
Quorum means that a simple majority of nodes are healthy enough to elect a master for the unit. The epsilon
power is used only in the case of a voting tie. If a simple majority does not exist, the epsilon node (process)
chooses the master for a given RDB unit.
When cluster communication is interruptedfor example, because of a booting or a cluster interconnect
hiccup that lasts for a few secondsa unit goes out of quorum. When the cluster communication is restored,
the unit comes back into quorum automatically.
4-28
RDB Databases
node1
node2
mgwd VLDB VifMgr BCOM
node4
node3
NetApp Confidential
29
RDB DATABASES
This slide shows a four-node cluster. The four databases that are shown for each node are the four RDB units
(management, VLDB, VifMgr, and BCOM). Each unit consists of four distributed databases. Each node has
one local database for each RDB unit.
The databases that are shown on this slide with dark borders are the masters. Note that the master of any
particular RDB unit is independent of the master of the other RDB units.
The node that is shown on this slide with a dark border has epsilon (the tie-breaking ability).
On each node, all the RDB databases are stored in the vol0 volume.
4-29
Quorum
1 of 2
A quorum is a simple majority of connected, healthy, and
eligible nodes.
Two RDB quorum concepts exist: a cluster-wide quorum
and an individual RDB unit that is in or out of quorum.
RDB units never go out of quorum as a whole; only local
units (processes) do.
When an RDB unit goes out of quorum, reads from the
RDB unit can still occur, but changes to the RDB unit
cannot.
Example: If the VLDB goes out of quorum, during the brief
time that the database is out, no volumes can be created,
deleted, or moved; however, access to the volumes from
clients is not affected.
NetApp Confidential
30
QUORUM: 1 OF 2
A master can be elected only when a majority of local RDB units are connected and healthy for a particular
RDB unit on an eligible node. A master is elected when each local unit agrees on the first reachable healthy
node in the RDB site list. A healthy node is one that is connected, can communicate with the other nodes,
has CPU cycles, and has reasonable I/O.
The master of a given unit can change. For example, when the node that is the master for the management
unit is booted, a new management master must be elected by the remaining members of the management unit.
A local unit goes out of quorum when cluster communication is interrupted for a few seconds, for example,
because of a booting or a cluster interconnect hiccup that lasts for a few seconds. Because the RDB units
always work to monitor and maintain a good state, the local unit comes back in quorum automatically. When
a local unit goes out of quorum and then comes back into quorum, the RDB unit is synchronized again. Note
that the VLDB process on a node might go out of quorum although the VifMgr process on that same node has
no problem.
When a unit goes out of quorum, reads from that unit can be performed, but writes to that unit cannot. That
restriction is enforced so that no changes to that unit happen during the time that a master is not agreed upon.
In addition to the example above, if the VifMgr goes out of quorum, access to LIFs is not affected, but no LIF
failover can occur.
4-30
Quorum
2 of 2
The members of each RDB unit vote to

determine which node will be their master;
each unit elects its own master.
Each master might change when a local unit
goes out of and into quorum.
Before you take a node down for an extended
period of time, you should mark it as ineligible
(so the node doesnt factor into quorum):
cluster1::> system node modify node
<node> -eligibility false
NetApp Confidential
31
QUORUM: 2 OF 2
Marking a node as ineligible (by using the cluster modify command) means that the node no longer
affects RDB quorum or voting. If you mark the epsilon node as ineligible, epsilon is automatically given to
another node.
4-31
The Epsilon Node

When half of the nodes in a cluster are
isolated from the other half, no simple majority
exists.
NOTE: This situation is rare.
One node has a weighted vote (epsilon).

The epsilon node is epsilon for the entire
cluster, not only for individual RDB units (such
as the masters).
NetApp Confidential
32
THE EPSILON NODE

One node in the cluster has a special voting weight called epsilon. Unlike the masters of each RDB unit,
which might be different for each unit, the epsilon node is the same for all RDB units. This epsilon vote is
used only in the case of an even partitioning of a cluster, where, for example, four nodes of an eight-node
cluster cannot talk to the other four nodes. This situation is rare, but in this situation, a simple majority does
not exist, and the epsilon node sways the vote for the masters of the RDB units.
4-32
Which Cluster Is In Quorum?
4+
2+
NetApp Confidential
WHICH CLUSTER IS IN QUORUM?
4-33
33
Two-Node Clusters
Two-node clusters are a special case:
No majority exists in the event of a cluster
interconnect partition or during a failover
situation.
The RDB manages this case under the
covers but must be told that this cluster
contains only two nodes.
cluster1::> cluster ha modify configured true
See TR3450 for more information
NetApp Confidential
34
TWO-NODE CLUSTERS
From Ron Kownacki, author of the RDB:
Basically, quorum majority doesnt work well when down to two nodes and theres a failure, so RDB is
essentially locking the fact that quorum is no longer being used and enabling a single replica to be artificially
writable during that outage.
The reason we require a quorum (a majority) is so that all committed data is durable: if you successfully
write to a majority, you know that any future majority will contain at least one instance that has seen the
change, so the update is durable. If we didnt always require a majority, we could silently lose committed
data. So in two nodes, the node with epsilon is a majority and the other is a minorityso you would only
have one-directional failover (need the majority). So epsilon gives you a way to get majorities where you
normally wouldnt have them, but it only gives unidirectional failover because its static.
In two-node (high-availability mode), we try to get bidirectional failover. To do this, we remove the
configuration epsilon and make both nodes equaland form majorities artificially in the failover cases. So
quorum is two nodes available out of the total of two nodes in the cluster (no epsilon involved), but if theres
a failover, you artificially designate the survivor as the majority (and lock that fact). However, that means you
cant fail over the other way until both nodes are available, they sync up, and drop the lockotherwise you
would be discarding data.
4-34
Putting It All Together

Node
Network and
SCSI
modules
Client Access (Data)
Management
M-Host
Cluster Traffic
CSM
Data
module
Data Vserver
Root Volume
Vol0
RDB Units:
Mgwd
VLDB
VifMgr
BCOM
Root
Vol1
Vol2
NetApp Confidential
PUTTING IT ALL TOGETHER
4-35
35
Module Summary
Now that you have completed this module, you
should be able to:
Show the end-to-end path of a file write
request through a cluster
Answer questions about replicated database
(RDB) concepts
Identify the differences between a vol0 root
volume and a data virtual storage server
(Vserver) root volume
NetApp Confidential
MODULE SUMMARY
4-36
36
Exercise
Module 4: Architecture
Time Estimate: 15 Minutes
NetApp Confidential
EXERCISE
Please refer to your exercise guide.
4-37
37

04 Architecture SG PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

04 Architecture SG PDF

Transféré par

Droits d'auteur :

Formats disponibles

Module 4

Clustered Data ONTAP Administration: Architecture

Clustered Data ONTAP Administration: Architecture

Clustered Data ONTAP Administration: Architecture

Other key software components on every

Clustered Data ONTAP Administration: Architecture

Single Node Components (Illustrated)

Client Access (Data)

SINGLE NODE COMPONENTS (ILLUSTRATED)

Clustered Data ONTAP Administration: Architecture

The Network Module

THE NETWORK MODULE

Clustered Data ONTAP Administration: Architecture

The SCSI Module

THE SCSI MODULE

Clustered Data ONTAP Administration: Architecture

The Data Module

THE DATA MODULE

Clustered Data ONTAP Administration: Architecture

Clustered Data ONTAP Administration: Architecture

The Path of a Local Write Request

NAS and SAN

THE PATH OF A LOCAL WRITE REQUEST

Clustered Data ONTAP Administration: Architecture

The Path of a Remote Write Request

NAS and SAN

THE PATH OF A REMOTE WRITE REQUEST

Clustered Data ONTAP Administration: Architecture

Clustered Data ONTAP Modules

The network module:

Is called the N-blade

Provides NAS protocols

The SCSI module:

Provides SAN protocols

The data module:

Is called the D-blade

Provides storage access

CLUSTERED DATA ONTAP MODULES

Clustered Data ONTAP Administration: Architecture

Data ONTAP Architecture

Network and SCSI

DATA ONTAP ARCHITECTURE

Clustered Data ONTAP Administration: Architecture

The Vol0 Volume

Cannot be accessed by NAS or SAN clients

THE VOL0 VOLUME

Clustered Data ONTAP Administration: Architecture

Formerly known as cluster Vservers

Clustered Data ONTAP Administration: Architecture

Represent unique namespaces

Clustered Data ONTAP Administration: Architecture

Building a Namespace with Volumes and

A Data ONTAP Cluster

R is the root of a data Vserver.

D and E are mounted to C through junctions.

BUILDING A NAMESPACE WITH VOLUMES AND JUNCTIONS

Clustered Data ONTAP Administration: Architecture

Vservers, Namespaces, and Volumes

VSERVERS, NAMESPACES, AND VOLUMES

Clustered Data ONTAP Administration: Architecture

Clustered Data ONTAP Administration: Architecture

The Data Vserver Root Volume

THE DATA VSERVER ROOT VOLUME