VMAX3 operating environemnt is HYPERMAX OS 5977.

%% It is factory pre-configured
%% 100% Virtually Provisioned
%% Can be configured as all Flash
%% Rapidly provision storage
%% set service Level Objectives

----------
VMAX 100 K
----------

## 1 TO 2 eNGINES.
## 1440 Drives

----------
VMAX 200 K
----------
## 1 to 4 Engines
## 2880 Drives

----------
VMAX 400 K
----------

## 1 to 8 engines
## 5760 Drives

Features of VMAX3.

** Low latenty
** high IOPS
** can be configured all flash
** storage can be rapidly provisioned with desired service level agreements.
** it is management simplicity
** Massive scalability
** EMC solutions enabler version 8.0 ( uniSPHERE 8.0) to control VMAX3 Arrays.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~
VMAX 100K,200K,400K

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~
feature Description

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~
Maximum Drives Per Engine @ (720) 2.5"
@ (360) 3.5"

-----------------------------------------------------------------------------------
------
Drive Options @ Hybrid ( mixed drive types )
 @ All-Flash

-----------------------------------------------------------------------------------
------
DAE Mixing @ 60-drve and 12-drive behind an engine
@ Dingle increments

-----------------------------------------------------------------------------------
------
Power Option @ Three-Phase Delta(50amp),WYE(32 amp)
@ single-phase(32 amp)

-----------------------------------------------------------------------------------
------
Dispersion @ System Bays 2-8, upto 25 meters from
System Bay 1

-----------------------------------------------------------------------------------
------
Vault @ Vault to Flashin engine

-----------------------------------------------------------------------------------
------
Racking Options @ Single Engine
@ Dual Engine
@ Thier-party Racking

-----------------------------------------------------------------------------------
------
Service Access @ Integrated service processor in System
Bay 1
# Management Module congrol station
(MMCS)
@ Service tray on additional system bays

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VMAX 100K VMAX 200K
VMAX 400K

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Engines 1-2 1-4
1-8

-----------------------------------------------------------------------------------
----------------------------
Cache/Engine 512 Gb or 1 TB 512 GB, 1TB,or 2 TB
512 Gb ,1 TB or 2 TB

-----------------------------------------------------------------------------------
----------------------------
Engine Type 2.1 GHz 2.6 GHz
2.7 GHz
24 core 32 core
48 core

-----------------------------------------------------------------------------------
----------------------------
Max 2.5" Drives 1440 2880
5760

-----------------------------------------------------------------------------------
----------------------------
Max 3.5" Drives 720 1440
2880

-----------------------------------------------------------------------------------
----------------------------
Max usable Capacity 0.5 PBu 2.1 PBu
4.0 PBu

-----------------------------------------------------------------------------------
----------------------------
Max FE ports 64 128
256

-----------------------------------------------------------------------------------
----------------------------
Infiniband Fabric Dual 12-port Switches Dual 12-port Switches
Dual 18-port Switches

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

VMAX3 - is Dynamic Virtual Matrix

@ which enables 100s of CPU cores to be pooled together and allocated on
demand to meet the performcance requirements for the dynamic work loads.
@ This is first only Dynamic Virtual Matrix in the world today.
@ it is architected for agility and efficiency at scale
@ Resources are dynamically aportioned to host applications, data
services, and storage pools to meet application service levels
@ this enables the system to automatically respond to changing work loads
and optimize itlslf to delever the best performance available fromthe current
hardware
 @ Dynamic Virtual Matrix provides fully redundant architecture along with
fully shared resources within a dual controlor node and across multiple controlors
@ Dynamic load distribution architecture essentially is the BOIS of the
VMAX3 operating software and provides truly scalable multi control architecture
that scales and manages
from 2 fully redundant controlors upto 16 fully redundant controlors all
sharing IO processing and cache the resources.

There are 3 core allocation policies

@ balanced (Default)
@ Front-End
@ Back-End

-----------------------------------------------------------------------------------
-----------------------------------------------------------------------------------
-----
The load can be dynamially distributed over time. - currently this feature is
not supported by software ( by user) , we need to contact the EMC service Engineer
to do this

