EMC - VNX2 - Snapview Snapshot

1. Usefull Link

EMC VNX – SnapView Overview

VNX Video: SnapView

Creating SnapView Clones with naviseccli

2. Overview

VNX SnapView snapshots are a view of the data and not the actual data itself. As a result, creating a Snapshot and starting a session is a very quick process, requiring only a few seconds. The view that is then presented to the secondary host is a frozen copy of the source LUN as the primary host saw it at the time the session was started. The SnapView snapshot is writable by the secondary host, but any changes made to it are discarded if the SnapView snapshot is deactivated.
A SnapView snapshot is a composite of the unchanged data chunks on the source LUN and data chunks on a LUN called “Reserved LUN”. Before chunks of data are written to the source LUN, they are copied to a reserved area in private space, and the memory map is updated with the new location of these chunks. This process is referred to as Copy on First Write. The Copy On First Write Mechanism (COFW) uses pointers to track whether data on the source LUN, or in the Reserved LUN Pool. These pointers are kept in SP memory, which is volatile, and could therefore be lost if the SP should fail or the LUN be trespassed. A SnapView feature designed to prevent this loss of session metadata is persistence for sessions (which stores the pointers on the Reserved LUN(s) for the session). All sessions are automatically persistent and the user cannot turn off persistence.
The SnapView snapshot can be made accessible to a secondary host, but not to the primary host (unless software that allows simultaneous access, like EMC Replication Manager, is used).

A VNX is required hardware for using SnapView snapshots. If a host is to access the SnapView snapshot, two or more hosts are required; one primary host to access the VNX source LUN and one or more additional secondary hosts to access the SnapView snapshot of the source LUN.
The Admsnap program runs on host system in conjunction with SnapView running on the EMC VNX storage processors (SPs), and allows the user to start, activate, deactivate, and stop SnapView sessions. The Admsnap utility is an executable program (Command line) that the user can run interactively or with a script. This utility ships with the SnapView enabler.

The source LUN, the SnapView session, and the reserved LUN work together to create the SnapView snapshot. The SnapView snapshot is made visible to a secondary host when is activated to a SnapView session (given that a SnapView snapshot has been defined and has been added to a storage group connected to the secondary host).

The copy on first write mechanism (COFW) involves saving an original data area from the source LUN into a special save area (Reserved LUN) when that data area on the active LUN is about to be changed. The official term for that data area is a ‘chunk’ – a 64 KB piece of contiguous data.
The chunk is saved only once per session. This ensures that the view of the LUN is consistent and, unless writes are made to the SnapView snapshot, is always a true indication of what the LUN looked like at the time it was snapped (the session was started).
Saving only chunks that have been changed allows efficient use of the disk space available – whereas a full copy of the LUN would use additional space equal in size to the active LUN, a SnapView snapshot may use as little as 20% of the space, on average. This depends greatly, of course, on how long the SnapView snapshot needs to be available and how frequently data changes on the source LUN and the SnapView snapshot.
Saving original blocks also means that SnapView can roll a source LUN back to a previous point in time. This may be useful for fast recovery from corruption of the source LUN.

Due to the dynamic nature of reserved LUN assignment per source LUN, it may be better to have many smaller LUNs that can be used as a pool of individual resources. A limiting factor here is that the total number of reserved LUNs allowed varies by storage system model.

• Each reserved LUN can be a different size, and allocation to source LUNs is based on which is the next available reserved LUN, without regard to size. This means that there is no mechanism to ensure that a specified reserved LUN will be allocated to a specified source LUN. Because of the dynamic nature of the SnapView environment, assignment may be regarded as a random event (though, in fact, there are rules governing the assignment of reserved LUNs).

• The Reserved LUN Pool can be configured with thick pool LUNs or classic LUNs only. Pool LUNs that are created as Thin LUNs cannot be used in the RLP.

