Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

NetApp Unified Storage Appliance report in Aperi - design document

Revision as of 04:00, 1 August 2007 by Simona constantin.ro.ibm.com (Talk | contribs) (Requirements narrowed down)

Create a new Unified Storage Appliance Report - initial requirements

NetApp devices represent themselves in three different ways (depending on customer usage). Combined, these are referred to as a Unified Storage Appliance. The three representations include:

  • Traditional NAS filer (appliance storage is presented to clients as mounted file shares)
  • FC block storage array (appliance provides FC attached blocks/volumes and looks just like a storage subsystem from this view)
  • iSCSI block storage array (appliance provides iSCSI attached target volumes)

However, Aperi's data server looks at NetApp appliances only as NAS filers, ignoring its other two personalities. To support a Unified Storage Appliance report, Aperi must gather information for all three representations.

The Aperi data component gathers information on NetApp from 2 sources

  • Aperi data agent which sees the mounted file systems or Shares via NFS or CIFS views from a client perspective
  • NetApp SNMP MIB from which we get some basic, high level asset and simple capacity information on the whole NetApp box.

There is a chance that this technique may produce inaccurate results.

The Unified Storage View needs to show the following type of capacity information (exact information and metrics will be determined DIRECTLY from what NetApp provides in their new vendor specific profile for this):

  1. Show Appliance capacities - raw, used, reserved storage
  2. Label logical volumes as NAS, FC, iSCSI, or unassigned
  3. Total storage capacity used for NAS, iSCSI, FCP Blocks, snapshot, snapshot reserve, free, and unallocated
  4. Asset Information will already be available through information gathered in NAS Self-Contained Profile
  5. Configuration information on NetApp such as RAID and Cache configurations

Note that all of the above information will be available directly through SMI-S extension(s) from NetApp. We will use our existing SMI-S support structure as a base and gather information from the new NetApp vendor specific profile(s). The intent is to create a new Unified Storage Appliance Report that simply shows any and all information that NetApp gives to us in the vendor specific profile. We will also request from NetApp, field titles and descriptions that we will directly map to the report. So, basically, we take whatever NetApp hands us in the new SMIS profile and slap it into a report. The new vendor specific profile is being created specifically for this report.

We may wish to augment the information provided in the new profile with data we gather from other profiles such as the Block Services Profile, the SMI-S Self-Contained NAS profile, etc.

Requirements narrowed down

Below are listed the items which, even though mentioned in the requirements section, will not be put in this report:

"Capacity - reserved storage", "Cache configuration" - These are not clearly defined in the requirements and it is difficult to give meaning to them only from their names
"Snapshot", "Snapshot Reserve" - NetApp SMI-S agent does not offer information about snapshots.
"Total storage capacity used for NAS" - NetApp SMI-S agent does not fill in the FileSize property of the CIM_LogicalFile so the sizes of the exported directories and files (i.e. storage capacity used for NAS) cannot be computed.

Everything else will be included in this report.

SMI-S agent data collection

Most of the data needed by this report is collected by the implementation of "Array" and "NAS Self Contained" profiles.

LUNs masking and mapping

Paths between iSCSI/FC initiators, LUNs and target ports are collected as part of LUN Masking and Mapping subprofile.

In the case of the iSCSI protocol the paths between LUNs and the initiator nodes are not saved in T_RES_DATA_PATH. This problem seems to get solved if the steps "collectSAPAvailableForElement" and "collectDeviceSAPImplementation" are moved before "collectProtocollControllerForUnit" in org.eclipse.aperi.disk.collection.ProbeGenericMaskingMappingProcess. Side effects must be analyzed

The main classes that implement LUNs Masking and Mapping subprofile are:

org.eclipse.aperi.disk.collection.ProbeGenericMaskingMappingProcess - defines and executes the steps necesserary for collecting the instances in LUN Masking and Mapping profile
org.eclipse.aperi.disk.collection.MappingMaskingProcessor - collects data from the steps exectuted be ProbeGenericMaskingMappingProcess and saves it in the repository by calling appropriate mappers

The collected data is put in T_RES_CLIENT_SETTING, T_RES_MASKING_INFO, T_RES_PORT and T_RES_DATA_PATH. The iSCSI node names are stored in T_RES_PORT. Side efects must be analyzed. T_RES_Port.FormatName is always 1. Should be changed to reflect the different types of names stored in this table ( FC WWN, iSCSI node names)

Corellation between Array Profile entities (storage extents, Pools, LUNs) and Self Contained NAS entities (filesystems)

