Professional Documents
Culture Documents
01 MR-1CP-SANMGMT - SAN Management Overview - v4.0.1
01 MR-1CP-SANMGMT - SAN Management Overview - v4.0.1
storage devices and multipathing. EMC VNX and VMAX storage arrays and Connectrix
products are also introduced along with the tools to manage them.
Host bus adapters (HBA) are hardware components installed in an open systems host to
access storage in a SAN. These drivers are responsible for encapsulating and un-
encapsulating SCSI-3 protocol (commands and data) within the payload of Fibre Channel
frames. In several environments, hosts also use HBAs to boot the OS from a SAN-attached
storage array. In this situation, the HBA has a special boot code on it to allow the host to
probe for SCSI disks during boot time.
iSCSI HBAs are ideal initiators for iSCSI connections to storage. The iSCSI HBA offloads
TCP/IP and iSCSI frame processing, reducing the strain on the host’s CPU. iSCSI can also
be supported using a regular NIC (Network Interface Controller) card by enabling iSCSI
initiator driver software within the operating system.
Modern operating systems can create and manage highly scalable file systems that can be
expanded to meet the increasing appetites of multiple applications. A volume that is
presented to an operating system can be one physical volume, or a virtual volume that
spans an array of disks (RAID - Redundant Array of Independent Disks).
Fibre Channel, iSCSI and FCoE protocols operate only with block storage, whereas NAS
(Network Attached Storage) only operates on file level storage.
In Unix based systems the Meta Data consists of the Superblock, the Inodes and the list of
data blocks free and in use.
Windows file systems also have meta data, but use different terminology such as Master
File Table (MFT) in NTFS. The Meta Data of a file system has to be consistent for the file
system to be considered healthy.
Superblock – Contains important information about the file system: File system type,
creation/modification dates, size/layout of the file system, count of available resources and
a flag indicating the mount status of the file system. The Superblock maintains information
on the number of inodes allocated, in use, and free; and the number of data blocks
allocated, in use, and free. (This is set when the file system is created. The number of
Inodes allocated = File System Size divided by the number of bytes per I-node (NBPI)).
Each file or directory needs an inode. New files or directories cannot be created if there are
no free inodes.
Inodes – An Inode is associated with every file and directory, and has information about
file length, ownership, access privileges, time of last access/modification, number of links
and, finally, the block addresses for finding the location on the physical disk where the
actual data is stored.
The meta data of a File System is typically cached in the Hosts Memory Buffers. Host level
buffering is important to keep in mind in a VMAX Environment with SRDF and TimeFinder.
The information in a Host’s memory buffer is not available on the BCVs or the SRDF target
devices until they are flushed down to the standard devices.
Without a path failover software package, the loss of a path (dotted line) means one or
more applications may stop functioning. This can be caused by the loss of a Host Bus
Adapter, a port on the storage array or SAN switch, or a failed or unintentionally pulled
cable. A single path is a single point of failure. In the case of a path failure, all I/O that was
heading down the path is lost.
When multipathing software is used to make use of multiple paths, the loss of a path means
the load may be switched to use the remaining n-1 paths. This is called path failover. This
doesn’t mean that performance is not affected, but the applications continue to operate at
their best without down time.
Examples of multipath software include the native OS MPIO (Multi-path I/O) driver and EMC
PowerPath. EMC PowerPath is tuned to the unique capabilities of EMC storage arrays and
has more features and better performance than native MPIO drivers.
The diagram on the left depicts a snapshot of the system at a moment in time. The amount of I/O
from each application or process is unbalanced. Host applications sitting on top of deep queues are
not getting the I/O performance they need due to congestion. If this was the average loading, the
System Administrator would reconfigure the system to balance the load better. In any system, there
will be points in time when the load is unbalanced due to one application receiving heavy I/O
requirements.
In the single path example shown on the left, two of the applications are currently causing high I/O
traffic. At this point, two channels are overloaded (depicted by the pending request stack) while two
other channels are lightly loaded. In a while, the requests will have been handled and the system will
return to a more balanced load. In the meantime, the applications are being “data starved” and the
users or applications are experiencing less than optimal performance.
With Multipathing software in the system, applications transparently access multipathing devices
instead of the SD (SCSI driver) devices. Multipathing allocates the requests across the available
channels, reducing bottlenecks and improving performance. The diagram on the right shows a similar
snapshot, with multipath software using multiple channels to minimize the queue depth on all
channels.
Since the FAs (or SPs) are writing to cache and not to disks, any Channel Director/Storage Processor
can handle any request. This allows multipathing to constantly tune the server to adjust to changing
loads from the applications running on the server. Multipathing does not manage the I/O queues; it
manages the placement of I/O requests in the queue.
Multipathing improves the performance of the server, enabling it to make better use of the storage.
This results in better application performance, less operational resources spent on the care and
feeding of the system, and more financial value from your server investment.
Disk volumes are the most popular storage medium used in modern computers for storing
and accessing data for performance-intensive, online applications. Disks support rapid
access to random data locations. This means that data can be written or retrieved quickly
for a large number of users or applications. In addition, disks have a large capacity.
Disks come in several types, and can be generally divided into two categories: High
Performance and High Capacity. Solid State Disks (SSD) or Enterprise Flash Drives (EFD)
are the highest performing drives available because they have no moving parts and don’t
have to wait for a physical disk to rotate to a particular position before accessing data. Fast
spinning drives with Fibre Channel (FC) or Serial Attached SCSI (SAS) are the next level
down in high performance. Serial ATA (SATA) and Near Line SAS (NL-SAS) are high
capacity drives that spin slower than high performance drives. High capacity drives have
replaced tape for most applications.
Tapes are still used sometimes for backup because of their relatively low cost. However,
tape has various limitations; data is stored on the tape linearly along the length of the tape.
Search and retrieval of data is done sequentially, invariably taking several seconds to
access the data. As a result, random data access is slow and time consuming. This limits
tapes as a viable option for applications that require real-time, rapid access to data. On a
tape drive, the read/write head touches the tape surface, so the tape degrades or wears out
after repeated use. The storage and retrieval requirements of data from tape, and the
overhead associated with managing tape media, are significant.
Note: This course will use VNX and VMAX storage arrays in the lab exercises.
It is based on unique technology that combines scale out clustering and advanced data
caching, with the unique distributed cache coherence intelligence to deliver radically new
and improved approaches to storage management.
This architecture allows data to be accessed and shared between locations over distance via
a distributed federation of storage resources.
VPLEX with GeoSynchrony is open and heterogeneous, supporting both EMC storage
arrays and arrays from other storage vendors such as HDS, HP, and IBM. VPLEX conforms
to established world wide naming (WWN) guidelines used for zoning. VPLEX provides
storage federation for operating systems and applications that support clustered file
systems, including both physical and virtual server environments with VMware ESX and
Microsoft Hyper-V. VPLEX supports network fabrics from Brocade and Cisco.
Models VNXe 3200 and the VNX 5200 and above employ the MCx™ architecture. MCx
stands for Multicore Optimization. This high performance architecture is applied in VNX
arrays as Multicore RAID, Multicore Cache, and Multicore FAST Cache. In conjunction with
MCx, also included are enhanced hardware, increased memory and number of processor
cores, 4 TB 7200 RPM drives as well as the availability of FLASH-based SSD drives. Please
see the Sales Resource Center and Partner Portal for more information.
All the capacity in the group is available to the server. Any RAID Group should consist of all
SAS or all Flash Drives but not a mix of SAS and Flash Drives. Most RAID types can be
expanded with the exception of RAID 1, 3, 6, and Hot spares. Most RAID types can be
defragmented to reclaim gaps in the RAID group, with the exception of RAID 6.
Pools are recommended because they give the administrator maximum flexibility and are
easiest to manage.
A Pool is somewhat analogous to a RAID group. However, a Pool can contain a few disks or
hundreds of disks, whereas RAID groups are limited to 16 disks.
Pools are simple to create because they require only three user inputs:
• Pool Name
• Resources (Number of disks)
• Protection level: RAID 5 or 6
Pools are flexible. They can consist of any supported disk drives. Arrays can contain one or
many pools per storage system. The smallest pool size is three drives for RAID 5 and four
drives for RAID 6.
Note: EMC recommends a minimum of five drives for RAID 5 and eight drives for RAID 6.
Pools are also easy to modify. You can expand the pool size by adding drives to the pool,
and contract the pool size by removing drives from the pool.
The VMAX 100K is designed to be a new, lower entry point to the VMAX line, delivering
VMAX performance and capabilities in a smaller, more affordable footprint. The VMAX 100K
features an aggressive entry price, delivers solid performance, and offers the full suite of
rich data services available with all VMAX3 models. The VMAX 100K will be attractive to cost
conscious customers that require mission-critical storage for smaller data sets or contained
workloads.
The VMAX 200K is designed to meet the majority of our existing customer’s performance
and storage needs. The VMAX 200K delivers exceptional value for customers requiring very
high performance, complete VMAX3 functionality, and more usable capacity. The VMAX
200K can offer the same or better capacity and performance as most of the previous
generation VMAX 10K, 20K, and 40K configurations being sold, with a much smaller
footprint.
The VMAX 400K achieves new levels of performance and capacity not available in the
previous VMAX product line, and is not found in any competitive array. The VMAX 400K is
the new industry leader delivering unmatched performance and cloud-scale. Customers can
start small with 1 engine and grow over time to 8 engines (16 linear feet ). The VMAX 400K
is the new gold standard for high-end, mission-critical storage for hyper consolidation.
All three platforms are built on the industry-leading Dynamic Virtual Matrix Architecture and
run the same Hypermax OS code – which replaces the previous generation Enginuity code.
TDEVs (thin devices) or thin volumes can improve capacity utilization because an entire
physical volume is not used. A virtual volume is created from a common pool (thin pool).
The pool is shared by many TDEVs. Only the amount of physical space needed to store the
data is allocated to the TDEV.
In the example illustrated, the host has a 100 GB TDEV. When the TDEV is first created,
there is no data, so only 20 GB of physical space is allocated. As data is stored on the
TDEV, more space is allocated as needed. Physical space allocation is done automatically in
the background by EMC software on the array.
An IP SAN solution uses conventional networking gear, such as Gigabit Ethernet (GigE)
switches, host NICs, and network cables. This eliminates the need for special purpose FC
switches, Fibre Channel HBAs, and fibre optic cables. Such a solution becomes possible with
storage arrays that can natively support iSCSI, via GigE ports on their front-end directors
(VMAX) or on their SPs (VNX). For performance reasons, it is typically recommended that a
dedicated LAN be used to isolate storage network traffic from regular, corporate LAN traffic.
Departmental switches are used in smaller environments. These switches don’t have
some of the hardware redundancy that is built into the larger Director-class switches. But
SANs using departmental switches can be designed to tolerate the failure of any one switch,
by including multiple paths from hosts to storage. Departmental switches are ideal for
workgroup or mid-tier environments. The disadvantage of departmental switches are lower
number of ports and limited scalability. If for example, we tried to build a large SAN,
consisting of a thousand or more ports, using only departmental switches, many ports
would be used up, just to connect the switches to one another. This leaves fewer ports for
hosts and storage connections. Also the complexity and management burden of
interconnecting so many switches prohibits large-scale implementations.
Enterprise Directors are deployed in High Availability and/or large scale environments.
Connectrix Directors can have hundreds of ports in a single chassis. This solution easily
scales to SANs of a thousand or more ports using ISLs to connect multiple directors
together. Directors provide added flexibility because they are built with blades (or modules)
that can be added and mixed in various configurations to meet the needs of the data
center. Directors have a higher cost and larger footprint than departmental switches.
Multi-purpose switches, blades and modules are available to support other protocols
besides Fibre Channel such as FCoE for converged networks and FCIP for distance extension
solutions across a LAN/WAN.
Directors include the ED-DCX8510-4B with four slots available for port blades, providing
up to 192 16Gbps Fibre Channel Ports; and the ED-DCX8510-8B with 8 port blade slots,
providing up to 384 ports. Both director models come with high availability features such
as redundant, hot-swappable FRUs, including blades, power supplies, blowers, and WWN
cards.
The right-hand column shows the target code levels for each model. The target code is the
minimum revision of FOS (Fabric OS) that EMC recommends should be running on a switch.
There are currently two families of FOS that are supported on B-series switches, 6.4.x and
7.x. Most newer switch models are only supported using FOS 7.x or higher.
This course will focus on the newer switches that have not reached EOL. Details for older
switches can be found in various Connectrix B-Series documents such as the Hardware
Reference Manual for each model.
Directors include the MDS-9706 with 6 modules and up to 192 ports (4 slots are for port
modules), and the MDS-9710 with 10 modules and up to 384 ports (8 slots are for port
modules). These directors are highly available with dual supervisor modules and redundant
fans, power supplies and fabric (switching) modules.
The right-hand column shows the target code levels for each model. The target code is the
minimum revision of NX-OS that EMC recommends should be running on a switch. There
are currently two families of NX-OS that are supported on MDS-series switches, 5.2(x) and
6.x. Newer switch models are only supported using NX-OS 6.2.x or higher.
These tools are used to install, maintain, configure, monitor, and manage Connectrix B-
Series switches. Not all functions available through the CLI are available through the GUI.
These tools are used to install, maintain, configure, monitor, and manage Connectrix MDS-
Series switches. Not all functions available through the CLI are available through the GUI.
To meet continually evolving demands, data centers are moving from platform 2 designs
that are based on client/server topologies, to platform 3 designs that provide for social
networking, cloud, mobility, and big data. Administrators are being asked to manage more
and more data, with fewer resources than ever before.
This means that administrators need tools that can predict where resources such as VMs
and storage will be needed, and then automatically move and provision those resources and
also automatically provide connectivity through the network and the SAN, so that
administrators may be relieved of performing these routine tasks.
EMC ViPR SRM provides comprehensive monitoring, reporting, and analysis for
heterogeneous block, file, and virtualized storage environments. It enables you to visualize
application-to-storage dependencies, monitor and analyze configurations and capacity
growth, as well as optimize your environment to improve return on investment.
ViPR SRM addresses these layers by providing visibility into the physical and virtual
relationships to ensure consistent service levels. As you build out your cloud infrastructure,
ViPR SRM helps you ensure storage service levels while optimizing IT resources — both key
attributes of successful cloud deployments.
EMC ViPR SRM provides a topology view for validation and compliance, and also provides
monitoring and reporting for hosts, VMs, SAN ports, traffic utilization, and storage. ViPR is
switch vendor agnostic.
ViPR integrates with Connectrix B-Series fabrics by invoking the Storage Management
Initiative Specification (SMI-S) API of Connectrix Manager Converged Network Edition
(CMCNE). ViPR integrates with MDS-Series switches through SSH (Secure Shell) by
directly using the API of the switches.
ViPR does automated SAN zoning as part of the orchestrated storage provisioning process;
but it does not entirely manage Connectrix switches.
So even though ViPR provides automation of basic SAN provisioning functions, SAN
administrators still need the native Connectrix management tools because they provide a
level of detail and control that is not possible with non-vendor-specific tools.