-----------------------------------------------------------------------------------
-----------------------------------------------------------------------------------
-----

VAMX3 KEY FEATURES

## 100% virtually provisioned.
## Arrays are shipped pre-configured.
@@ Data devices, Data pools, storage Resouce pool and Service Level
Objectives.
## FAST ( the FAST is always enabled on VMAX3)
@@ Enables Service Level Objective based provisioning
@@ All host related data managed by FAST.
## Replication
@@ TimeFinder SnapVX
@@ SRDF (Extended SRDF fetures)
@@ ProtectPoint - Integration with DMC Data Domain
## eNAS
@@ Embedded NAS Data Services on Virtual Data Movbers and Control
Stations.

VMAX3 CONFIGURATION TOOLS.

@@ Initial Configuration
 -- Configuration is done at the factory.
-- Symwin and Simplified SymmWin
~ Runs on Management Module control Station (MMCS) ( is this like
service processor ?)
~ Access restricted to authorized EMC personnel only.

@@ End User tools for configuration and Managment.

-- solutions Enabler 8.0.x
-- Unisphere for VMAX 8.o.x

SE(solutions Enabler) integration with HYPERMAX OS

-----------------------------------------------------------------------------------
---

Unisphere for VMAX

SYMCLI

-----------------------------------------------------------------------------------
---
SYMAPI

-----------------------------------------------------------------------------------
---
^
^
|
|
|
|
|
|
|
| MMCS(Management Module control Station)
|
| SYMMWIN
v
v

-----------------------------------------------------------------------------------
----
HYPERMAX OS

-----------------------------------------------------------------------------------
----

@@ EMC Solution Enabler APIs are the storage management programming

interfaces that provide an access mechanism for managing the VAMX3 Storage Arrays.
@@ They can be used to develep storage Management applications
@@ SYMCLI resides on Mangment Host system to manage , monitor , to
perform control operations on the storage array
@@ SYMCLI commands are invoked from the Managment Host operating
system command line shell
 @@ SYMCLI commands are built on top of sym API library functions
which uses system calls that generate low level I/O SCSI commands to the storage
arrays.
@@ UNISPHERE for VMAX3 is the GUI that makes API calls to SYM API
to get the access to the storge array
@@ SymmWIN running on the VMAX3 MMCS access Hypermax OS directly.

Introduction to solutions Enabler.

## Symmetrix Command Line Interface (SYMCLI).

## Comprehensive command set for Managing VMAX3 Arrays.
-- Invoked from the Host OS command line.
-- Scripts that may provide further integration with OS and
application.
## Security and access controls
-- Monitor only
-- Host-based and user-based controls.

Introduction to UNISPHERE for VMAX

## VMAX3 Arrays
--Service Level Based Management.
## Performance Analyzet
-- Installed by default
-- pOstgreSQL
## APIs for Automation and Provisioning.

UNISPHERE functionality
## Manage eLicenses, User and Roles
## Storage Configuration Managment
-- SLO based provisioning
-- FAST
## Configure and Monitor Alerts
## Performance Monitoring
-- Real time, Root cause and Historical ( real time
analysis and historical trending of VMAX performance data)
we can also see high frequency metrix in the
real time , VMAX3 system HEAT maps ,graphs ,detailing system performance.
we cab also drill down through data to
investigate the issues to monitor perfomance overtime,execute schedule and ongoing
reports and
to export data to a file
-- Dashboards
users can customise their own Dashboards along
with system pre given.
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

==========================

VMAX3 Storage Provisioning

==========================

Factory Pre-Configuration

## Disk Groups
@ A collection of Physical Drives.

-each drive in the Disk Group shares the same perfomance

characterstics determined by the rotational speed and technology of the dirves it
may be 15k/10k/7.2k/flash and capacity

## Data Pools
@ Collection of Data Devices(Tdats)
- Preconfigured in each Disk Group
- All the disks in the disk group are of same RAID protection(
so all the disks in the given group are having same RAID protection and fixed
size )