• The combination of these factors makes the sizing of the reserved LUN pool a non-trivial task – particularly when Incremental SAN Copy and MirrorView/A are used along with Snapshots.

• It is expected that 10% of the data on the source LUN changes while the session is active. Creating 2 RLs per Source LUN allows for a safety margin - it allows twice the expected size, for a total of 20%.

• This example shows a total of 160 GB to be snapped, with eight reserved LUNs totaling 32 GB.

• The user may obtain reserved LUN pool statistics by viewing the properties of the reserved LUN pool. At-a-glance information presented includes the amount of space used and the amount of free space. Warnings about LUN pool usage are available in the SP Event Log and may also be available elsewhere, if configured by the user. Some performance related information, of the type available from Unisphere Analyzer, may be accessed from the GUI.

• Once the LUN Pool has been populated, a next step is to flag all required LUNs as Snapshot source LUNs. This is performed by creating snapshots of those LUNs, or starting sessions on those LUNs, which changes the LUN state from a regular LUN to a Snapshot Source LUN. The changed state is stored on the PSM LUN, so that it survives power cycles. Destruction of the SnapView snapshots and sessions associated with a source LUN return it to ‘standard’ LUN status and that change is also recorded on the PSM LUN. Here the source LUN returns to the regular LUN state.

Note that the calculation shown here is a compromise. Different results are obtained if the goal is to minimize the number of reserved LUNs or to minimize the wasted space in the reserved LUN pool. Also note that the Snapshot Wizard creates larger reserved LUNs by default. It is dealing with a potentially less-experienced user and leaves more overhead for safety.

Here we see the different host I/O types that may be directed at a Snapshot. Note that if there is no active session on the Snapshot, it appears off-line to the host, and the host operating system raises an error if an attempt is made to access it.
If a session is active, the SnapView driver needs to perform additional processing. Reads may require data to be read from the reserved LUN pool or the source LUN, and the driver needs to consult the memory map to determine where the data chunks are located and retrieve them.
Writes to a Snapshot are always directed at the reserved LUN pool because the secondary host has no access to the source LUN. The driver needs to determine whether the data chunk is already in the Reserved LUN Pool or not. If it is, the write proceeds. If it is not, the chunk is copied to the reserved LUN pool and the write performed on that chunk. The chunk is copied into SP memory, the write data merged with the chunk, and the modified chunk written to the reserved LUN Pool

use SnapView snapshots, the user must create a Reserved LUN Pool. This LUN pool needs enough available space to hold all the original chunks on the source LUN that are likely to change while the session is active.
When the user starts the first session on a source LUN, one reserved LUN is assigned (allocated) to that source LUN. If the reserved LUN becomes full during the time this session is running, the next available reserved LUN will be assigned automatically to the source LUN. When the session is started, the COFW mechanism is enabled and the SnapView starts tracking the source LUN.

Creating the SnapView snapshot enables the allocation of an offline device (Virtual LUN) to a storage group. Following the slide the user creates the SnapView snapshot that will be offline until activated to a running SnapView session.
Snapshot of Source Lun is added to the Storage Group of Server B the device is still offline (Not Ready) as the SnapView Snapshot is not activated yet.

Once the SnapView session and the SnapView snapshot are created for a given source LUN, the user can activate the SnapView snapshot. This action essentially associates a Snapview snapshot to the point-in-time view provided by the SnapView session. If the SnapView snapshot is already in a storage group and allocated to a host, following activation the connected host should be able to see this point-in-time copy of source LUN data after a bus rescan at the host level.
If the secondary host requests a read, SnapView first determines whether the required data is on the source LUN (i.e. has not been modified since the session started), or in the reserved LUN Pool, and fetches it from the relevant location

COFW process, invoked when a host changes a source LUN chunk for the first time. The original chunk is copied to the reserved LUN Pool.