The aggregate a volume resides on, will be found using storage extents, skipping over the logical disk.

A full path from a Filesystem (i.e volume which can be traditional or FlexVol) to its containing storage pool ( aggregate ) is represented in the following ways:

SMI-S specification

CIM_FileSystem ------- CIM_ResidesOnExtent ------- CIM_LogicalDisk
CIM_LogicalDisk ------ CIM_BasedOn --------------- CIM_StorageExtent
CIM_StorageExtent ---- CIM_ConcreteComponent ----- CIM_StoragePool

NetApp SMI-S Agent representation for a FlexVol

ONTAP_LocalFS ---------- ONTAP_LocalFSResidesOnExtent ------ ONTAP_LogicalDisk
ONTAP_LogicalDisk ------ ONTAP_FlexVolBasedOnExtent -------- ONTAP_FlexVolExtent
ONTAP_FlexVolExtent ---- ONTAP_ConcreteFlexVolComponent ---- ONTAP_ConcretePool

NetApp SMI-S Agent representation for a traditional volume

ONTAP_LocalFS ----------- ONTAP_LocalFSResidesOnExtent ---- ONTAP_LogicalDisk
ONTAP_LogicalDisk ------- ONTAP_BasedOn ------------------- ONTAP_ConcreteExtent
ONTAP_ConcreteExtent ---- ONTAP_ConcreteComponent --------- ONTAP_ConcretePool

The path between ONTAP_LocalFS and ONTAP_FlexVolExtent/ONTAP_ConcreteExtent can be shortcuted using the condition: ONTAP_LocalFS.Root == '/vol/'+ ONTAP_FlexVolExtent.Name for FlexVols and ONTAP_LocalFS.Root == '/vol/'+ ONTAP_ConcreteExtent.Name for traditional volumes.

ONTAP_FlexVolExtent/ONTAP_ConcreteExtent and their associations to ONTAP_Concrete Pools are collected by the Array Profile implementation and stored in T_RES_STORAGE_EXTENT and T_RES_STORAGE_POOL.

The storage extents containing volumes are collected in the step named "collectExtentsFromPool", which is a substep of "collectPoolsFromComputerSystem" (see org.eclipse.aperi.disk.collection.ProbeNetAppSubsystemProcess). The association used is ONTAP_ConcretePool (starting point):CIM_ConcreteComponent (association):CIM_StorageExtent (final point).

The FlexVolExtents are stored in the repository using the mapper org.eclipse.aperi.infrastructure.mapping.SMISONTAP_FlexVolExtentToDBMapper. The ONTAP_ConcreteExtent are stored using the mapper org.eclipse.aperi.infrastructure.mapping.SMISONTAP_ConcreteExtentToDBMapper.

The LUNs and the volumes they are part of will be correlated using the LUNs' names, volumes mount point and the serial number of their storage subsystem. The LUN names are in fact absolute file names of which prefix is the mount point of the volume. For example the LUN named /vol/vol0/lun0 is part of the WAFL filesystem mounted at /vol/vol0.

High level description of the report

I imagine the report as a series of drill down reports structured on four levels.

  1. The top level report displays general information about a NetApp storage subsystem. A row in this report has the following columns:
    1. two drill down icons for accessing "Volume Details" and "Aggregate Details" reports
    2. "Filer Name"
    3. "Capacity: Row Storage" - total disk capacities
    4. "Capacity: Assigned Storage" - sum of disk capacities already assigned to aggregates
    5. "Capacity: Free Space on Aggregates" - space that has not been consumed by the existing FlexVols and can be used to create new FlexVols. A traditional volume consumes all the space in its aggregate.
    6. "Capacity: Available Storage" - sum of hot spare disk capacities
  2. Second level reports
    1. Volume Details. Each row corresponds to a volume and contains the following columns:
      1. one drill down icon for accessing "Volume Content" report
      2. "Filer Name"
      3. "Volume Mount Point"
      4. "Volume Type" - flexible or traditional
      5. "Total Volume Space" -
      6. "Free Space" - free space on the volume
      7. "Space Occupied by LUNs" - total space assigned to LUNs
      8. "Number of LUNs" - number of LUNs created on this volume
      9. "Number of Share" - total number of files shares
      10. "Aggregate the Volume Resides On"
    2. Aggregate Details. The columns of this report are:
      1. "Filer Name"
      2. "Aggregate Name",
      3. "Aggregate Raid Level"
      4. "Aggregate Total Space"
      5. "Aggregate Free Space"
      6. "Number of disks in the Aggregate"
  3. Volume Content. Describes the file shares and LUNs that are part of the volume. The columns of this report are:
    1. drill down icon that will be activated only if the row represents a LUN that is mapped to hosts. This icon will drill down to the "LUNs Mapping Details"
    2. "Filer Name"
    3. "Volume Mount Point"
    4. "LUN/Share Name" - LUN name, which is an absolute file name or the export name ( the name with which a file/directory is exported/shared )
    5. "Protocol" - CIFS or/and NFS for shares and iSCSI or/and FC for LUNs. A file can be shared using both CIFS and NFS and a LUN can be mapped both through FC and iSCSI.
    6. "Allocated Space" - for exported files and directories this will be "N/A" for LUNs will represent the LUN's capacity
  4. LUNs Mapping Details. Displays what FC initiator ports or iSCSI initiator nodes have access to this LUN.
    1. "Filer Name"
    2. "Volume Mount Point"
    3. "LUN Name"
    4. "Protocol"
    5. "Host Node/Port name"