@ All Data Devices in a dis Group added to a Data Pool.

- 1-to-1 relationship between Data Pool and disk group.

@ Performance capability of each Data Pool is Known

- Baed on the drive type, spped, capacity, quantity of drives
and RAID protection

## Storage Resource Pool

@ collection of Data Pools

## Service Level Objectives.

-----------------------------------------------------------------------------------
-------------------------------------------------------
IMP Disk Groups,Data Pools, Storage Resource pool, Service Level
Objectives can'b be configured or modfied with solutions enabler of UNISPHERE
These are created during the configuration process at the
factory.

-----------------------------------------------------------------------------------
-------------------------------------------------------
 All the data pools must belong to only one disk group, there is one to
one relationship between disk groups and data pools.
Disk group must contaning the disk of same disk technology,
capacity,rotational speed and RAID type
The performance capability of each data pool is known and based on
drive type , speed, capacity , Quantity of drives , and the RAID protection.

+++++++++++++++++++++++

Data Pools -Protection

+++++++++++++++++++++++

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Option Characteristics
protection Performanace cost

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
RAID 1 @ Write to two separate Physical drives
Higher Fastest LOW
@ Read frin Single Drive

-----------------------------------------------------------------------------------
-------------------------------------------------------
RAID 5 @ Parity based protection
High Fast Read and Good Write Lower
@ Striped data and parity
@ 3+1 and 7+1

-----------------------------------------------------------------------------------
-------------------------------------------------------
RAID 6 @ Two parity drives 6+2 and 14+2
@ Data availability is primary consideration
Highest Fast Read and Fair Write Lower
@ Performance is a secibdart consideration

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

write penalaties

RAID 1: 2 writes on back end

RAID 5: each host write results to 2 reads and 2
writes
RAID 6: each host write results to 3 reads and 3
writes

++++++++++++++++++++++++++
SRP -Storage Resource Pool
++++++++++++++++++++++++++

@@ Collection of Data Pools

@@ Factory Pre-configured includes one SRP (which contains
all the data pools in the array)
@@ Not configurable via solutions Enabler or Unisphere for
VMAX
@@ Multiple SRPs may be configured (by qualified EMC
personal)
if there are multiple SRPs one of them must be
marked as default

storage resource pool

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~ |
| | Flash -RAID(3+1) | | SA 15k - RAID 1 | | SAS
7.2K -RAID 6(14+2) | |
| | Data Pool 0 | | Data Pool 1 | | Data
Pool 2 | |
| ~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~ |
|
|

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

++++++++++++++++++++++++++++++++++++++++++++++++
SLO - Service Level Objective Based Provisioning
++++++++++++++++++++++++++++++++++++++++++++++++

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Service Level Objective
Storage Groups

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ Defined ideal performance Operating range of an
application @ Canbe explicitly associated with an SRP
@ Can be combined with a workload type
@ Can be explicitly associated with an SLO and workload type
-- further refines the performance objective
-- Defines the SG and FAST Managed.
@ Preconfigured
@ SGs are implicitly associated with the default SRP and the Optimized SLO

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Service Level Objective(SLO) defines the ideal

performance operating range of an application
 ## each SLO contains an expected maxim responce time
range
The responce time is measured from the perspective
of the Front end adopter.

## The SLO can be combined with work load type before

refind the performance objective
## SLO are pre-defined /pre-configured ( these are not
configurable using solutions enabler or UNISPHERE)

--------------

storage groups
--------------

** storage groups in VMAX3 (with Hypermax o/S

5977 ) are similar to the storage group used in previous generation of the VMAX
arrays.
** It is logical grouping of devices used for
FAST ,Device Masking , control and monitoring.
** In the HyperMax OS 5977 a storage group can be
associated with SRP.
-- this is allows the devices in the SGs to
allocate storage from in any pool in the SRP.
** When an SG is associated with a SLO it defines
a SG as FAST managed storage group .

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

SLO Performance Behaviour

Expected Average Response Time

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

Diamond Flash
0.8 ms