After the copy of the original chunk to the reserved LUN Pool, pointers are updated to indicate that the chunk is now present in the reserved LUN Pool. The map in SP memory, and the map on disk (remember that all sessions are persistent), is also updated.
Note that once a chunk has been copied to the reserved LUN Pool, further changes made to that chunk on the source LUN (for the specific session) do not initiate any COFW operations for that session

SnapView Snapshots are writeable by the secondary host. This slide shows the write operation from Server B. The write operation addresses a non-virgin chunk; no data for that chunk is in the reserved LUN Pool. SnapView copies the chunk from the source LUN to the reserved LUN Pool in an operation which may be thought of as a Copy on First Write. The copy of the data visible to the Server B(the copy in the RLP) is then modified by the write

After the modification of the chunk, the map and pointers are updated

EMC VNX VNX2 Technical Update - Deep Dive

Overview Link

Virtual VNX: Overview, Architecture & Use Cases

VNX Overview

Vnx series-technical-review

EMC VNX Unified Best Practices For Performance:Applied Best Practices Guide

NAS Meets SAN – an intro to VNX Unified

EMC VNX Monitoring and Reporting

EMC - VNX - LUN Migration

LUN Migration is an important feature for use in storage system tuning. LUN Migration moves data from a source LUN to a destination LUN (of the same or larger size) within a single storage system. This migration is accomplished without disruption to applications running on the host. LUN Migration can enhance performance or increase disk utilization for the changing business needs and applications by allowing the user to change LUN type and characteristics, such as RAID type or size (Destination must be the same size or larger), while production volumes remain online. LUNs can be moved between Pools, between RAID Groups, or between Pools and RAID Groups.

When a Thin LUN is migrated to another Thin LUN, only the consumed space is copied. When a Thick LUN or Classic LUN is migrated to a Thin LUN, the space reclamation feature is invoked and only the consumed capacity is copied

• LUN migration allows data to be moved from one LUN to another, regardless of RAID type, disk type, LUN type, speed and number of disks in the RAID group or Pool, with some restrictions. The process involved in the migration is the same across all VNX systems.

• The LUNs used for migration may not be private LUNs, nor may they be in the process of binding, expanding or migrating.

• Either LUN, or both LUNs, may be metaLUNs, but neither LUN may be a component LUN of a metaLUN.

• The destination LUN may not be part of SnapView or MirrorView operation. This includes Clone Private LUNs, Write Intent Log LUNs, and Reserved LUN Pool LUNs.

Note the Destination LUN is required to be at least as large as the Source LUN, but may be larger

The LUN Migration feature is transparent to any host accessing the Source LUN, though there may be a performance impact.
Copying of data proceeds while the Source LUN is available for read/write access, and the copy process may be terminated at any time. Once all data is copied, the Destination LUN assumes the full identity of the Source LUN, and the Source LUN is destroyed as a security measure. If the migration is terminated before completion, the source LUN will remain accessible to the host, and the destination will be destroyed as a security measure.
The host accessing the Source LUN sees no identity change, though of course the LUN size may have changed. In that case, a host utility, such as Microsoft Windows diskpart, can be used to make the increased space available to the host OS.

In the systems drop-down list on the menu bar, select a system. Select Storage > LUNs > LUNs. Navigate to the LUN that will be the source LUN for the migration operation, and right-click Migrate

The “Start Migration” menu option configures and starts the LUN migration operation.
If the destination LUN does not belong to the SP that owns the source LUN, the destination LUN will be trespassed to the SP that owns the source LUN before the migration starts.

• Source LUN Name: Identifies the source LUN that will be participating in the migration operation.

• Source LUN ID: Identifies the source LUN ID (iSCSI) or the WWN (Fibre Channel).

• Source LUN Capacity: Identifies the capacity of the source LUN, for example, 5 GB.

• Migration Rate: Sets the rate at which the data will be copied - valid values are Low, Medium, High, or ASAP.

Available Destination LUNs: Lists LUNs that are available to be destination LUNs. These LUNS must be the same size or larger than the source LUN