Implementation details

Device Server

Steps "collectSAPAvailableForElement" and "collectDeviceSAPImplementation" will be moved before "collectProtocollControllerForUnit", in org.eclipse.aperi.disk.collection.ProbeGenericMaskingMappingProcess. Side effects must be analyzed.

I need to analyze further the side effects caused by storing the iSCSI node names in T_RES_PORT.

Gui and Data Server

The class org.eclipse.aperi.TStorm.server.guireq.GuiReportReq will be extended to support a new type of report, which will have five subtypes:

/** New Report type */

public static final int NETAPP_UNIFIED_STORAGE = 88

/** NETAPP_UNIFIED_STORAGE subreports */

public static final int NETAPP_UNIFIED_STORAGE_MAIN = 112;

public static final int NETAPP_UNIFIED_STORAGE_VOLUMES = 113;

public static final int NETAPP_UNIFIED_STORAGE_AGGR = 114;

public static final int NETAPP_UNIFIED_STORAGE_VOLCONTENT = 115;

public static final int NETAPP_UNIFIED_STORAGE_LUNS = 116;

Following classes will be added to support the new report:

org.eclipse.aperi.TStorm.gui.NetAppUnifiedStorageTable - GUI tables for displaying the reports
org.eclipse.aperi.TStorm.common.NetAppUnifiedStorageAdjuster - is the data model behind NetAppUnifiedStorageTable
org.eclipse.aperi.repository.report.RptNetAppUnifiedStorageReport - this class is instantiated in DataServer and executes the queries against the database to extract the data. In this class the queries for each subtype of the NetaApp Unified Storage report are defined and executed.

New serialaizible objects will be defined only if needed to transfer data between Data Server and GUI. (I will add details here as I develop the code)

Glossary

This document blends together NetApp, SMI-S and Aperi terms and I hope that this glossary will clarify their intended meaning .

aggregate 
It is the highest level that Data ONTAP uses for grouping disks. Lower levels are plexes and RAID groups, which are the basis for an aggregate. A volume is created on an aggregate. An aggregate is described by NetApp SMI-S agent using an instance of CIM_StoragePool and is represented as a storage pool in Aperi.
filer 
A shorthand for a NetApp storage system
file share 
A directory or a file that is made available by a filer to clients through NFS or CIFS protocol
FlexVol 
A FlexVol is a type of volume that shares its containing aggregate with many other FlexVols.
hot spare disk 
It is a disk that has not been added yet to any aggregates and can be used to extend an aggregate, to create a new aggregates or to replace a failed disk in an aggregate. Data Ontap replaces automatically a failed disk with one of the hot spare disks.
LUN  
Logical unit of storage. Storage Volume and LUNs have equivalent meaning.
LUN masking
LUN mapping
Data ONTAP 
It is the operating system which manages a NetApp storage system.
plex 
It is an assembly of RAID groups. Data ONTAP manages mirroring at plex level. An aggregate has only one plex when it is unmirrored and two plexes when it is mirrored.
Traditional Volume 
A traditional volume is a volume that occupies by itself an entire aggregate.
volume 
It is a Data ONTAP file system of type WAFL. The LUNs are created on a volume as files but exposed as block storage space. The file shares are also part of a volume. gives to us in the vendor specific profile. A volume is represented by NetApp SMI-S agent using an instance of CIM_FileSystem.

Back to the top