-----------------------------------------------------------------------------------
---------------------
Platinum Between Flash & 15K RPM
3.0 ms

-----------------------------------------------------------------------------------
---------------------
Gold 15k RPM
5.0 ms
-----------------------------------------------------------------------------------
---------------------
Silver 10K RPM
8.0 ms

-----------------------------------------------------------------------------------
---------------------
Bronze 7.2K RPM
14.0 ms

-----------------------------------------------------------------------------------
---------------------
Optimized(default) System optimized
N/A

-----------------------------------------------------------------------------------
---------------------
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

++ there are 5 available service level objectives

(SLO) varying and expected average Response time targets

@@ the Optimized SLO has no explicit Resoonce time

target

@@ the optimized SLO achieves the optimal

performance by placing the most active data on higher performing storge
and the least active data on the most cost
effictive storage.

## Diamond emulates Flash Drive performance.

%% platinum emulates performance between Flash and
15K RPM drives
&& Gold emulates performance of 15K RPM dirves
@@ Silver emulates performance of 10k RPM drives
** Bronze emulates performance of 7.2k RPM drives

++ the actual response time of an application

associated with a SLO vary based on the actual workload
it will depend
-- on the average I/O size
-- Read,Write Ratio
-- and use of local and remote replication

-----------------------------------------------------------------------------------
-------------------------------
IMP @@ these SLOs are Fixed and Cannot be
modified
@@ the end user can associate the desired
SLO with a storage group.
@@ please also note that Certain SLOs are
may not available on an array , if certain drive type are not configured
-----------------------------------------------------------------------------------
-------------------------------

no Flash drives present in an array.
no 7.2k RPM drives are not present
ex:
Diamond SLOs are not available if there
Broanze SLOs are not available if there
in any array.

+++++++++++++++++++++++++
AVAILABLE WORKLOAD Types
+++++++++++++++++++++++++

@@ there are 4 workload types

@@ The workload type can be speficied with a
diamond,platinum,Gold,Silver, Bronze Slo types to further refine response time
expectations
IMP Note : we cannot associate the
work load type with the Optimized SLO

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~
Workload type
Description

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~
OLTP Small
block I/O workload

-----------------------------------------------------------------------------------
-------------------
OLTP with Replication Small
block I/O workload with local or remote replication

-----------------------------------------------------------------------------------
-------------------
DSS Large
Block I/O workload

-----------------------------------------------------------------------------------
-------------------
DSS with Replication Large
blockI/O workload with local or remote replication

-----------------------------------------------------------------------------------
-------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~
 ++++++++++++++++++++++++
AUTO PROVISIONING GROUPS
++++++++++++++++++++++++

@@ AUTO-PROVISIONING GROUPS ARE USE TO

ALLOCATE VMAX3 STORAGE TO HOSTS
@@ VMAX3 ARRAYS PRESENT THIN DEVICES TO HOSTS
-- Open system host sees VMAX3 Thin Devices
as FBA SCSI disk drives.
@@ VMAX3 Thin Device -Size Metrics
-- Sector - 16 blocks (512 byte Block) 8
kb.
-- Track Size - 16 Sectors - 16 *8 =128 KB
-- Cyclinder Size - 15 Trakcs - 15 * 128 =
1920 KB
-- Maximum Device Size - 8947848 Cylinders
= 16384 Gb = 16 TB
-- Device sizes are typically specified in
Cylinders.

++ Open system host sees VMAX3 Thin Devices