Useful Link

EMC VNX – LUN migration using VNX Snapshot

EMC VNX: LUN migration & provisioning using NAVISECCLI

LUN migration process

EMC VNX – LUN MIGRATION

EMC VNX VNX2 Technical Update - Deep Dive

Overview Link

Virtual VNX: Overview, Architecture & Use Cases

VNX Overview

Vnx series-technical-review

EMC VNX Unified Best Practices For Performance:Applied Best Practices Guide

NAS Meets SAN – an intro to VNX Unified

EMC VNX Monitoring and Reporting

EMC VNX2 - Architecture Overview

1. Overview

The VNX Series unifies EMC’s File-based and Block-based offerings into a single product that can be managed with one easy to use GUI. In addition, object storage solutions are available that make use of the VNX storage systems. The VNX Series is a storage solution designed for a wide range of environments that include midtier-to-enterprise.
The VNX unified storage platforms support the NAS protocols (CIFS for Windows and NFS for UNIX/Linux, including pNFS), patented Multi-Path File System (MPFS) as well native block protocols (iSCSI and Fiber Channel). VNX is optimized for:

• Core IT applications like transactional workloads – Oracle, SAP, SQL, Exchange or SharePoint.

• Server virtualization and end user computing/VDI.

• Applications that need traditional file, or block or unified storage.

EMC VNX VNX2 Technical Update - Deep Dive

Overview Link

Virtual VNX: Overview, Architecture & Use Cases

VNX Overview

Vnx series-technical-review

EMC VNX Unified Best Practices For Performance:Applied Best Practices Guide

NAS Meets SAN – an intro to VNX Unified

EMC VNX Monitoring and Reporting
VNX is also a good fit for partner lead configurations optimized for virtual applications with VMware and Hyper-V integration. The VNX with MCx (VNX2) architecture unleashes the power of Flash, taking full advantage of the latest Intel multi-core technology with the introduction of MCx.

EMC VNX with MCx runs the MCx platform. MCx is comprised of two central components: Multi-
Core Cache and Multi-Core RAID. What is VNX multi-core technology and why is it essential? VNX MCx was specifically designed to dynamically and evenly distribute all data services across all CPU cores in the system. MCx allows Multi-core Cache and Multi-core RAID services to scale linearly regardless of the number of available CPU cores.
Flash storage, or Solid State Disks, has exponentially higher potential IO throughput than spinning storage media. With Flash pushing multiple gigabytes per second of random IO through the system, the storage operating system must be designed to keep pace. If the storage OS statically assigns data services to specific cores, Flash will saturate one or more cores, while other cores are under utilized, this will cause the storage OS to become a bottleneck—preventing the power of Flash from being exposed. By dynamically spreading the workload evenly across all of the available cores, MCx empowers VNX to keep pace with this dramatic performance boost, allowing organizations to deliver extreme responsiveness to their performance-critical applications. This translates into more virtual machines, more transactions, and more aggregate IOPS for file services.

2. Architecture

The VNX modular architecture is designed to deliver a native block and file solution with dedicated components that are optimized for the specific use case and that leverage the hardware and core technologies across both the file and block implementations. This picture illustrates a unified storage product with scalable Data Movers, Control Station (not shown), storage processors, I/O (Input/Output) modules, link control cards (LCC), disk drives, and power supplies. The following slides will cover these components in greater detail.

The Storage Processors are the core of the VNX platform. They deliver the VNX Block components and services, such as Multi-core Cache (MCC) and Multi-core RAID (MCR). The two Storage Processors, SPA and SPB, provide Block data access via UltraFlex I/O (Covered later in this module) technology that supports Fibre Channel, iSCSI, and FCoE protocols, providing access for all external hosts as well as the File hardware of the VNX array.
The VNX storage processors operate in Active/Active mode, in that both controllers are active/on-line and receiving host I/O simultaneously for the backend storage.

The VNX Data Mover X-blade runs the VNX Operating Environment for File, which is optimized to move data between the storage and the IP network. The Data Movers provide highly available file-level access to users and applications via NFS, CIFS, and nPFS protocols. The Data Mover X-Blade stores and accesses data through the Storage Processors. A VNX Data Mover can be configured as a standby Data Mover which serves as a hot spare for up to seven primary or online Data Movers. If a primary Data Mover should go down the standby Data Mover takes its place with little or not disruption of service.

The Control Station is included in all VNX Unified and VNX File storage arrays to provide management and monitoring functions. The Control Station runs a customized Linux kernel. An
optional, second Control Station may be present in some models for redundancy.
The Control Station can be secured by implementing secure user authentication, as well as being isolated on a secure, private network.
The Control Station software is used to install and configure the system, monitor the health of the Primary Data Movers and initiate failover to the Standby Data Movers as required. It is also used to monitor the system’s environmental conditions and performance of all components. The Control Station will also facilitate the call-home and dial-in support features. The Control Station is not in the data path of any File or Block operations.

The power supplies provide the information necessary for Unisphere to monitor and display the ambient temperature and power consumption of the power supply. The power supplies are field replaceble units (FRUs). Each power supply includes two power LEDs and a status LED. The power supplies provide adaptive cooling, in which an array adjusts the power supply fan speeds to spin only as fast as needed to ensure sufficient cooling. The Power Supplies are hotswappable and redundant.
The Standby Power Supply provides battery power to DPE and power to the DAE and SPE on some VNX models. The VNX x uses a DPE which has the SPS built within the VNX SP (Battery On Board) except for the VNX8000 (SPE based) which uses independent SPSs.
The VNX series platform can support up to two standby power supplies or dual SPSs. DC power supplies are available for models VNX5200, VNX5400, and VNX5600. This allows for the  nstallation of these models in network telecommunication facilities or central offices. DC to AC inverters are available for use with VNX Control Stations. This makes these models NEBS
(Network Equipment Building System) compliant.

VNX Series uses I/O Modules in various combinations for front and back-end connectivity. Each
I/O module is protocol independent and hot swappable. Options for block I/O include Fibre Channel, Fibre Channel over Ethernet (FCoE) and iSCSI. Options for file I/O include both 1 Gb/s and 10 Gb/s Ethernet with either copper or optical connections.

VNX uses enclosures to hold major and supporting components, such as power supplies, of VNX, and to provide hot-pluggable connectivity into the system. The possible enclosures are the Storage Processor Enclosure (SPE), Disk Processor Enclosure (DPE), Disk Array Enclosure (DAE), and Data Mover Enclosure (DME).
The enclosures present in the system depend on the VNX configuration type: Unified, Block, or File. The example shown illustrates a VNX Unified configuration. Depending on the model, disks may, or may not, be enclosed with the SPs. When no disks are enclosed with the SPs, an SPE is used. If disks are enclosed with the SPs, a DPE is used. DAEs do not contain any SPs, rather they hold disks, and their supporting hardware, only. Different size DAEs are used depending on the disk form factor and quantity. In Unified and File configurations DMEs are used to contain the Data Mover X-Blades along with their supporting components.

3. Features and Capabolities

VNX with MCx architecture EMC has introduced the first phase of an active/active access model. Symmetric Active/Active allows clients to access a Classic LUN (not supported on pool LUNs) simultaneously through both SPs for improved reliability, ease-of management and improved performance. Since all paths are active, there is no need for the storage processor to "trespass" to gain access to the LUN “owned” by the other storage processor on a path failure, eliminating application timeouts. The same is true for an SP failure, as the SP merely picks up all of the I/Os from the host through the alternate “optimized” path. This capability enables additional LUN performance, as there is more backend bandwidth that can be served by a single SP or FE port.