as FBA SCSI disk drives.
-- standard SCSI commands such as SCSI
enquiry and SCSI read capacity,
return low lovel physical device
data (such as vendor ,configuration,and basic configuration
but have limited knowledge of the
configuration details on the storage system.
-- knowledge of VMAX3 specific
information such as Director configuration,Cache size,number of devices,
mapping of physical to logical port
status,flags etc require a different set of tools and that is what the solutions
enabler and UNISPHERE.

++ Host IOPS are managed by Hypermax O/S

environment, which runs on VMAX3 array.
++ VMAX3 thin devices are presented to the
host with these emulation attributes
-- Eacn device has N cyclinders
( the number is configurable)
each cyclinder has 15 tracks
each device track is in
FBA(fixed Block Architecture) is 128 KB
256 blocks of 512 each
++ Maximum thin device that can be
configured on a VMAX3 is 16 TB

+++++++++++++++++++
 STORAGE ALLOCATION
+++++++++++++++++++

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Initiator Group @ Fibre Channel
Initiator /HBA/HBA WWNS
- A initiator
group can have upto max of 64 initiators(WWS) or 64 child Initiator group names
- A initiator
group can't contain mixture of host Initiators(wwn) and child IG names
- An individuall
belongs to only one initiator group
-- howerver
once the initiator is in the group, the group can be member of another initiator
group
-- this
feture is called cascaded initiator group ( this is allowed cascaded level of 1.
so it can do one level deep)
@ Port Flags set on
Initiator Group basis with one set of port flags applying to all the initiators in
the group
- FCID Lockdown
per Initiator ( it is set on per initiator basis)
(FCID
lockdown stops the threat of WWN spoofing)
(WWN
Spoofing: An attacker gains access to a storage system in order to
access/modify/deny data or metadata.)

-----------------------------------------------------------------------------------
---------------------------------------------------------------------
Port Group @ Front End Ports
-- it can contain
maximum of 32 FA ports
@ A port can belong
to multiple port groups
@ Ports must have
the ACLX flag enabled ( beore a port is added to the port group m the ACLX shouold
have been enabled)

** ACLX
-Access Control Logix
symmaskdb
-sid <sid #> list database -v

** What
controls the visibility of the VMAX3 ACLX device to a host?
Show ACLX
device flag set to Enabled

-----------------------------------------------------------------------------------
---------------------------------------------------------------------
Storage Group @ VMAX3 Thin Devices

@ A device can
belong to more than one storage group
@ can be associated
with SRP,SLO and Workload Type

-- storage group
can only contain devices or other storage groups
No mixing is
permitted.
-- storage grop
with devices may contain upto 4k VMAX3 logical volumes/LUNS
-- A logical
Volume may belong to more than one storage group.
-- There is limit
of 16K storage groups per VMAX3 storage array.
-- A parent
storage group can have upto 32 child storage groups.
-- one of each
type of group is associated with to form a Masking view.

** Storage
group is a logical grouping of upto 4096 symm devices.
** LUN
addressing done automatically via dyanamic LUN feature

-----------------------------------------------------------------------------------
---------------------------------------------------------------------
Masking View @ one of each type
of group is associated together to form a masking view

** It
defines an association between one Initiator group, one port group and one storage
group.
** when a
masking view is created, the devicves in the storage group are mapped to the ports
in the port group
and
maksined to the initiators in the initiator group.

-----------------------------------------------------------------------------------
---------------------------------------------------------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+++++++++++++++++++++++++++++++++
MANAGING STORAGE AND PROVISIONING
+++++++++++++++++++++++++++++++++

@@ This can be done using UNISPHERE for VMAX or

SYMCLI
-- UNISPHERE for VMAX - various wizards and
tasks
-- SYMCLI
* symconfigure
* symaccess
* symsg

@@ perform configuration and storage provisioning

-- Thin device management - creation, deletion,
attribute modification
-- Front-end port managment - attributes,
association
-- Array metrics
-- Manage Auto-rpovisioning groups - storage
provisioning.

++++++++++++++++++++++++++
configuration Architecture
++++++++++++++++++++++++++

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~
| ---------------------------
---------------------------- ------------------------ |
| | | |
~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~~~~ | |
| | HOST | | | LOCAL
VMAX3 | | | | REMOTE VMAX3 | | |
| | | |
~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~~~~ | |
| | ~~~~~~~~~ ~~~~~~~~~~ | | ~~~~~~
| | | |
| | |SYMCLI | |UNIVMAX | | | | FA |
| | | |
| | ~~~~~~~~~ ~~~~~~~~~~ | | ~~~~~~
| | | |
| | ~~~~~~~~~~~~~~~~~~~ |---------------->|
| | | |
| | | SYMAPI | | | | |
| | | |
| | ``````````````````` | | | ~~V~~
| | ~~~~~~ | |
| | | SIL | | | | | RA
|------------------------>| RA | | |
| | ~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~
| | ~|~~~~ | |
| | | | |
| | | | |
| ----------------------------
----|----------------------- ----|------------------- |
| | ^
| ^ |
| Ethernet | |
Ethernet| | |
| | |
| | |

| | |
| | |

| v |
v | |
|
--------------------------- -------------------------- |
| |
~~~~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~~~~~~~~ | |
| | ! | SYMWIN
scripts | !| | ! | SYMWIN scripts | ! | |

| | !
~~~~~~~~~~~~~~~~~~ !| | ! ~~~~~~~~~~~~~~~~~~ ! | |

| | !
!| | ! ! | |
| | !
!| | ! ! | |

| | ! SYMWIN
!| | ! SYMWIN ! | |
| | !
!| | ! ! | |
| |
~~~~~~~~~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~~~~~~ | |
| |
~~~~~~~~~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~~~~~~ | |
| | ! MMCS
!| | ! MMCS ! | |
| | !
!| | ! ! | |

| |
~~~~~~~~~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~~~~~~ | |
|
|--------------------------- -------------------------- |
|
|

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~

IMP ## The configuration Manager Architecture allows you to run symwin

scripts on vmax3 MMCS

@@ configuration change requests are generated either by the symconfigure

symcli command or a symapi library call generated by a user making a request
through the UNISPHERE for VMAX GUI.
@@ These requests are converted by SYMAPI on the host to VMAX3 sys-calls and
trasmitted to the VMAX3 through the channel interconnect
@@ The VMAX3 front-end routes requests to the MMCS which invokes symwin
procedures to perform the requested changes to the VMAX3.

@@ in the case of SRDF connected array , configuration requests can be sent to

the remote array over the SRDF links.

++++++++++++++++++++++++
VMAX3 Gatekeeper Devices
++++++++++++++++++++++++

## solutions enabler is an EMC software component used to control the

storage feature of VMAX3 array.
## It receives user requests by a symcli/GUI or other means and generate
system commands that are transmitted to the VMAX3 array for action.
## Gatekeeper devices are luns that act as the target of command requests
to enguinity based functionality.
## these commands are arrive in the form of disk I/O requests - the more
commands that are issued from the host , and the more complex the action required
by those commands
the more gate keepers are required to handle those requests in timely
manner.
## When solutions Enabler succefuly obtain a gate keeper , it locks the
device and then processes the system commands.
## Once the solutions enabler processes the systemm commands, it closes and
unlock the device freeing it for other processes
## A Gate keeper is not intended to store the data , it is usually
configured as a small 3 cylinder device ( or approxmately 6MB device)
## Gatekeeper devices should be mapped and masked to a single host only
and should not be shared across the hosts.

IMP ## there is specific recomendation on the number of gate keepers was

required for all VMAX3 configurations
*** EMC recomends it to be 6 gate keepers for each HBA.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| %% 3-cyl thin devices(~ 6MB)
|
| %% Receives low-level SCSI I/O from SYMCLI/GUI
|
| %% Used as target of SYMCLI/SYMAPI commands
|
| *** commands passed through gatekeepers to VMAX3 for action
|
| *** Locked during the passing of commands
|
| *** Lots of commands flowing to the VMAX3 from many
applications on the same host can cause gatekeeper shortage |
|
|
| %% must be accessible from the host executing the commands
|

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ++++++++++++++++++++++++++++++++++++++++++++
CONCURRENT CONFIGURATION SESSIONS ON VMAX3
++++++++++++++++++++++++++++++++++++++++++++

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| @@ Concurent Provisioning
|
| - upto four concurrint non-conflicting configuration change
seesions. |

| *** should not include conflits of the following

|

| -- Device Back-end port

|
| -- Device front-end port
|
| -- Device
|
| @@ array Manages its own device locking
|

| @@ Session ID identifies each running configuration sesssion.

|

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

## VAMX3 allows to run the 4 concurrent sessions at

the same time, when are not conflicting with each other.
this means multiple configuration parallel
sessions can run at the same time as long as the changes do not include any
conflicts as given.
-- Device Back-end port
-- Device front-end port
-- Device itself.

## the VMAX3 array manages itself the device locking

and each running session is defined by session ID.

++++++++++++++++++++++++++++++++++++++++++++++
CONFIGURATION CHANGES USING UNISPHERE FOR VMAX
++++++++++++++++++++++++++++++++++++++++++++++
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| @@ Multiple ways to invoke configuration changes via unispehere
|
| -- Depends on the rype of configuration change
|
| -- Unisphere has many wizards.
|

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

## configuration changes can be invoked by UNISPHERE

for VMAX in many different ways.
## The method depends on the type of configuration
change
## Unispehere has number of wizards are available
## configuration tasks can be submitted to a job list.

++++++++++++++++++++++++
Unispehere -SRP Headroom
++++++++++++++++++++++++

@@ the storage groups dashboard in unisphere for vmax shows all the
configured storage resouce pools and the available headroom for each SLO.
@@ prior to allocating new storage to a host,it is a good idea too
check the available headroom

to navigate to the storage group dashboards simply click on the

storage section button.

----------------------
Unisphere -SRP details
----------------------

one can also look at the details of configured storage resource

pools to see the details of usable and allocated and free capacity
to navigate to the storage resource pools click on the storage
resource pool link in the storage resource section dropdown.

----------------------
Unisphere -Job list
----------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| @@ List of jobs
|
| - Yet to be run - CAn be run on demand or scheduled
for later execution |
| - Jobs that are running , successfully completed,
or failed. |

| @@ Job list can be accessed by clicking

|
 | - Job list link in the system section dropdown
|
| - Job list link in the status bar
|

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

most of the configuration tasks in the Unispehere for vmax can be

added to the job list for execution at a later time.
the job list shows all the that are yet to be run , jobs that are
running currently,and jobs that are run successfully. and also the jobs that are
failed
you can naviagate to the job list by clicking the job list in
the sytem section dropdown. or clicking on joblist link in the status bar

for example :
we can create a job for creating the
volumes/luns ...we can click run botton to create the luns now and click on the
scheduled button to create it later.

---------------------------
configuration chages SYMCLI
---------------------------

## varify configuration changes can be made safely:

- symconfigure verify -sid <sid#> ...shows if the
symmetrix is ready for configuration changes
## check usage of the configure storage resource pools
- symcfg list -srp -sid <sid#>

## consider impact on I/O

- to make devices not ready use :
symdev not_ready <symdev>
## After allocation/de-allocation of storage to a host update
the host operating system environment before attempting I/O

## Query
- symconfigure query -sid <sid#>
## Abort
- configuration change session can be terminated
prematurely using the abort command.
- premature termination is only possible before the point
of no return.
- symconfigure -sid <sid#> abort -session_id <session-
id>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
###################################################################################
###################################################################################
#######################################################
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

-------------
FAST with SLO
-------------

One of the major changes with V3 is the way we provision storage. FAST has been
enhanced to work on a more granular level (128KB track level) and we have
abstracted a lot of the internals so that the end user need not be so concerned
about
the mechanics of the array they can simply provision capacity and set a performance
expectation which the array will work to achieve.

In VMAX3 FAST is always on and the majority of the configuration is pre-configured,

available SLO are dictated by the disks available in the array

and Storage Resource Pools are defined in the bin file.

we are no longer required to create meta devices to support larger devices and the
SLO model makes provisioning intuitive and easy.

-------------------------
Creation of storage Group
-------------------------

@@ We can creae the Storage group like which we created earlier for VMAX2.
@@ Assigning to SLO and Workload is optional ,
@@ If no SLO or Workload is specified FAST will still manage everything but yout
SLO will be optimized.
@@ VMAX3 supports 64k (64000) storage grops, ( we can create one storage group
for one application).
@@ At present we can create devs up to 16TB soon to be increased further.

example of creation of luns

-----------------------------------------------------------------------------------
--------------------------
symconfigure -sid 007 -cmd "create dev count =5 config=tdev,
emulation=fba size=2048 GB sg=myapp_sg;" preview

-----------------------------------------------------------------------------------
--------------------------

----------------------------------------------------------
symsg �sid <sid#> create myapp_sg �slo gold �workload oltp
----------------------------------------------------------

@@ Present to the host via a masking view, no change from VMAX here.

++ Here I will highlight a few of the key commands to gather information about
the configuration and interaction with the SRP and SLO.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++
IMP NOTE:- Monitoring and Alerting of FAST SLO is built into Unisphere for VMAX.
SLO compliance is reported at every level when looking at storage group components
in Unisphere.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++

-----------------------------------
Viewing SRP configured on the Array
-----------------------------------

@@ Most VMAX3 arrays will only have a single SRP.

@@ However it is also possible to have multiple, if we are using
FAST.X or Protect point ( for Data Domain Backups) we may have
additional SRP in the config.

----------------------------
symcfg -sid <sid#> list -srp
-----------------------------
----------------------------------------------
symcfg -sid <sid#> show -srp <srp-name> -tb/gb
----------------------------------------------

++ Default SRP is set to be usable by RDFA DSE, this is normal.

++ There is no need to configure a separate pool for DSE in VAMX3.
++ we can reserve and cap some space from the default SRP for this
purpose.

---------------------------------
Viewing Available SLO in the VMAX
---------------------------------

----------------------------
symcfg -sid <sid#> list -slo
----------------------------

++ to get more details look at the SLO's and the workloads that can
be associated with storage groups
we can run this command.
 ------------------------------------------------------
symcfg -sid <sid#> list -slo -detail -by_resptime -all
------------------------------------------------------

--------------------------------
Viewing SRP capacity consumption
--------------------------------

@@ to the get an idea of how your storge is being consumed ( from the
command line we can run this command)

---------------------------------------------
symsg -sid <sid#> list -srp -demand -type slo
---------------------------------------------

++ this above command shows you how the SRP is being consumed by
each of the SLO,
++ it will also list how much space is consumed by DSE and Snapshot
( please note that , this capacity all comes from the SRP , so it's worth keeping
an eye on)

------------------------------------------
Listing SLO associations by Storage Group.
------------------------------------------

@@ the previous command (symsg -sid <sid#> list -srp -demand -type
slo) gives good idea at high level.
@@ but if we want to see from a storage level like which storage
groups are associated with each SLO we can use this undergiven command

--------------------------------------
symsg -sid <sid#> list -by_SLO -detail
--------------------------------------
++ this above command shows , each storage group whether or not is
associated with SLO.
++ we can also get some detial about the number of devices in storage
group ( not the capacity)

@@ we can use this follwoing command to get the additional

informatiion like the space consumption of an individual device level on the
applicatiion storage group.

----------------------------------------------
symcfg list -tdev -bound -detail -sd <sg-name>
-----------------------------------------------

## We can see the full breakdown of the SRP including drive pools
and which SLO you have availabe as well as TDAT information.
with this command we can have information like thin
devices(Tdevs) bound to the SRP and how much space they are each consuming.
 ---------------------------------------------------------
symcfg -sid <sid#> how -srp <srp-name> -gb -detail | more
---------------------------------------------------------

-----------------------------------------------------------------------------------
----------------------------------------------------------
Changing the SLO on Existing Storage Groups ( the storage groups which are already
associated to the masking view and they are in production)
-----------------------------------------------------------------------------------
----------------------------------------------------------

Ex: changing SLO (service level objective ) to platinum and workload to

OLTP_REP for a storage group test.

---------------------------------------------------------
symsg -sid <sid#> -sg test set -slo platinum -wl OLTP_REP
---------------------------------------------------------

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++
solutions Enabler 8.X also allows for moving devices between groups non-
disuprively
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++