EMC VNX FailSafe Network or “FSN” provides high availability in the event of an Ethernet switch failure by connecting the two components of the FSN to separate switches. Unlike EtherChannel and LACP, FSN can maintain full bandwidth when failed over, given the same bandwidth on both the active and passive configurations. They do not require any special switch configuration. FailSafe Networks are configured as sets of ports, FastEtherChannels, Link Aggregations, or combinations of these.
Only one connection in an FSN is active at a time. If the FailSafe device detects that the active connection has failed, the Data Mover automatically switches to the surviving partner with the same identity as the failed connection

VNX Virtual Provisioning improves storage capacity utilization by only allocating storage as needed. File systems as well as LUNs can be logically sized to required capacities, and physically provisioned with less capacity. This means storage need not sit idle in a file system or LUN until it is used.
VNX Virtual Provisioning safeguards allow users to keep a track of thinly provisioned file systems and LUNs. By reporting on actual physical usage, total logical size, and available capacity, administrators can both predict and set alerts to avoid running out of physical capacity

VNX with MCx architecture platforms, support Block-level deduplication.
Deduplication of data happens at an 8KB block granularity and requires an 8KB mapping. It can be set at the pool LUN level and Thin, Thick and Deduplicated LUNs can be stored in a single Pool. The deduplication domain is the pool itself; deduplication does not take place across pools. Deduplication occurs out-of-band and is throttled to minimize host I/O impact. The Block Compression feature provides a further reduction of capacity savings initially provided by Virtual Provisioning (compression requires Thin LUNs).
The Block Compression feature uses standard data compression algorithms to reduce space allocated to LUNs. Block compression may be applied to Classic LUNs or Pool LUNs. Block Compression operates in the background, while the LUNs are available for host access. All compression and decompression processes are handled by VNX, so no server cycles are consumed in the process, and no additional server software is required. When sufficient new data is written to a compressed LUN, the system will automatically attempt to compress the uncompressed data in the background.

VNX also supports file level deduplication and compression. VNX for File performs all deduplication processing as a background, asynchronous operation that acts on file data after it has been written into the file system. It does not process active data or data as it is written into the file system.
Deduplication activity can be throttled to avoid impact on processes serving client I/Os. Once candidate files have been identified for deduplication, two activities take place:

• Compression: Compression is accomplished by using components similar to those used inVNX for block LUN compression

• Deduplication: File-level deduplication or single instancing is accomplished by using components of another EMC product called Avamar which duplicates file identification algorithms (file identification for single instance is accomplished using a hashing algorithmfrom Avamar).

VNX storage systems support an optional FAST Cache consisting of a storage pool of Flash disks configured to function as FAST Cache. This cache provides low latency and high I/O performance without requiring a large number of Flash disks. It is also expandable while I/O to and from the storage system is occurring. The FAST Cache is based on the locality of reference of the data set. By promoting the data set to the FAST Cache, the storage system services any subsequent requests for this data faster from the Flash disks that make up the FAST Cache;
thus, reducing the load on the disks in the LUNs that contain the data (the underlying disks). FAST Cache consists of one or more pairs of mirrored disks (RAID 1) and provides both read and write caching. For reads, the FAST Cache driver copies data off the disks being accessed into the FAST Cache. For writes, FAST Cache effectively buffers the data waiting to be written to disk. In both cases, the workload is off-loaded from slow rotating disks to the faster Flash disks in FAST Cache. The performance boost provided by FAST Cache varies with the workload and the cache size.

VNX FAST VP tracks data in a Pool at a granularity of 256 MB – a slice – and ranks slices according to their level of activity and how recent that activity took place. Slices that are heavily and frequently accessed are moved to the highest tier of storage, typically Flash drives, while the data that is accessed least are moved to lower performing, but higher capacity storage – typically NL-SAS drives. This sub-LUN granularity makes the process more efficient, and enhances the benefit achieved from the addition of Flash drives.
The ranking process is automatic, and requires no user intervention. Relocation of slices occurs according to a schedule which is user-configurable, but which defaults to a daily relocation. Users can also start a manual relocation if desired.

4. Management

EMC Unisphere for VNX provides a flexible, integrated experience for managing VNX storage systems. Unisphere’s wizards help the user to provision and manage the storage while automatically implementing best practices for the configuration.
Unisphere is completely web-enabled for remote management of the storage environment. Unisphere Management Server runs on the SPs and the Control Station. Administrative users must authenticate to the VNX when using Unisphere. The VNX provides flexible options for administrative user accounts. For deployments where the VNX will be administered by multiple people, the VNX offers the ability for creating multiple unique administrative accounts. Different administrative roles can be defined for the user accounts to distribute different administrative tasks for the users

Administration of the VNX system can be performed with two Command Line Interfaces (CLIs).
Administrative users must authenticate to the VNX when using CLI interfaces. Block enabled
systems have a host‐based Secure CLI software option called Navisphere Secure CLI. Navisphere
Secure CLI is a client application that allows simple operations on the EMC VNX Series platform and
some other legacy storage systems. The CLI can be used to automate management functions
through shell scripts and batch files.
File enabled VNX systems use a command line interface to the Control Station for file
administrative tasks. If VNX for File or Unified is present, then it can be connected to it via serial or
SSH to troubleshoot many VNX for File hardware components

Unisphere Central is a network application that enables administrators to remotely monitor multiple VNX systems whether they reside in a data center or are deployed in remote and branch offices. It provides administrators the ability to monitor the health, trends and alerts of large numbers of VNX systems from a central console. Unisphere Central is a virtual appliance that runs in a VMware virtual environment.
Users continue to leverage the Unisphere element manager for provisioning and management of their VNX systems, whereas Unisphere Central provides a quick and easy way to monitor all their deployed VNX systems.

 
Unisphere Analyzer is the VNX performance analysis tool. Unisphere Analyzer is an application to help identify bottlenecks and hotspots in VNX storage systems, and enable users to evaluate and fine-tune the performance of their VNX system.
Data may be collected by the storage system, or by a Windows host, running the appropriate oftware, in the environment. Different performance metrics are collected from disks, Storage Processors, LUNs, cache, and SnapView snapshot sessions. Data may be displayed in real-time, or for later analysis, saved as a .nar (Unisphere Archive) file.
For File based detailed monitoring, users have access to the native monitoring capability of Unisphere for File and additional monitoring is available for the VNX for File components in the
separately licensed Data Protection Advisor for File Server offering that provides detailed
reporting not only on replication configurations but VNX for File in general


Unisphere Quality of Service Manager (UQM) measures, monitors, and controls application
performance on the VNX storage system. UQM can be a powerful tool for evaluating the
storage system to determine the current service levels and to provide guidance on what
service levels are possible, given the specific environment.
UQM may be managed by Unisphere GUI, Secure CLI, or Unisphere Client.
Because UQM is array resident, there is no host component to load, and no performance
impact on the host.
UQM controls array performance by allocating resources to user-defined classes of I/O. This
resource allocation allows the specified I/O classes to meet pre-defined performance goals


VNX Monitoring and Reporting is a cost effective software solution. Accessible from a web
portal it has a tree view format that drills down into several summary or filtered views. VNX
Monitoring and Reporting is a limited version of Watch4Net for VNX. It provides basic
monitoring and reporting capabilities for VNX administrators. VNX Monitoring and Reporting
automatically collects block and file storage statistics along with configuration data, and stores
them into a database that can be viewed from dashboards and reports. Watch4Net offers a
custom report development framework extending the preconfigured VNX reports and creates
new reports to meet specific reporting needs. It provides real-time, historical and projected
visibility into network, data center, storage and cloud infrastructure performance. Users who
have more complex environments, or more complex needs, can use Watch4net or upgrade
VNX Monitoring and Reporting to the full version of Watch4net.